by Adam Brett

Vagrant Revisited

This article was published on Friday, August 15, 2014 which was more than 18 months ago , this means the content may be out of date or no longer relevant. You should verify that the technical information in this article is still current before relying upon it for your own purposes.

It's been over 18 months since I wrote the most popular post on this blog to date. That post is still receiving over 2000 new visitors every single month despite being horribly out of date. Vagrant and Chef have both moved on a great deal, and the provisioning tool landscape has changed quite significantly too, so it's probably time I wrote a follow-up.

If you haven't read my original post on Vagrant, I suggest you start there and quickly skim it for the key terms, as I will be building on and updating that knowledge here.


If you still haven't started using vagrant yet, why not? It just continues to get better and is now a fairly standard part of every developers setup. If you aren't familiar with Vagrant, think of it as a command line script for controlling virutal-machines.


When I first wrote about Vagrant, it could only control one type of virutal-machine, VirtualBox, since then they have introduced the concept of Providers. A provider is an interface between Vagrant and the software that runs your VM.

Currently Vagrant supports VirtualBox1 (default), VMWare2 (commercial), Docker3, Hyper-V4, AWS5 and DigitalOcean6, or you can write your own custom provider. Make sure you have Vagrant and VirtualBox installed before you continue, both are fairly straightforward to install and you will find instructions on their respective websites.


Just like back then, vagrant still relies on baseboxes, which are kind of like empty virutal machine images, or snapshots taken immediately after you've installed the Operating System. Unlike 18 months ago, when the only Provider was VirtualBox, a basebox now has to have been built for your specific provider. A VirtualBox basebox won't work on VMware and vise-versa.

Hashicorp, the company behind Vagrant have also released a SaaS product for hosting baseboxes7. You can host open source boxes for free, and some linux distributions maintain their own boxes there8, or have plans910 to do so, so that's a good place to start to find baseboxes that match your environment.

An added bonus of Vagrant Cloud is that it will take care of chosing the right box for your provider for you, so if the box you want is available for your provider Vagrant Cloud will automatically download the correct one and you don't have to worry.

On Vagrant Cloud, boxes are namespaced with the username of the user that created them, that means that now, instead of referencing "precise64", you would reference the box as "ubuntu/precise64" or "hashicorp/precise64" depending on whether you want the version from ubuntu themselves, or from hashicorp.

Key Command (to add a new box):

vagrant box add hashicorp/precise64

The old method of adding a box from a url still works, it's just not as widely used. Vagrant Cloud is easier as it provides a single source for all boxes rather than having boxes scattered around various URLs and private Dropbox accounts that can't necessarily be trusted.


Vagrant still requires a Vagrantfile, which is a basic Ruby file which provides all of the config settings for your project. You can quickly and easily create a Vagrantfile for your project by running:

cd ~/projects/my-project
vagrant init <boxname>

Where <boxname> is the name of the local box or Vagrant Cloud box that you want to use, e.g.:

vagrant init hashicorp/precise64

This will generate a Vagrantfile wherever you ran that command. There will be a lot of lines commented out, you can safely ignore them all, all you really need to get started are the uncommented lines:


Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| = "hashicorp/precise64" :hostonly, ""

The only change here is that we've kept the previously commented out line for, as you will probably want an IP Address for your new VM.

You can mount additional directories from the host Operating System in your new VM here too, but the directory that holds your Vagrantfile will always be mounted in the VM at /vagrant, which is usually enough for most basic purposes.

Key Commands

The key commands for Vagrant haven't changed since my original post, so you can read about those here.


Baseboxes are just that, a base for you to build on. They're usually empty and need to be provisioned before they will be useful for you. One key difference between now and the original post is that the commands vagrant up and a vagrant reload don't automatically provision your box for you. vagrant up will only run the provisioning step the first time it's run, on subsequent runs provisioning will not be run.

If you ever do want to run your provisioning step again you should make sure the VM is running with vagrant up or vagrant reload and then run vagrant provision as a separate step once it's loaded.

You can also simulate the old behaviour by adding the --provision flag to the up and reload commands like so:

vagrant up --provision
vagrant reload --provision


Hopefully this quick update will allow all of those reading the original post to get started using the latest and greatest of Vagrant tools. The amount of code and time required to get up and running with Vagrant has gotten considerably smaller, and the already shallow learning curve shallower and shorter.

Vagrant has moved on a great deal in a short amount of time, and that's the sign of a great project and a great community around it. I'm sure there will be more great things to come in the next 18 months too.

For exclusive content, including screen-casts, videos, and early beta access to my projects, subscribe to my email list below.

I love discussion, but not blog comments. If you want to comment on what's written above, head over to twitter.