In my last article, I reviewed the best WordPress development environment apps out there. But that’s not all of it, there are a number of great options available as well for those of you who would prefer a CLI-based local development environment as opposed to using an app. Personally, I’m running a mix of both CLI and app based environments for my dev environment these days depending on the project I’m working on.
This time around, I looked at a few different CLI-based local environments for WordPress development. There was no special criteria for choosing the options here, I just searched through some popular tools for CLI-based dev environments and tried those. If you feel I should’ve included any other development tools or if I missed anything exciting, please let me know in the comments section.
Not to be confused with the incredible game, VVVVVV, VVV (Varying Vagrant Vagrants) 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 website 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.
__ __ __ __ __ __ ____ \ \ / / \ \ / / \ \ / / |___ \ \ \ / / \ \ / / \ \ / / __) | \ \/ / \ \/ / \ \/ / |__ < \ / \ / \ / ___) | \/ \/ \/ |____/
Getting started with VVV
Installing VVV is really straightforward, once you’ve got Vagrant and VirtualBox installed, which is available for all major platforms including Windows, Mac, and Linux, just clone their repo (or download it), simply run
vagrant status to generate config files which will essentially copy the
config/default-config.yml file to
config/config.yml, then update it with the sites you’d like to run and any specifics like PHP version, utilities, etc. then run
You’ll probably be up and running after a few minutes of it installing a bunch of files. While it installs the files, it would be a good idea to see what lies in configuration files, though do note that any changes made to it would require you to reload Vagrant, which can be done with
vagrant reload --provision.
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
config/config.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 their detailed docs.
So long as you can get Vagrant and VirtualBox installed, VVV is a pretty solid choice for running local WordPress dev 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 your 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 web 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.
#! #! #!Three shebangs.
One for every
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 whereas 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. If you’re developing a WordPress plugin, a WordPress theme, or website with a team (or even if you’re just using multiple computers yourself), all anybody needs to do to jump into the 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 that you’ve installed VirtualBox and Vagrant, then simply clone Chassis off of their git repository. Note that you’ll need to pull in the submodules inside the repository, which can be done by simply running
git submodule update --init.
After cloning and updating submodules, simply run
vagrant up to boot up the environment. Next up, you’d need to copy the contents of
local-config-sample.php over to
local-config.php where you’ll be making configuration changes. That’s it, you should have your site up and running now.
At this point, I feel 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. It’s one that might be a bit more in line with how I tend to do things, as each install is self-contained, 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.
#! #! #!Three shebangs.
One for every
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. 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.
Valet is more like 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. Plus, 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 a new WordPress installation 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. 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 local 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. You can also switch PHP versions on the fly, switching MySQL versions isn’t as easy, however.
For my money, Valet (Plus) is the best option I’ve explored so far. It 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…
#! #! #! #!Four shebangs.
I primarily like the fact that it’s Mac only.
Devilbox is kind of like VVV meets Valet. It runs using Docker containers rather than Vagrant. 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. Though their documentation is pretty extensive, so at least that’s a good thing.
Like Devilbox, Lando previously known as Kalabox, also runs in a Docker container. Lando comes with pre-packaged installers for each major platform including Windows, Mac, and Linux.
Before you can get started with using Lando, you’ll need to run a few commands that can easily be found at their homepage. You can also find a recipe for WordPress development environment to quickly get started.
Lando also makes it really easy to set up tooling services like Node, Grunt, Gulp etc., you simply need to adjust your
.lando.yml configuration file accordingly. It also comes with pre-installed WP-CLI so you won’t have to worry about SSH access to your working directory, you can simply run
When it comes to CLI-based tools for running local WordPress development environments, there are way too many tools available to count. A lot of these tools are too similar to each other as they’re basically a fork with some changes made to fit in a specific workflow. Personally, I’d prefer a tool that’d make switching between PHP and MySQL versions easier, one which makes installing WordPress faster without having to go for a walk before it is ready to use. For me, Valet Plus fits the bill.
Which one you choose or choose to fork is really up to your personal preferences and/or the needs of your project.
As a WordPress developer at Delicious Brains, I like to have a lot of different development sites to test different scenarios with different versions of PHP and MySQL. I also usually just nuke sites after I’m done running through those tests. Something like Valet Plus or Local by Flywheel (acquired by WPEngine) 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 environment solution is the perfect one for you and why? Let us know in the comments section!
This article was originally written by Jeff Gould in 2017 and has since been updated.