Valet Windows Laravel Package

Technical Evaluation

Architecture fit. This is not an application dependency — it is developer-environment tooling. Nothing in a Laravel codebase references it, no composer.json entry is created, and it ships no service providers, facades, or config that touch production code. Architecturally that is the safest possible category: adoption is reversible, blast radius is a developer workstation, and it cannot introduce a runtime dependency into the deployable artifact. The fit question therefore reduces to environment parity: does the stack it provisions (Nginx + PHP-FPM + MySQL/MariaDB + Redis + MailHog, projects served at *.test over HTTP/HTTPS) match what our applications actually run against in staging and production? Where production is Nginx/PHP-FPM, Valet Windows is a reasonable local mirror. Where production is Apache, or where the team already standardizes on containerized parity (Docker Compose / Laravel Sail), Valet Windows is a competing convention that would fragment the fleet rather than unify it.

Integration feasibility. Mechanically simple and well understood: a one-command installer that elevates, writes the Windows hosts file, registers Nginx and database services, adjusts PATH, and exposes a valet CLI (park, link, secure, share). Onboarding cost per developer is measured in minutes. The feasibility risks are not in the install but in the preconditions: local admin rights, antivirus/EDR tolerance of a newly installed background service listening on ports 80/443, and coexistence with anything already bound to those ports (IIS, Skype, prior XAMPP/Laragon/WAMP installs). In a managed corporate Windows fleet, those preconditions are policy questions, not technical ones, and they are where most rollouts stall.

Technical risk.

• Security surface. Installing privileged services and modifying the system hosts file is a configuration-management event. valet secure generates and trusts a local CA — distributing and later revoking that trust across machines needs an owner. valet share tunnels a local site to a public URL, which is a genuine data-egress risk if used with production-like data and needs an explicit policy.
• Version skew. Release 2.5.3 adds PHP 8.4, but Valet's per-site PHP switching means each developer can silently run a different interpreter than CI. The tool makes version drift easy, which is convenient locally and hazardous for parity.
• Maintenance concentration. 910 stars and an active 2025 release are encouraging, but this is a community project in a niche (Windows-native Valet) with a historically small contributor base. Upstream Laravel Valet is macOS/Linux-first; this port tracks it at a distance. Bus-factor and Windows-version-breakage risk are real.
• Absence of contract. There is no SLA, no LTS policy, and no compatibility matrix published beyond release notes. We cannot infer support commitments.
• Reversibility. Uninstall quality is unverified — leftover services, hosts entries, trusted root certificates, and data directories are the typical residue, and they are the thing that makes "we tried it" expensive to undo.

Key questions.

• Does our engineering fleet actually run Windows natively, or is WSL2 the sanctioned path? If WSL2, this tool is redundant.
• Do we already have a containerized or Herd/Sail-based standard, and would this create a second, conflicting convention?
• Can non-admin developers install it, or does it require a helpdesk ticket each time?
• What is our policy on locally trusted root CAs, and who owns issuance and revocation?
• Is valet share permitted, and if so, under what data-handling constraints?
• Which PHP versions must we support, and does Valet's per-site switching get pinned to match CI?
• What is the maintainer bus factor, and how quickly has the project historically absorbed PHP and Laravel major-version changes?
• What does a full uninstall leave behind, and is that documented?
• How does it behave alongside existing XAMPP/Laragon/Docker installs during a transition period?

Integration Approach

Stack fit. Adopt only if three conditions hold: the team is Windows-native, production is Nginx/PHP-FPM (or we accept the divergence knowingly), and we do not already have a containerized local standard that developers rely on. If any of those fails, the correct answer is to standardize on the existing tool rather than add a second environment manager. Valet Windows is a convention, and two conventions is worse than one imperfect one.

Migration path. Treat this as a tooling migration with a defined cutover, not an install:

1. Inventory current local stacks per developer (XAMPP, Laragon, WAMP, Docker, WSL2) and the ports, services, and hosts entries each owns.
2. Decommission before install. Retire the incumbent stack first — port 80/443 conflicts and stale hosts entries are the dominant first-day failure.
3. Pilot on two or three volunteers with heterogeneous machines (Windows 10 and 11, Home vs Pro, different EDR products). Capture every deviation as documentation.
4. Codify the setup as onboarding documentation and, where possible, a scripted bootstrap so the one-command install is genuinely one command including PHP version pinning.
5. Cut over the remainder, keeping the old stack recoverable for one sprint.

