Update 10/20/2013: This was a great intro post to using Vagrant for WordPress development. If you’d like more, see my talk from WordCamp Vancouver, also titled “Hi WordPress, Meet Vagrant“, as well as the accompanying slides and context. Also, I called out WordPress.com at the end of this post with the hopes that a Vagrant environment could be built for that environment as well. Automattic came through with the VIP Quickstart repository, which is coming closer and closer to the WordPress.com environment every day.

Over the last few months I’ve been planting seeds with every WordPress developer I run into with the hope of convincing them to use Vagrant to manage their development environment. The basic pitch has evolved with time and now that I’ve had the chance to fine tune it for 10up’s recent developer summit, I’m going to lay it out here as well.


It helps to start with what we’ve been working with so far. The first step to developing for WordPress is to make sure your environment meets the minimum requirements. As of today, these are PHP 5.2.4 and MySQL version 5.0 or greater.

The beginning of WordPress development was often like the wild west. Cowboys abound, PHP files were edited in some form of a text editor and uploaded directly to the server for testing. White screens were a good indicator when things went wrong.

As familiarity with WordPress, PHP and MySQL progressed, local LAMP environments arrived. Apache, PHP and MySQL all had binaries that could be installed in Windows or Mac and a basic development environment could be setup with relative ease. White screens now happened locally first and more rarely in production.

MAMP, XAMPP and WAMP came along and provided a few click method of creating a stable LAMP sandbox for us to play in. With the minimum requirements for WordPress development met, things got stable and stale.

Meeting Environment Requirements

Rather than meeting minimum requirements, Vagrant provides a flexible way for a developer to meet environment requirements.

How about a server running Ubuntu 12.0.4, nginx, PHP-FPM, MySQL, memcached and the PECL memcache extension? Vagrant does that.

And CentOS 6.4 with nginx, PHP-FPM, MySQL, memcached and the PECL memcached extension? This too.

Or Debian 6 with page caching provided by Varnish or Redis… Can also do.

But wait.. still working with that project hosted on Apache, MySQL and PHP?

Vagrant does that.

This Matters?

This matters. The closer you can be to your production environment during development, the more confident you can be that the code you are pushing has been tested properly.

When that tricky cache expiration issue appears, the tools will be immediately available to confirm and troubleshoot it. When somebody on your team needs to jump in to help on a project, only a couple commands stand between them and a full matching system.

And at the end of the day, when you are done with development, one command powers off this amazing virtual environment and leaves you with a personal computer.

Go Try It and Chime In

10up has a pretty decent setup going over at Varying Vagrant Vagrants. A walkthrough from a few weeks ago is up at Evolving WordPress Development With Vagrant. We’re continuing to cruise ahead with a common nginx, MySQL, PHP-FPM and memcached setup, but we’ll be branching off to our other environments shortly as well. If you have an environment you’d like to see matched, fork the repository and give it a go.

And If Your Name Is Mo Or Barry…


What we have in our default provisioning so far is pretty close to a basic version of the WordPress.com server environment. We would love to help create a Vagrant setup that matches production as closely as possible and can be used by anybody developing a project with that in mind. Ping me when you’re game. :)

Cache issues be gone!