Laravel Valet: a Mac development environment without Vagrant or /etc/hosts

What Laravel Valet replaces, and who it is built for

The README opens by calling Valet a Laravel development environment for Mac minimalists, and names two things it removes: Vagrant and the /etc/hosts file. That is the whole pitch. Instead of provisioning a virtual machine per project, you install Valet once and it configures the Mac itself to serve your sites. The README states that Valet configures your Mac to always run Nginx in the background when your machine starts, and that DnsMasq proxies all requests on the *.test domain to sites installed on your local machine.

The intended user is a Laravel developer working on macOS who keeps projects in a single directory and wants each one reachable at a predictable hostname. The README is explicit about the trade-off: Valet isn't a complete replacement for Vagrant or Homestead, but provides a great alternative if you want flexible basics, prefer extreme speed, or are working on a machine with a limited amount of RAM. It also states the environment uses roughly 7mb of RAM. That figure is the project's own claim, not an independent measurement, and it describes the resident footprint of the stack rather than the memory your PHP process will consume while handling a request.

If your team standardises on a container or VM image so that every developer runs identical PHP, database and extension versions, Valet is the wrong shape of tool. It runs on the host operating system, so the environment is your Mac.

How Nginx and DnsMasq serve *.test without touching /etc/hosts

The mechanism in the README is short but specific. A background Nginx process runs from machine startup. DnsMasq resolves the *.test domain locally. Requests for a hostname ending in .test therefore land on the local Nginx rather than going out to a public DNS resolver, and Nginx routes them to the matching site directory.

Because resolution happens through DnsMasq instead of the hosts file, adding a project does not mean editing /etc/hosts. That is the practical difference from the manual approach many developers start with, where each new hostname is a line appended to a system file. The repository layout reflects this: the cli/ directory holds the command line application, valet is the entry script at the top level, and server.php sits alongside it. The top level also contains find-usable-php.php, which suggests the tool inspects the machine for installed PHP versions rather than assuming one.

What the README does not describe is the routing rules themselves, how a hostname maps to a directory, or what happens when two parked directories claim the same name. Those details live in the documentation on the Laravel website, which is where the README points for anything beyond the introduction.

Installing Laravel Valet on macOS and serving a first site

The README does not contain installation commands. It states that documentation for Valet can be found on the Laravel website at laravel.com/docs/valet, and that is where the install steps live. The repository does give you two things you can verify: the package name in composer.json is laravel/valet, and the top level contains a valet entry script alongside the cli/ directory.

Because the README gives no install commands, the honest answer is that you should follow laravel.com/docs/valet for the actual steps. A global Composer install is the conventional route for a package named laravel/valet, but the README does not show that command, so treat the documentation as the source of truth rather than any snippet you find elsewhere.

What the README does describe is the end state after installation. Nginx runs in the background from machine startup, DnsMasq handles the *.test domain, and sites installed on your local machine answer on that domain. The observable result is that a request to a *.test hostname resolves locally instead of failing DNS.

One documented capability worth noting at this stage: the README says you can share your sites publicly using local tunnels. That is a feature of the tool rather than a separate product, though the README does not name the tunnel provider or the command.

Where Valet stops being the right tool

The README draws the boundary itself: Valet isn't a complete replacement for Vagrant or Homestead. Read that literally. If your project depends on a specific Linux distribution, a particular kernel module, or a service that does not run natively on macOS, Valet cannot supply it, because there is no virtual machine underneath. The environment is your Mac.

A second limitation follows from the architecture. Nginx runs in the background from machine startup. That is convenient, and it also means a web server is listening on your laptop whether or not you are working on a project. Developers who want the server to exist only while a project is active will find this arrangement backwards.

A third is platform. The README describes Valet as a Laravel development environment for Mac, the repository topics are laravel, macos and php, and the description says the same thing. There is no Windows or Linux story here. If your team is mixed-platform, Valet solves the problem for exactly one of them.

Finally, the README does not document rollback. There is an UPGRADE.md file in the repository, which implies upgrades are a documented concern, but nothing in the README explains how to undo an install or return to a previous version. Treat the upgrade notes as required reading before changing versions.

Valet against Vagrant and Homestead, and against plain manual setup

The README names Vagrant and Homestead as the alternatives it is measured against, and the difference is architectural rather than cosmetic. Vagrant and Homestead provision a virtual machine; the application runs inside that guest. Valet configures the host. The consequence is that Valet starts faster and uses less memory, which is the README's own framing when it mentions roughly 7mb of RAM and machines with a limited amount of RAM. The cost is isolation: a VM gives you a reproducible Linux environment that matches production more closely, and Valet gives you your Mac.

There is a second comparison the README makes implicitly. It says no /etc/hosts file. The manual alternative is a locally installed Nginx plus hand-edited host entries, which works but turns every new project into a system file edit. Valet's DnsMasq configuration replaces that with a wildcard domain, which is the actual improvement.

Neither comparison is settled by the README alone. If you need production parity, the VM approach wins on the axis that matters. If you need a Laravel site answering on a hostname within seconds of creating the directory, and you are on a Mac, Valet is aimed squarely at you.

Maintenance, releases and what the MIT licence means here

The repository is not archived, and the last push was on 2026-09-22. Recent releases listed are v4.12.0 on 2026-03-10, v4.11.1 on 2026-02-10 and v4.11.0 on 2025-10-07. The gap between the most recent release and the latest commit is worth noticing: the codebase moves between tagged versions, so if you pin to a release you are not tracking everything on main.

Upgrade cost is real for a tool that modifies system services. Because Valet configures Nginx and DnsMasq on the host, a major version change can touch those services, and the repository ships an UPGRADE.md file precisely because the steps are not obvious. The README does not describe a rollback path, so the practical discipline is to read UPGRADE.md before moving between major versions and to know which PHP versions find-usable-php.php will select on your machine.

Licensing is straightforward. The README states that Laravel Valet is open-sourced software licensed under the MIT license, and the repository carries LICENSE.md. MIT is permissive: you can use, modify and redistribute the code, including in commercial settings, provided the licence and copyright notice are preserved. This is a description of the licence text, not legal advice, and if you are redistributing Valet inside a product you should read LICENSE.md yourself.

Editorial conclusion

Adopt Laravel Valet if you develop Laravel on a Mac, want sites served on the *.test domain, and are willing to let it run Nginx in the background from boot. Do not adopt it if you need a full Linux VM, run Windows or Linux as your daily driver, or require the environment to be identical to production. Before committing, verify that the documented installation path on laravel.com/docs/valet matches the PHP and Homebrew setup on your machine, and read UPGRADE.md before moving between major versions, because the README does not document rollback and the upgrade notes are the only place that describes what changes.

Frequently asked questions

Official sources

1. laravel/valet on GitHub
2. License: MIT
3. Project website
4. README
5. Releases