ycodetech/valet-windows
A Valet-inspired local development environment for Windows. Park directories, link Laravel/PHP sites, and serve them on local .test domains with simple CLI commands—no Vagrant or heavy virtual machines required.
ycodetech/valet-windows is a Windows port of Laravel Valet: a per-user nginx + Acrylic DNS stack that serves your local projects at *.test with zero per-project configuration. The day-to-day workflow will feel identical to the macOS Valet if you've used it — most of the friction is Windows-specific (DNS, admin rights, port ownership), which is what makes the install the hard part and everything after it a one-liner.
Minimal setup:
PATH from a regular (non-WSL) PowerShell/CMD window, plus a terminal you can elevate. Nginx, Acrylic, and the certificate bundle are installed by the tool itself.composer global require ycodetech/valet-windows.%APPDATA%\Composer\vendor\bin to your PATH and verify with valet --version in a new shell.valet install in an elevated shell. This registers the Acrylic DNS service, writes the nginx config, generates the Valet CA, and starts everything. Reboot (or at least log out/in) so Acrylic's DNS binding takes effect.127.0.0.1. Acrylic resolves everything else upstream to 8.8.8.8 by default, but it must be the resolver Windows uses for *.test to hit nginx.valet park %USERPROFILE%\Sites (every direct subfolder becomes <folder>.test) or cd into a project and run valet link myapp. Visit http://myapp.test.Where to look first:
valet help — the command surface is your best map; it mirrors upstream Valet closely but not 1:1.%USERPROFILE%\.config\valet) — this is where Nginx/, Sites/, Certificates/, and Drivers/ live. Everything Valet does at runtime is reading or writing here.~/.config/valet/Nginx/ — the first place to look when a site 502s or 404s.C:\Program Files (x86)\Acrylic DNS Proxy\AcrylicConfiguration.ini — edit hosts behavior, add wildcard domains for custom TLDs.First realistic use case: park your ~/Sites (or ~/code) folder, clone three Laravel apps into it, and hit app1.test, app2.test, app3.test without ever touching a hosts file or vhost manually.
Park the root, link the outliers. valet park ~/Sites handles the 90% case (one site per folder, name = folder). Use valet link for projects checked out elsewhere, or when you need a name that differs from the folder, e.g. valet link acme-api inside ~/work/acme-api-v2. valet unlink inside the folder removes the site and its symlink.
HTTPS on demand, not globally. Use valet secure <site> per project when a payment provider, WebAuthn callback, or OAuth redirect needs TLS; valet unsecure <site> reverts it. Trust the Valet CA once in the Windows certificate store (certmgr.msc → Trusted Root) so Chrome/Edge stop complaining. Keep HTTP for sites where you use Vite's HMR over .test — mixing TLS in the dev loop usually just adds redirect pain for no benefit.
Proxy non-PHP services. Docker services, Node SSR servers, Rails, or Go APIs running on a local port can still live at api.test via valet proxy api http://127.0.0.1:8080 (and valet unproxy to remove). This is the cleanest way to keep a single .test convention across a polyglot repo without teaching every team member a different port map.
Custom drivers for non-Laravel apps. Valet's driver system (WordPress, Symfony, custom) still works here — drop a driver class in ~/.config/valet/Drivers/ and Valet will auto-detect wp-config.php, public/index.php, etc., and route to the correct subdirectory. On Windows, driver paths need Windows-style separators, so copy the shape from the shipped LaravelValetDriver rather than porting directly from a Mac blog post.
Per-site nginx overrides. Any file you put at ~/.config/valet/Nginx/<site>.test is loaded verbatim. Use this for client_max_body_size on upload-heavy apps, extra fastcgi_ tuning, or location blocks for a specific SPA. After changes, valet restart — nginx won't pick up the edit otherwise.
Team workflow. Valet is a global Composer tool, so it's a per-developer convenience rather than a project dependency — don't commit it to composer.json. Instead, document in the repo README: the required PHP version (so valet uses the right binary), the expected .test hostname, and any valet proxy/valet secure calls needed. That keeps Windows onboarding to a few commands without coupling CI to the package.
PHP version switching. The php on your PATH is the php Valet serves. Swap PHP with whatever version manager you use (valet restart afterwards), and confirm with valet php --version if that command exists in your version, or by checking the nginx fastcgi_pass in a site conf.
Port 80/443 is a battlefield. Windows services (IIS, Skype, "World Wide Web Publishing Service", sometimes Steam) grab those ports and Valet silently fails to bind or serves the wrong thing. Run netstat -ano | findstr :80 before blaming the package; valet restart after freeing the port. If you can't reclaim 80, edit the default nginx server in ~/.config/valet/Nginx/ — but be aware most Valet URLs assume port 80.
DNS is the #1 failure mode. *.test resolving to nothing usually means one of: (a) Acrylic service isn't running (services.msc → "Acrylic DNS Proxy"), (b) the adapter's primary DNS isn't 127.0.0.1, or (c) a VPN split-tunnel client (Cisco AnyConnect, Zscaler) has hijacked DNS. Validate with nslookup mysite.test 127.0.0.1 — if that answers, the problem is at the app layer; if it times out, it's Acrylic.
Admin shell for install, user shell for daily use. valet install and valet restart typically need elevation; valet park, valet link, and valet sites do not. Running everything as admin is a common way to end up with config files owned by the wrong SID (especially on domain-joined machines).
HTTPS will still warn in Firefox. Windows' certutil/certmgr trust only applies to Chromium and Edge. Firefox uses its own NSS store — import the Valet CA (~/.config/valet/Certificates/) into about:preferences#privacy → "View Certificates" → Authorities. If you skip this, the padlock looks broken but the site works.
Logs before guesswork. nginx access/error logs and PHP-FPM errors live under the Valet config dir and the package's install dir. A 502 Bad Gateway is almost always PHP-FPM not running or serving the wrong binary — check valet start/valet stop/valet restart state first, then php -v from the shell Valet inherits.
Don't mix WSL and Windows. If your project lives on WSL and you're driving the Windows PHP + nginx stack, file paths, symlinks, and permissions diverge in ways Valet won't reconcile. Pick one: either run Valet inside WSL (separate stack, not this package) or keep the project on the Windows filesystem and use the Windows toolchain. valet linking a \\wsl$\... path is a known source of "site resolves but 404s".
Antivirus and Defender slow first-requests. Real-time scanning of the Valet home dir and your project folder adds 200–800ms to cold requests. Excluding both directories is a meaningful quality-of-life win on day one.
Version drift from upstream Valet. Because this is a community port tracking macOS Valet, some commands (valet share especially, which depends on external tunneling tools) may be missing, partial, or behave differently than Laravel's docs describe. When a doc claim doesn't match, trust valet help over the upstream site. Pin the install (composer global require ycodetech/valet-windows:<x.y>) if you need reproducible behavior across a team, and re-run valet install after upgrading — the nginx config and certs aren't always migrated automatically.
Extension points worth knowing. Beyond drivers and per-site nginx confs: custom TLDs (edit AcrylicConfiguration.ini wildcard + valet link --domain), custom CA (replace files in ~/.config/valet/Certificates/ if you need internal-CA-signed sites for testing), and shell-level valet aliases in $PROFILE for the commands you type most (commonly vrestart, vpark).
How can I help you explore Laravel packages today?