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.
#! #! #!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 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.
#! #! #!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, 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…
#! #! #! #!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, 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
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
tinyrick.dev, your InstantWP urls will look more like
http://127.0.0.1:20080/wordpress/ 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!