Valet Linux Laravel Package

Technical Evaluation

What this package actually is: cpriego/valet-linux is not an application dependency — it is a host-level developer tooling installer. It is installed globally (composer global require cpriego/valet-linux) and, once valet install runs, it mutates the workstation: installs and configures nginx, dnsmasq (or NetworkManager/systemd-resolved hooks), PHP-FPM, a systemd service (valet.service), a sudoers drop-in under /etc/sudoers.d, and a locally generated CA added to the system trust store. The Dependents: 0 figure is expected and not a red flag; nothing should ever require this in a composer.json.

Architecture fit: Good fit only as an optional local convenience layer for individual Laravel/PHP developers on Debian/Ubuntu-family Linux. It is a poor fit as a mandated, org-standardized environment because it configures the host, not the project — it provides no reproducibility guarantee, no lockfile of the runtime stack, and no parity with CI or staging. Any team already standardized on Docker Compose/Sail, Devcontainers, or Nix will find it orthogonal and mildly conflicting (port 80/443 contention, DNS hijacking of *.test).

Integration feasibility: Mechanically simple — one global install, one valet install, valet link/valet park per project. The friction is environmental, not procedural:

• Requires sudo and root-owned service changes; many corporate-managed Linux laptops restrict this or run endpoint agents that flag sudoers edits and CA trust-store changes.
• Distro support is realistically Ubuntu/Debian-centric; Arch/Fedora/openSUSE support is community-grade and version-fragile.
• Conflicts with systemd-resolved's stub listener on 127.0.0.53 are the single most common install failure.
• No meaningful support for containers, WSL2 remote workflows, or ephemeral cloud dev environments (Codespaces, Coder, Gitpod) — a growing share of developer fleets.

Technical risk:

• Single-maintainer / bus factor. Historically a low-activity port that tracks upstream Laravel Valet with a lag; PHP version bumps, nginx config changes, and new Ubuntu LTS releases can leave gaps.
• Strategic risk (highest). Laravel Herd now covers Linux as the first-party, commercially backed option. A 27.4 score with an opportunity of 1.31 reflects that this package occupies a shrinking niche between "official free tool" and "Docker." Betting a documented onboarding path on it is a bet against the vendor's own direction.
• Blast radius. A misconfigured install can break host DNS or occupy port 80, which manifests as "my whole machine's networking is broken," not "my project is broken." That converts a dev-tooling problem into a support escalation.
• Security posture. Adding a third-party-generated CA to the system trust store is a policy decision, not a convenience one — it needs explicit sign-off in regulated environments.

Key questions to resolve before adoption:

1. Is Laravel Herd (official, supported) an acceptable substitute? If yes, this package is redundant.
2. Which distros and versions are in our fleet, and who owns the compatibility matrix?
3. Does endpoint security / IT policy permit sudoers and trust-store modification?
4. What is the canonical baseline — do we need native host serving at all, or is Sail/Devcontainers sufficient?
5. Who is on the hook for support when a developer's DNS breaks at 5pm on a Friday?
6. Is the pinned version we'd standardize on still receiving upstream Valet parity fixes?

Integration Approach

Stack fit: Appropriate for PHP/Laravel/WordPress developers on Ubuntu LTS who want zero-config https://project.test without container overhead. Not appropriate for polyglot teams, teams with heavy service dependencies (Redis, queues, search, multiple PHP versions simultaneously), or anyone who needs CI parity.

Migration path: Position it as an individual opt-in accelerator, never a team requirement. Concretely:

1. Keep the repository's canonical local environment (Sail/Compose) as the documented baseline for CI parity and new-service onboarding.
2. Publish a short "Valet Linux (optional)" appendix: pinned global version, install script, teardown runbook, and an explicit statement that Valet-based setups are best-effort, unsupported by platform engineering.
3. Provide a valet uninstall + trust-store cleanup procedure so a developer can back out cleanly if it fights their machine.

Compatibility and sequencing:

• Pin the version. Do not let composer global update float the tool. Record the exact tag and the PHP/nginx/dnsmasq versions it expects.
• Sequence as a pilot: (a) inventory distro/PHP spread across the team; (b) pilot with 3–5 volunteers on the dominant distro; (c) measure install success rate and time-to-first-served-site; (d) only then publish documentation. Do not publish docs before the pilot — undocumented success stories are cheap, and undocumented failures burn credibility.
• Pre-flight checks in the install script: port 80/443 free, systemd-resolved stub listener status, sudoers writability, existing Apache/nginx/dnsmasq packages.
• Coexistence rules: reserve *.test for Valet and ensure nothing else claims it; document port remapping if the developer also runs Docker on 80/443.

Exit criteria: If the pilot's install success rate is below ~80% or median time-to-first-site exceeds ~30 minutes, recommend Herd or Docker and abandon the path rather than documenting around failures. Given the 1.31 opportunity score and the first-party alternative, the default recommendation should lean toward not formalizing this dependency.

Operational Impact

Maintenance: Low frequency, high sharpness. The tool needs attention when: a new Ubuntu LTS lands, PHP is upgraded system-wide, nginx config formats shift, the local CA expires or is rejected after a browser/OS trust-store change, or upstream Valet diverges. Because it is a global install, there is no dependency manager to nudge anyone — stale installs silently rot until something breaks. Budget for a periodic "is this still the right recommendation?" review rather than continuous maintenance.

Support: The real cost. Failures are host-level and therefore high-severity-perceived: DNS not resolving, port 80 occupied, HTTPS warnings, 502 from a dead PHP-FPM socket. These are indistinguishable to the developer from "my laptop is broken," and the instinct is to escalate to platform engineering. Without an explicit ownership decision, this package quietly creates a volunteer support desk. Recommend: named owner (or explicitly "no owner, best-effort, here's the uninstall command"), a troubleshooting decision tree in the docs, and a hard boundary that platform engineering supports the Compose baseline, not Valet.

Scaling characteristics: It does not scale — it is per-workstation, per-developer state. There is no central configuration, no drift detection, no way to audit who is running which version against which nginx config. Cost grows linearly with headcount while consistency stays flat or degrades. For a 5-person team this is invisible; for 50 developers across mixed distros it becomes an unmanageable long tail of unique snowflake machines.

Failure modes to document:

• dnsmasq vs. systemd-resolved stub listener contention → total DNS failure on the host.
• Port 80/443 claimed by Apache, another nginx, or Docker → install or serve failure.
• PHP-FPM socket/version mismatch after a system PHP upgrade → 502 Bad Gateway.
• Expired or distrusted local CA → browser HTTPS interstitials that look like a security incident.
• valet uninstall leaving residue (sudoers drop-in, trust-store entry, orphaned service).
• Silent breakage in CI/remote-dev contexts where the host is not the developer's machine.

Ramp-up: Excellent for the target persona — a Laravel developer on Ubuntu is productive in roughly 15–30 minutes (install, park/link, secure). Near-zero for anyone else: container-first developers, non-Debian distros, WSL2 users, or developers on managed laptops without sudo get little to no value and meaningful friction. Onboarding materials should state this audience boundary in the first paragraph so the wrong people don't start down the path.

Bottom line for the TPM: Technically competent and pleasant for its narrow persona, but strategically declining — no dependents, thin maintainership, and a first-party alternative (Herd) plus a stronger reproducible baseline (Sail/Containers) on either side of it. Treat as a documented optional convenience with a pinned version and a clean exit, not as an infrastructure commitment.