Valet Linux Laravel Package

Product Decisions This Supports

Local development environment standard (build vs. buy vs. skip) Valet Linux is a zero-cost, MIT-licensed, host-level dev environment: nginx + php-fpm + dnsmasq, with *.test domains auto-served from a project directory. The PM decision it informs is whether your team standardizes on a host-level tool or a containerized one (Laravel Sail, DDEV, Docker Compose). It is the cheapest possible option in effort and infrastructure, so it's the right default only if your app's dependency surface is shallow.

Onboarding time as a measurable KPI This package directly attacks first-day friction: clone → valet link → browse to project.test. If your onboarding survey says "it took two days to get the app running," this is a candidate intervention. Treat adoption as an experiment with a before/after onboarding-time metric rather than a mandate.

Platform support matrix and documentation scope Because official Laravel Valet is macOS-only, this package is effectively the "Linux-native" answer for engineers on Ubuntu/Fedora workstations. That makes it a documentation decision: do you publish a supported-environments page with one blessed path, or per-OS recipes? A PM should decide whether Linux engineers get first-class treatment or are told to use WSL/Docker.

Scope boundary for "supported dev setup" Valet Linux is single-stack and host-level: one PHP version at a time, no service orchestration. If your roadmap includes queues, Redis, search, multi-version PHP, or a shared team database, the decision this package supports is a no — it becomes a personal convenience tool, not a team standard.

Sponsorship / maintainer-risk posture 1,467 stars is respectable but modest for a dev tool, and this is a community port with a single-maintainer risk profile. The PM decision is whether to depend on it silently, depend on it with a documented fallback, or contribute/sponsor upstream. Note that "0 dependents" and an opportunity score of 1.31 are expected here, not a red flag — it's a CLI tool, not a library, so nothing can depend on it in the Composer sense, and there is little commercial upside to capture. Value it as an enabler, not a differentiator.

Where it does not belong on the roadmap Not production infrastructure, not CI, not a deployment mechanism. Do not let "it works on my machine via Valet" leak into environment-parity assumptions.

When to Consider This Package

Adopt (or at least document as an option) when:

• Your engineering org has a meaningful Linux workstation population and official Valet isn't an option.
• The app is a conventional single-service Laravel/PHP app (MySQL/SQLite, no exotic daemons) that runs fine on host PHP.
• You want a sub-hour "clone and browse" experience without asking engineers to install and run a container runtime.
• You're optimizing for minimal local resource usage — no VM, no Docker daemon, no per-project images.
• You need HTTPS locally for testing callbacks, cookies, or OAuth flows without hand-managing certificates.
• You have a documented escape hatch (Sail/DDEV) for engineers whose projects need more.

Look elsewhere when:

• Reproducibility and parity matter more than speed: multi-service apps, pinned PHP/extension versions, or teams that must match a containerized CI image — use Laravel Sail or DDEV.
• Your team is macOS/Windows-dominant; official Valet or WSL2 covers those, and maintaining two local-dev narratives is drag.
• You need multi-version PHP side by side, or per-project database/service isolation.
• Your security posture disallows a tool that runs a background daemon and modifies system DNS (dnsmasq) and nginx config with elevated privileges on engineer laptops.
• You require vendor support or an SLA; this is a community project with a small maintainer base.
• You're evaluating a runtime dependency for shipped product code — this is developer tooling only.

How to Pitch It (Stakeholders)

To executives: This is free, MIT-licensed developer tooling — not a product dependency — that can cut Linux engineer setup time from days to minutes by giving each project a real local domain with no VMs or containers. There is no license cost and no production risk. The tradeoff is that it's community-maintained and Linux-only, so we recommend it as a documented option alongside a containerized path, not a company-wide mandate. Expected upside is engineering hours saved at onboarding and on environment debugging; downside is bounded to a documentation page and an optional sponsor relationship.

To engineering: Use it if you're on Linux and your project is a plain Laravel app — valet link and you're serving over HTTPS with a trusted local cert, no Docker daemon, minimal RAM. If your project needs Redis, queues, search, multiple PHP versions, or must match CI exactly, use Sail/DDEV instead, and we'll keep both paths documented so nobody is blocked. If you rely on it, know the fallback: it's one maintainer, so keep your project runnable under Docker as a safety net.

To security/compliance: Scope is limited to developer laptops; it installs nginx and php-fpm and runs a DNS resolver for *.test domains, and it never touches production. Review is a one-time laptop-configuration review, not a code-audit item.