Jeremy Felt

Evolving WordPress Development With Vagrant

Yesterday we tagged version 0.2 of Varying Vagrant Vagrants, an evolving Vagrant configuration with an end goal of providing a system to pass development projects between team members at 10up for easy ramp up on projects. While any development project can be supported, our initial focus is WordPress. If you’re doing any kind of WordPress development, you should check it out. If you check it out and you fall in love, you should think about working with us.

UPDATE 04/12/03: This post is a great intro and provides good context  for the overall Vagrant discussion that’s been happening. Quite a bit has changed in the last few weeks and I would recommend stopping by Hi WordPress, Meet Vagrant for some of the latest fodder. Thanks!

What is Vagrant?

Vagrant is an open source “tool for building and distributing development environments”. Created by Mitchell Hashimoto, it provides a method to automatically provision a headless virtual machine for use with virtualization software such as VirtualBox. The various configurations of these virtual machines are sandboxed away from your local machine.

What is VirtualBox?

VirtualBox is open source virtualization software from Sun Microsystems. It provides a method to handle these prepackaged virtual machines, or boxes, that are configured with Vagrant.

What is Varying Vagrant Vagrants?

Varying Vagrant Vagrants is an exploration into the world of of Vagrant and how it can help to make development efficient and in sync with production systems. It replaces the common MAMP or XAMPP setups that we have become familiar with and ensures that all members of the team can develop in the same environment for a project without worrying about the operating system on their local machine.

One development environment is currently provided with Varying Vagrant Vagrants.  This includes Ubuntu 12.0.4 with Nginx, PHP-FPM, MySQL and Memcached. While this does not match every production environment, it has become a very common setup for highly scalable WordPress sites. It is these sites where developing in sync with production can be the most important. The closer we can come to matching the exact environment, the more likely we are to catch bugs and environment specific situations before deployment.

How Do I Get Started?

Getting started is easy, and will more than likely take you less than 30 minutes.

  1. Download and install the latest version of VirtualBox for your operating system.
  2. Download and install the latest version of Vagrant for your operating system.
  3. Clone or download the Varying Vagrant Vagrants repository to a local directory.
  4. Navigate to the new directory and type `vagrant up`

With that, your virtual machine is running. Test it immediately by going to in a web browser. To start working with WordPress, one more step is necessary.

  • Modify your local machine’s hosts file so that `` is mapped to ``.

Once mapped, visiting `` in your browser will bring up an initial WordPress installation. Follow through that to create your first WordPress development environment in Vagrant. Themes and plugins that you are developing can go into the respective `www/wordpress-default/wp-content/` directories.

From here, you should experiment.

If you are familiar with object caching, the common plugins for working with PECL memcache can be installed. Memcached itself is already installed and running for when you’re ready.

If you start poking around the internal documentation for Varying Vagrant Vagrants, you’ll see quite a few places where you can hook in with customizations of your own to continue to extend the development environment.

What’s Next?

Two goals are driving the development for the next releases of Varying Vagrant Vagrants.

  1. Provide a way to start with one of multiple WordPress configurations. Multisite is an obvious addition, but it would also be nice to include configurations for object caching as well as helpful development plugins.
  2. Provide a way to pass projects around with a Vagrantfile and WordPress configuration included that can help others jump in to assit immediately.

Please feel free to pass along any feedback or issues with the current release via the GitHub issues page. Any input is much appreciated!

If you want to geek out on some context for my Vagrant experience so far, check out these posts:

Responses and reactions


akismet-af63aa5537a2e60af1a1f8a89d461cfe replied on 

Sorry for this late comment (and question)! After doing local dev in the usual way for deployment on Red Hat's OpenShift for over a year (which is great, by the way), I need to set up several sites that will be more traditionally hosted. Setting up Xampp and MAMP again ( I use several machines in different locations), or the individual modules is okay, but it's just not quite right! The local setup never matches the production site anyway. Vagrant sounds like something I've been searching for for quite a while (although I don't reallu understand yet), but I do have a question, if it's okay. Can this be set up now to work effectively with existing working sites now? Sorry for the noob question! Thanks in advance, and I'll keep reading -- Jon.

jeffrose replied on 

Hi Jeremy:

I saw your talk at WCYVR on Saturday and today got brave and installed Vagrant and VVV. It works so amazingly well.

Thanks for sharing that! SSH and all the *nix tools are new to me, but I'm looking forward to learning.

Jesse replied on 

One issue I'm having is dealing with uploads(Media) in WordPress in conjunction with Vagrant. Usually this is just a simple permissions issue, no matter what I do (chmod -R 777 wp-content/ or change ownership with chown) Wordpress is still unable to create the upload directory and upload content.

Any thoughts?

Phill Coxon replied on 

Hi there. I've just discovered Vagrant and I'm liking what I'm seeing so far. I've installed a copy of Varying Vagrant Vagrants and have it running locally - awesome!

The main question I have relates to the domain name for development vs production. How are you handling database transfer between development and production? Manually modifying the database to replace the URL in tables & serialized data?

Or are you setting up a local vagrant dev environment with the production url and updating the hosts file? That would certainly make transferring the database between development & production super easy.

Thanks for your work on this so far - can't wait to put it to use once I fully get my head around it.

    Jon Jennings (@JonJennings) replied on 

    Traditionally, I've always used the script here: to convert databases from dev/staging to live. There are also a couple of plugins out there that I've heard recommended... you install them on the dev site & they create a backup file that's been pre-tweaked to use the live site's URL.

    Running locally, putting the live site URL in your hosts is a neat trick... unless you need to refer to the actual live site for any reason :-)

Leave a Reply

Your email address will not be published. Required fields are marked *

The only requirement for your mention to be recognized is a link to this post in your post's content. You can update or delete your post and then re-submit the URL in the form to update or remove your response from this page.

Learn more about Webmentions.