We kicked a poll off three months ago asking y’all what kind of local development environment you set up for running WordPress locally. At the time of this writing, we got 2,623 votes, so a decent amount of significance here. Especially because the question was phrased:
If you’re running WordPress locally (i.e running PHP, MySQL, and a web server), how are you doing it?
Presupposes that you are running a local environment. (Please do that.)
Here’s an image of the results:

(If you can’t see that, don’t worry, we’re about to go through the results.)
The winner, at 61%, was using some kind of software-with-a-UI to manage it. WAMP / MAMP / AMPPS were mentioned, but it also said “Similar software with UI”, which I think is relevant as we’ll see in a second. This option was more than 3 times more popular than any other choice.
Vagrant was in second place at 15%. I’m sure some of that is direct usage of Vagrant, but also sizeable chunks toward pre-configured-for-WordPress projects like VCCW, VVV, or Scotch Box.
In third place was installing things directly at 13%. All these other options take at least some kind of stab at isolating the dependencies of local development. Meaning if you have multiple local development environments (very common), they don’t all need to share the same dependencies. This could be relevant even if you do all WordPress development. Perhaps one project is running PHP 7 and MySQL 5.7, but another is on some older hosting is at PHP 5.3 and MySQL 4. Matching those production versions in development is a good idea, so you can have some confidence what you do locally will work on production. Without any local isolation, you’re stuck with the same versions of everything across development environments. Might be just fine if you only work on one thing!
Docker was the penultimate choice at 7%. As hip as Docker seems to be, apparently it’s adoption amongst WordPress folks hasn’t caught on super strongly yet.
Gilbert Pellegrom has a great comparison of Vagrant and Docker:
The downside to [Vagrant] is that each virtual machine includes not only your application and all of its libraries but the entire guest operating system as well, which may well be tens of GBs in size.
Docker, however, uses “containers” which include your application and all of its dependencies, but share the kernel (operating system) with other containers. Containers run as isolated processes on the host operating system but are not tied to any specific infrastructure (they can run on any computer).
What is the upshot of all of this?
- Vagrant is easier to understand and is easier to get up and running but can be very resource-intensive (in terms of RAM and space).
- Docker’s architecture is harder to understand and can be harder to get up and running but is much faster, uses much less CPU and RAM and potentially uses much less space than Vagrant VM’s.
As a personal anecdote, I’m using Docker for all my WordPress stuff now (on my Mac), and didn’t find it particularly hard to set up or understand. One thing that bit me was not putting my MySQL stuff on a “volume” at first, which made the database susceptible to being wiped out when Docker rebuilt the container (but I have that fixed). I just followed this.
5% of folks voted “Other” and were asked to chime in in the comments. There were 63 comments, which is quite few for a CSS-Tricks post these days!
22 comments mentioned Laravel Valet, so I think that deserves and extra-special shout-out here.
Valet is a Laravel development environment for Mac minimalists. No Vagrant, no `/etc/hosts` file. You can even share your sites publicly using local tunnels…
Laravel Valet configures your Mac to always run Nginx in the background when your machine starts. Then, using DnsMasq, Valet proxies all requests on the *.dev domain to point to sites installed on your local machine.
In other words, a blazing fast Laravel development environment that uses roughly 7 MB of RAM.
There were also 8 mentions for Local by Flywheel (Mac and Windows), which looks like a nice UI for managing local WordPress development environments:

If you use Valet or Local, you could have either voted in the “Similar Software with UI” category or “Other” category, so in the grand tradition of CSS-Tricks polls, the data is a bit loose.
Great article & research! For the vagrant “downside” I want to point out that it is possible to use a vagrant machine that includes multiple projects. I have always used Vagrant this way for WordPress development and I’m still stunned many people build a new vagrant for each of their website projects, even though the system is always the same.
Right. Setting up virtual hosts is trivial, especially with Nginx.
I’m running Laravel Valet these days as well! So easy to use, mock HTTPS and share from local with a unique URL. In fact, I’m using it for most local development… not just WordPress. Definitely with checking out!
Loved using scotch-box for nearly two years, with some occasional VVV. However, Local by Flywheel (formerly Pressmatic) is the best thing since sliced bread. I could not reccomend it more, holy crap does it make life easy. Plus it’s powered by Docker!
+1 for Valet, I had a bit of trouble setting it up — and forget about it if you have a really old Mac – but now its just a matter of making a folder and a new database
We run a headless Ubuntu server in a VM, and port forwarding.
Docker on Windows is amazing. I haven’t worked out debugging yet, but it’s an insanely great way to launch the whole WordPress stack in a nice little box.
My cloudbook laptop doesn’t have the space to develop locally, so I use Cloud9, which has a nice proconfigured setup for WordPress projects.
I imagine Desktop Server is not a popular choice? Anyone want to share their Docker rigs here? Bonus points if it uses Swarm with a single Redis cache distributed across instances.
IMHO there is no real advantage for running something fancy like Docker over a simple (or advanced) Virtual Host-based environment. The more complex setups require a proper VM, ie. NOT sharing the kernel etc., because it is mostly that – the kernel differs extremely from normal, specific GNU tools are simply missing or not accessible, only FTP available, limited PHP modules etc. So at best, you may go with a Unix VM that allows for using kernels down to 2.6 up to current 4.8 (eg. ArchLinux, Manjaro, Debian Unstable). Though the worst case scenario is having to dutifully replicate the whole setup, eg. installing the very OS that is run on the remote live environment, etc.pp.
And no, not everybody lives in fancy “my client got a full server to play with” country. Actually I’m always quite amused, up to annoyed, with folks always claiming it would be THAT way and no other. Most small to middle-sized companies use simple shared hosting accounts, maybe a bit souped up in several cases, but nonetheless: A very reduced, resource-limited environment. Folks just want a site, not a whole bloody server. And they simply do not care what advantages some managed v-server, or a full-blown dedicated server might offer them: It’s a website, maybe a bit of responsiveness here, and a few products there, but thats it. Also, of corpse, its about the monthly maintenance costs.
Or maybe all the true hardworking developers just dont come here anymore or simply have given up to vocalize their thoughts, because all is happy npm + gulp + Docker country these days? I dont know.
BTT: VM where its needed. Seldom, but a proper fullblown VirtualBox or KVM VM is quickly setup, esp. if you’re using a template (ie. a VM image you’ve already prepared for such actions). Drop in everything you need, SSH or (worse case) FTP into it, develop it all on your own machine, and then happy rollout time!
Aside of that, I keep it to good ole XAMP – has been working reliable for ages. PHP + MySQL / MariaDB are always reasonable up-to-date, VHosts are easily done – also, a vhost-specific setup for specific jobs does help a lot, too – and setting up different kinds of debuggers are nice feat (though seldom used), too.
cu, w0lf.
Shameless plugin, but we’ve been building a free local development solution for WordPress called WPLib Box.
It is a single Vagrant box at the moment, but it is designed to “just work” (as much as we can make that true.) We are actively evolving it to use Docker internally and plan to convert it to multi-project soon.
Our goal is for it to become the most flexible solution available that “just works” for local WordPress development. And we plan to get rid of the need for VirtualBox and Vagrant as soon as technology allows us to do so and still make it “just work.”
If you are interested in giving it a try we have a free Slack channel where we offer support.