Compatibility. Windows 10/11; PHP through 8.4 as of 2.5.3; MySQL/MariaDB, Redis, and MailHog provisioned as Windows services. Verify explicitly against: Windows Home (no Hyper-V, affects any WSL2 fallback), corporate EDR/antivirus whitelisting, non-C: install locations, path names containing spaces, and coexisting VPN clients that intercept local traffic. Also verify that the provisioned MailHog version is compatible with the mail assertions our test suites make — a local mail sink that behaves differently from CI's is a subtle source of false-green tests.

Sequencing. Pin a specific Valet release and a specific PHP minor per project, recorded in the repo (e.g. a .valet-php convention or README), so switching is deliberate rather than incidental. Land the pilot and documentation before broad rollout. Do not couple this to any application or framework upgrade — it is orthogonal and should not gate or be gated by runtime work.

Operational Impact

Maintenance. Ongoing cost is low but non-zero and largely invisible: periodic valet upgrades, PHP minor bumps, service health after Windows updates, and re-issuing local certificates when they expire. Someone must own "the local dev environment" as a named responsibility, otherwise it degrades into per-developer snowflakes. Because the tool auto-updates services underneath the developer, an upgrade can change Nginx or PHP behavior without any repository change — an unusual property that argues for pinning versions and upgrading deliberately.

Support. Expect a front-loaded support burden concentrated in the first two weeks per cohort: port conflicts, hosts-file permissions, certificate trust prompts, and EDR quarantine. After that, support drops to near zero for developers who stay on the rails and spikes for anyone changing PHP versions or adding a second stack. Community documentation is reasonable but generic; internal runbooks are what actually reduce tickets. There is no commercial support tier, so all escalation is internal or upstream issue-tracker-based.

Scaling. Scales trivially with headcount — it is a per-workstation tool with no shared infrastructure and no production footprint, so there is no capacity, throughput, or cost dimension. The scaling risk is consistency: the more developers and the more projects, the more PHP versions, service configurations, and certificate states exist in the wild. Per-site PHP switching is the specific feature that makes drift cheap and therefore likely. Mitigate with per-repo version pinning and a CI-aligned PHP matrix rather than by restricting the tool.

Failure modes.

• Environment drift without signal. Developers on different PHP minors produce different behavior than CI; failures get misattributed to the application. Mitigation: pin PHP per repo, document it, and treat mismatches as defects.
• Port and service collision. A leftover XAMPP or IIS binding silently wins port 80; *.test resolves to the wrong server. Mitigation: decommission-first migration and a documented health check.
• Hosts-file and certificate residue. Uninstalls leave trusted root CAs and hosts entries behind, creating durable security and DNS surprises. Mitigation: a written uninstall procedure and periodic audit of trusted roots.
• Security policy conflict. EDR blocks the Nginx service or the installer requires elevation an unmanaged user cannot obtain, halting rollout mid-cohort. Mitigation: validate with IT/security before the pilot, not after.
• Data egress via valet share. A developer exposes a local site publicly with real data. Mitigation: explicit policy and, ideally, technical restriction.
• Upstream abandonment or Windows breakage. A Windows update or a stall in maintainer activity leaves the fleet stranded. Mitigation: keep a documented fallback (WSL2/Sail) and re-evaluate at each major Windows or PHP release.
• Mail-parity gap. Local MailHog behavior diverges from CI's mail transport, producing tests that pass locally and fail in CI or vice versa.

Ramp-up. Effectively zero for a developer who has used Laravel Valet, Laragon, or any *.test-style local stack: park/link/secure are a five-minute explanation. Budget roughly half a day for first-time setup including troubleshooting on a managed machine, and invest an hour in a written runbook covering PHP version switching, certificate trust, port conflict diagnosis, and uninstall. The TPM-level ramp-up is the policy work — EDR sign-off, CA trust policy, and share rules — which is small but must be scheduled, because it is the only part of this adoption that cannot be fixed by a developer at their own desk.