Valet vs VVV vs Chassis: A Comparison Guide to CLI-Based Local Dev Environments


In my last article, I reviewed a few different options for hosting WordPress locally using GUI-based apps. Well, the nerd voice was strong in the comments section of that article and the nerds want CLI-based tools. If it isn’t text or it has more than 8 colors, they don’t want to hear about it. Well, nerds – here it is. A bunch of text, about a bunch of other text, that you can use to host your WordPress websites locally. Rejoice.


This time around, I looked at a few different CLI-based local dev setups – I had no criteria for choosing which ones, I pretty much just typed all of the names that I thought I remembered into Google and tried out the 5 that were actually things. You’re welcome.

Hot Tip: If you want to destroy your productivity as a web developer, install a bunch of different tools that all want to run on port 80 and print out 10-page manifestos of red text whenever something else is running on port 80… Highly effective.


Not to be confused with the incredible game, VVVVVV, VVV, or Varying Vagrant Vagrants (cool…), is a WordPress-centric Vagrant configuration that allows you to easily spin up a new web stack that has been tailored to the requirements of modern WordPress development and recommendations of the Core team. Not so much a tool or an app on its own, VVV, is really more like a set of best practices for server administration wrapped up as a Vagrantfile.

  __     ___     ___     __  ____
  \ \   / \ \   / \ \   / / |___ \
   \ \ / / \ \ / / \ \ / /    __) |
    \ V /   \ V /   \ V /    / __/
     \_/     \_/     \_/    |_____|

Getting started with VVV

Installing VVV is really straightforward, once you’ve got Vagrant and VirtualBox installed, just clone their repo (or download it), copy the vvv-config.yml file to vvv-custom.yml and update it with the sites you’d like to run and any specifics like PHP version, utilities, etc. then run vagrant up and you’ll probably be up and running after a few arduous minutes of watching it do… stuff.

If you’re familiar with YAML–or like… have ever looked at a configuration file before–VVV makes it really easy to add new sites to your box, just create a new site configuration in vv-custom.yml and then run vagrant provision. This is way faster than completing the same task in a GUI app, and running vagrant provision when the box is already running only takes a few seconds in comparison to the 15ish minutes that an initial provision will take.

I’m not going to go over detailed installation or usage instructions for most of these setups, I’d really just be copying and pasting over each one’s “quickstart” page, and I feel like we’re better than that. You’re better than that. Just hit up the docs like a real nerd 🤓.


So long as you can get Vagrant and VirtualBox installed, VVV is a pretty solid choice for running local WordPress development environments. It comes with everything you need to get going on a WordPress project out-of-the-box. I really like the idea of bundling the development environment along with your project; it seems like a simple and clean way to handle this sort of thing and it works well – especially useful if you’re Automating Local WordPress Site Setup.

On the negative side, if you’re not well-versed with how Vagrant works (I’m not), then it can feel a bit obtuse, and you might have to keep running back to the docs to get things working or make changes to the server setup and hosts. Additionally, Vagrant boxes aren’t exactly lightweight and VVV is really designed to run multiple sites on one box, so if you are running per-project VVV instances, I wouldn’t be surprised if things start to get a bit sluggish.

VVV Rating

#! #! #! Three shebangs.
One for every V.


Chassis is pretty much just VVV with fewer bells and whistles. I don’t mean that in a bad way (quite the opposite, actually) – Chassis’ lack of features is actually its biggest feature.

While VVV can be bundled with projects and you can run a new Vagrant box for each VVV instance, it’s really designed to run multiple sites on one box as well as provide a lot of functionality and services to each of those sites. Chassis, on the other hand, is designed to run a single site per box/install/whatever and its boxes are a lot leaner. In my testing, provisioning a new Chassis box from scratch took about 4 minutes where VVV took around 15 minutes. While running a bunch of these will still slow down your host system, Chassis aims to be a bit lighter.

The cool thing about Chassis is that it becomes a part of your project, so if you’re developing a plugin, theme, or website with a team (or even if you’re just using multiple computers yourself), all anybody needs to do to jump into development is run vagrant up from within the folder in your project that contains the Vagrantfile and they’ll be running your project in the exact same server environment that it was originally set up with.

Getting Started With Chassis

First, you’re going to want to read the Chassis docs if you haven’t already. Next, you’ll want to make sure not to email me if you can’t figure it out from there because we’ve already been over the fact that I’m not going to hold your hand here…


