Valet Windows Laravel Package

Product Decisions This Supports

• Developer onboarding and time-to-first-commit. The core value is compressing "new Windows laptop → running Laravel app at myapp.test" from a day of Nginx/PHP/MySQL/Redis/MailHog yak-shaving into a single install plus valet park / valet link. That is a measurable DX metric (time-to-first-request for new hires and contractors), which makes it a legitimate roadmap item rather than a nice-to-have.
• Local environment standardization (or deliberate non-standardization). Adopting it is a decision to bless a specific local stack — Nginx + PHP + MySQL/MariaDB + Redis + MailHog behind *.test — for Windows developers. The alternative decision is "bring your own environment," which is cheaper to mandate but expensive in support tickets. This package is the cheap end of the "standardize" spectrum.
• Build vs. buy vs. use the official thing. This is the central product question, and it is not obvious. Options in the same slot: Laravel Herd for Windows (free, first-party), Laravel Sail / Docker Compose, WSL2 + Docker, Laragon, XAMPP, or a hand-rolled scripted setup. valet-windows wins on zero-dependency, zero-Docker, near-zero-config; it loses on first-party support and cross-platform parity. A PM should be able to state which axis matters more before picking.
• Contractor and short-engagement velocity. External devs on Windows laptops can be productive on day one without provisioning entitlements for Docker Desktop or a commercial license. Reduces procurement friction for short engagements.
• Local/production parity for specific concerns. valet secure gives real HTTPS locally, which de-risks OAuth callbacks, cookie/SameSite behavior, secure-only cookies, and mixed-content bugs that only surface under TLS. valet share supports ad-hoc demos and webhook testing without deploying to staging. Both are small features with outsized value in the bug classes they eliminate.
• Where it should not drive decisions. It has no production footprint, no runtime coupling to the application, and no bearing on hosting, scaling, or deployment architecture. Do not let a local-env choice leak into roadmap discussions about infrastructure.
• Roadmap signal it sends. The 2.5.3 release adding PHP 8.4 support tells you the maintainer is tracking upstream runtime releases. That supports a "safe to adopt now" call, but it is a maintenance signal, not an endorsement of the tool as a long-term standard.

When to Consider This Package

Adopt when:

• The team is predominantly Windows and writing PHP/Laravel day to day.
• You want near-zero config and no Docker dependency — no virtualization layer, no container RAM tax, no Docker Desktop licensing questions, no WSL2 filesystem-performance surprises on bind mounts.
• You are a small team without platform engineering to maintain a shared Docker/devcontainer setup.
• You need several projects served simultaneously at friendly *.test hostnames, with per-project linking rather than editing hosts files.
• You need Redis, MailHog, and MySQL/MariaDB locally without assembling them yourself — mail catching in particular removes a class of "did the email send?" friction.
• Reversibility matters. It is MIT-licensed, installs at the workstation level, and can be uninstalled in minutes. Low-commitment pilots are cheap.
• You are willing to accept a community-maintained, single-maintainer tool (910 stars; 2.5.3 shipped March 2025) and to verify the PHP version-switching story (valet use) against your per-project version matrix before committing.

Look elsewhere when:

• Cross-platform parity is required. Mixed macOS/Windows/Linux teams should use Herd (macOS + Windows) or Docker/Sail so that "works on my machine" means the same thing everywhere. Maintaining two local-env playbooks is a real ongoing tax.
• You need production-grade parity. If your app depends on queues, workers, multiple services, specific extensions, or versions of Nginx/PHP that differ from what this tool ships, containers win. valet-windows is opinionated and lightly configurable by design.
• First-party support or an SLA is a procurement requirement. This is a community project; Laravel's own answer for Windows is Herd. If your org requires vendor-backed tooling, this is not it.
• macOS-heavy or Linux-heavy teams. macOS users should use upstream Laravel Valet; Linux users should use Docker/Sail. Adopting this creates a split-brain setup guide.
• You need reproducible, CI-identical environments. Local-only tooling cannot be your source of truth for CI. Pair it with a container-based CI or accept drift.
• The maintenance chain is a concern. Single-maintainer Windows tooling with no formal support path is a real risk for a 50-person engineering org, and a non-issue for a 5-person one. Match the risk to the org size.
• You are standardizing for the long term. If the answer must survive three years and two reorganizations, prefer the officially supported path and treat this as an accelerator that individuals may opt into.

How to Pitch It (Stakeholders)

For executives (one paragraph). This is a free, MIT-licensed developer tool that sets up a complete PHP/Laravel development environment on a Windows laptop in one command — web server, database, Redis, and a mail catcher — so engineers stop spending their first day(s) installing software and start shipping. There is no license cost, no procurement, no production footprint, and no lock-in: it can be removed from a machine in minutes. The strategic caveat is that it is a community-maintained project rather than an officially supported Laravel product, so we should position it as a tactical accelerator for Windows developers, not a mandated company standard. The recommendation is a two-to-three person, one-sprint pilot measured on time-to-first-request and local-environment support tickets, with Docker/Sail documented as the sanctioned fallback. Total downside if it disappoints: a few hours of engineering time.

For engineering leads. One-command install of Nginx, PHP, MySQL/MariaDB, Redis, and MailHog; valet park and valet link to serve projects at *.test; valet secure for HTTPS; valet share for public demos. The command vocabulary deliberately mirrors Laravel Valet on macOS, so anyone with Valet muscle memory is immediately productive, and onboarding documentation can largely be borrowed from upstream Valet. PHP 8.4 is supported as of 2.5.3 (March 2025), which means it is not the thing blocking a runtime upgrade.

For engineering, the honest caveats. It is Windows-only by design, so it does not solve parity for macOS or Linux teammates — plan for two documented paths or pick a cross-platform tool. It is community-maintained with a small contributor base, so we own the risk of an upstream stall. Configuration is intentionally minimal; if we need bespoke Nginx directives, extra services, or strict production parity, that is a signal to go to containers instead. And local-environment choice must never become a proxy for production architecture decisions.

The ask. Approve a time-boxed pilot with two or three Windows-based engineers. Success criteria: median time-to-first-request under one hour for a new machine, a measurable drop in "my local env is broken" support requests, and no blocker on per-project PHP version switching. If it clears those, document it as the recommended (not required) Windows path, keep Sail/Docker as the supported alternative, and revisit if Laravel Herd for Windows becomes the obvious default — at which point this decision costs us nothing to reverse.