At this point, I feel like kind of a dummy for including both Chassis and VVV as separate things. The two are essentially the same: frameworks, or maybe just opinionated default configurations for running WordPress servers on Vagrant. Chassis has a slightly different philosophy from VVV, and it’s one that might be a bit more in line with how I tend to do things, but I wouldn’t go so far as to say that it’s better or worse than VVV. They’re just slightly different tools that have minor (dis)advantages over each other depending on how you’d like to work.

Chassis Rating

#! #! #! Three shebangs.
One for every s.


Valet is something quite different from Chassis or VVV. While the former tools run virtual machines that are isolated from the rest of your environment, Valet runs directly within OS X (sorry, Windows users (not really)).

Valet is brought to us by the fine folks that make Laravel, and while it is built and maintained by the Laravel community, it will also run WordPress out of the box. For a great introduction to Valet, check out the introduction video which is as entertaining as it is informative.

While Valet is more like a MAMP or DesktopServer in that it’s installed globally on your machine rather than as a dependency of your project, it comes with some really nice advantages over the project-level solutions like Chassis and VVV: It’s very lightweight and serves sites quickly without bogging down your machine, and making a new site is as easy as creating a new folder within a directory that you have “parked” with Valet – no need to fiddle with the hosts file, it just sort of works.

Valet comes with baked in support for running your sites over HTTPS, sharing sites with Ngrok tunnels, and a bunch more. Additionally, there is also Valet Plus, which adds even more great features like the ability to quickly switch php versions, database helpers, and Xdebug helpers.


Valet isn’t purpose-built for WordPress, which you might view as a feature if you do any non-WordPress development. But that does mean that you need to create a database and install WordPress for each new project that you create. While this might be a sticking point for some, writing a script to do this for you with one command is a pretty trivial task and even if you did it manually each time it would still be significantly faster than provisioning a new Vagrant box with Chassis or VVV.

Valet is really fantastic if you run a lot of development sites at once, or if you need to be able to quickly create new sites on the fly without setting up a whole bunch of tooling. On the other hand, if you only work on one project at a time and/or if you need to work on that project with multiple developers or from multiple locations with a consistent development server environment, then Valet might not be your best choice.

For my money, Valet (Plus) is the best option I’ve explored so far, and might even replace MAMP Pro in my day to day workflow – and not just because I had to completely uninstall MAMP to get it working…

Valet Rating

#! #! #! #! Four shebangs.
I primarily like the fact that it’s Mac only.

Honorable Mentions


Devilbox is kind of like VVV meets Valet. It runs using Docker containers rather than Vagrant, and it runs globally in a similar manner to Valet in that once you have Devilbox up and running, you can add new sites by just creating folders in Devilbox’s www directory (and updating your hosts file).

While Devilbox provides a lot of tools and features including a cool status dashboard, it’s also pretty obtuse when it comes to actually using it. In my experience of using Docker, this is pretty much the norm as you really need a flowchart to understand how to run commands with docker-compose, so if you’re not some Docker savant, you’ll probably need to consult the docs quite a bit – even for just simple commands:

# Call a generic command
$ docker-compose exec --user devilbox php 
    |           |         |         |        | 
    use        execute    use     container  the
docker-compose    cmd    built-in    name     actual
                on the    user       to      command
                docker   devilbox   exec     to
                container            command  execute

How intuitive…


InstantWP is a really cool project that was brought to my attention after my previous article on GUI based local development environments as something I should have reviewed for that one. So why mention it here, you might ask? Because InstantWP is both a CLI and GUI based local dev environment – neat!

InstantWP installs within your project like Chassis, but runs on a virtualization technology called QEMU. While you can run InstantWP entirely from the CLI, it also comes with a control panel app that will get you up and running without needing to type a single command.

The main thing that I didn’t like about InstantWP is that all of its services, including the web server itself, are bound to ports on your localhost. So rather than nice, easy to remember domain names like hungry-for-apples.local or, your InstantWP urls will look more like or which are ugly and I hate them.


To be honest, when it comes to CLI-based tools for running local development servers, there are probably as many tools and homespun solutions as there are grains of sand in the back of my car after coming home from the dog beach (which is a lot). That’s because nerds like you see a perfectly good tool that a number of folks have spent good time crafting into a well-thought out product and think, “I could make something better than that this weekend…” Which one you choose or choose to fork is really up to your personal preferences and/or the needs of your project.

Personally, as a developer of WP Migrate DB Pro, I like to have a lot of different development sites to test different migration scenarios on. I also usually just nuke sites after I’m done running through those tests, something like Valet is a perfect fit for my workflow since I can get new sites up and running quickly and having many sites running at a time doesn’t require as much overhead as it would with a VM based solution.

What CLI-based local development solution is the perfect one for you and why? Let us know in the comments!

About the Author

Jeff Gould

Jeff is a problem solver at heart who found his way to the web at an early age and never looked back. Before Delicious Brains, Jeff was a freelance web developer specializing in WordPress and front-end development.

  • Nathaniel

    I’m curious if you’ve heard of I really like it because I’m able to spin up local dev environments _as well as_ my staging/production/whatever else environments. It uses Ansible to configure the servers. Really handy and great team behind it!

  • davidpaquet

    I know it’s not strictly “CLI”, but have you tried Local by Flywheel? Underneath, it does use Docker, but it come with a nice UI.

  • gatchaman

    Ugh. As someone who started writing programs to run on DOS, I never, ever wanted to return to CLI’s. That being said, some things are just better (GULP over CodeKit for example).

    IMHO, vagrant is a great tool, but if you don’t need to recreate an exact server config, its a bit overkill for most WordPress builds.

  • alexhaworth are doing sandboxes (docker) now which can spin up directly from your GIT and has better deployment integration.. Interested to know anyones thoughts on this.

  • Have you tried out Homestead from Laravel? I like it mainly because we also run a lot of our stuff on Forge so the environments are identical then.

  • clifgriffin

    Valet’s main advantage beyond what’s already been mentioned is performance. Running a virtual machine, even on the latest and greatest hardware, is still slow as hell.

    I tried so many things to speed up VVV. I tried VMWare Fusion instead of VirtualBox. I tried numerous virtual machine configurations.

    Nothing worked consistently and it always slowed down over time, especially with larger sites.

    I haven’t had a single issue with speed since I switched to Valet. (Almost a year now)

    It’s also really nice that you can script interactions with Valet and run them directly in terminal rather than having to deal with SSHing into the VVV environment (or the workarounds).

  • Is it really that unpopular to just run your own LAMP/LEMP stack on your favorite Linux distro and be happy? 😀
    I’m running a LEMP stack and I have a couple of simple commands to setup a new site on it’s own domain(on my machine):
    cd /etc/nginx/sites-available/
    sudo cp
    sudo nano
    // searches references for and replaces them – I know, I should be using sed like a boss, but I’m not 🙁
    sudo ln -s /etc/nginx/sites-available/ /etc/nginx/sites-enabled/
    sudo service nginx reload

    I know that it seems like a lot, but with auto-completion it seriously takes ~1-2 minutes.

  • I quite like VVV. If I didn’t do so much work on Pantheon, I’d use it exclusively. For Pantheon users, there is Lando ( ) which makes Dev Ops a whole lot easier.

  • InstantWP

    Thanks for mentioning InstantWP, Jeff! Your criticism of the ugly URLs is 100% right of course, but they are there for a reason. InstantWP is completely portable so it does not need any configuration changes on your machine. To get the nice local domain names you have to fiddle with the hosts file on the machine and that is not portable unfortunately 🙂 But the portability means you can copy and paste InstantWP around like any other folder and run it from a USB key. It was designed for students in a classroom originally and still used worldwide for teaching WordPress – hence the ugly URLs.



    • Thanks for the note, Seamus – makes perfect sense!

      Would be cool to utilize something like for prettier zero-conf urls.

  • I am one of about 93 million Linux users who won’t find anything of much interest here. In your next article, if you could be a little less Mac-centric and Window-biased it would be much appreciated.

  • Jordan

    I love Scotch Box it has worked so well for me and spins up new environments with ease.

  • Cameron Jones

    Big fan of Chassis. I love how, unlike XAMPP and VVV and the like, you have a new box for each site, which is really helpful when you’re dealing with a variety of sites on a variety of hosts and PHP versions, I can change the config without breaking anything else I’m working on and store each development environment within a project folder with all my other assets and docs for the project instead of some global location. It also handles hostnames without needing to touch a hosts file which is super handy.

  • Valet users that want to create WordPress sites fast, take a look at wp-cli-valet-command.

    With that installed, we can use a shell script and create a WordPress site with a single command from anywhere in the terminal: wp-create sitename


  • kristjan07

    I have tested most of them and Lando ( wins in a long shot.

    It has all:
    * Don’t restrict only to WordPress
    * Have recipes to quick start
    * Has all developer need in local development: Mailhog, nice url and so on…
    * For each project its own conf
    * Super easy to change project php version and so on
    * cross platform

    CLI is also so intuitive that you don’t even want GUI 🙂