I've been using VirtualBox for many years to create a development environment.

A lot of my colleagues are talking about Vagrant and many people seem very excited about it but I just can't seem to grasp the benefits of it.. seems to me like it's a series of new commands to learn in order to do the same things I did with Virtualbox.

With VirtualBox, I install and configure an environment perfectly, then I can package it up as an OVA or whatever and share it with other office users. You can take a snapshot in VirtualBox if something goes wrong.

Puppet and chef aren’t really part of Vagrant, they’re their own thing right?

So yes, what benefits specifically does Vagrant offer over VirtualBox on it's own?

  • 18
    Two years on I'm now using Vagrant every day for development - it's great! My team uses it and it's solved our dev environment issues.
    – John Hunt
    Feb 10, 2016 at 10:04
  • 3
    I also found vagrant far more useful in a multi-developer team whereas previously it was just me. I imposed vagrant on my team and discovered that's where the value comes in.
    – John Hunt
    May 6, 2016 at 10:53
  • 11
    4 years on and I've discovered docker is terrible. Long live Vagrant.
    – John Hunt
    Feb 5, 2018 at 15:00
  • 4
    5 or 6 years on, I've discovered I have to use docker because everyone else does. The new shiny stuff isn't so shiny in reality.. I don't feel people ever really got to grips with the old stuff yet.. However, it does have its place.. Being able to spin up a quick dev LEMP stack is quite nice
    – John Hunt
    Jan 14, 2019 at 10:54
  • 7
    7.5 years on, actually Docker is OK - a steep learning curve and the whole thing was off to a very rocky start. Now I just have to learn about K8S etc.. sigh.
    – John Hunt
    Oct 19, 2020 at 8:53

5 Answers 5


This is a big question, so I'm going to break it up into three sections.


Vagrant is used to set up one or more virtual machines by:

  • Importing pre-made images (called "boxes")
  • Setting VM-specific settings (IP address, hostnames, port forwarding, memory, etc.)
  • Running provisioning software like Puppet or Chef

Note that it doesn't install software or set up the machine past loading the VM and setting VirtualBox settings. Think of it as a scripting engine for VirtualBox.

Here are some reasons I've seen for using Vagrant over just VirtualBox.

1. Set Up Multi-VM Networks with Ease

Most of the Vagrant power-user content I've read has been about setting up multiple VMs at the same time. Vagrant gives you a single config file to set these up, enabling you to launch all of them with one command.

Say you've configured three VMs to network with each other using static IPs on the 192.168.1.* subnet. You find yourself in a location that is already using that subnet to hand out IP addresses, and your VMs now conflict. With Vagrant, you can simply edit the Vagrantfile and reload the VMs, whereas with VirtualBox you'd have to open the settings for each VM, if not boot each VM and change them inside.

2. Source Control

By putting the settings in a text file, it enables the configuration to be put under source control. Made some changes last week and accidentally broke the image? Just revert the changes and reload the VM. You can accomplish this with VirtualBox snapshots, but it will take up much more space than just a Vagrantfile.

3. Various Platforms

There's a large number of boxes available at sites such as http://vagrantbox.es. This enables you to try various OSes or distributions, applying the same provisioning to set up similar environments. This can help with testing or adding support to new platforms, and would be time-consuming using just VirtualBox.

There are a lot of arguments for using provisioning software, as well as using image snapshots. For additional discussion, I'll point you to Stephen Nelson-Smith's excellent article How to Build 100 Web Servers in a Day.

  • 8
    Still, I do not understand why I should use vagrant in development environment! Because, it's expensive ( if you want to use VMWare! ) We can prepare a virtual machine like base boxes which is used by vagrant then get clone by VMware to setting up another virtual machine. First and foremost, we can control all virtual machine settings by vmrun command that offered by VMware even IP address changes or running a script inside the guest machine! Jul 14, 2014 at 8:33
  • 3
    @OğuzÇelikdemir That's a fair point. Vagrant just puts an easier front-end to VMWare with regards to bringing up a new machine. Behind the scenes, it's using vmrun to control it. I had always used VirtualBox, and thus don't have any experience with the VMWare backend. Jul 17, 2014 at 19:34
  • 2
    @AdamLukens, Thanks for the detailed comments. What you mentioned sounds interesting.. but I wonder if you are aware of the VboxManage command? virtualbox.org/manual/ch08.html Pretty much everything you mentioned can be created as a script by passing the specific ip/parameter to vboxmanage controlvm or a similar command in a shell script and then version control that.. So how does vagrant improve over virtualbox?
    – alpha_989
    Mar 6, 2018 at 15:33
  • 1
    @alpha_989 I agree. There seems to be no unique point for using Vagrant. Just for convenience. Apr 23, 2018 at 8:47
  • @alpha_989 I understand that the main advantage of Vagrant over the VirtualBox cli would be that Vagrant can also use "providers" other than VirtualBox (in case one needs to change).
    – MakisH
    Oct 9, 2020 at 14:42

In addition to the excellent answer given by Adam, Vagrant ties everything all together. Although Chef and Puppet (and Salt and shell scripts and whatever other provisioner you want to use) are separate things, Vagrant ties it all together and makes it work with just a vagrant up.

That one command will

  1. just start the VM if that's all that is needed, but it'll also
  2. create the box from your specified base box if that is also not done yet, but if you don't even have the base box on your machine it'll first
  3. fetch it from its URL and download it to your machine.

You don't have to think about all that. Let's say you're switching to a different project, one started by a coworker. You just checkout the code from your repo, and run vagrant up, not worrying about downloading ISOs or installing anything, or wondering which version of which distro you need to use for that particular client, or whether you have a copy of a VM that's already got everything you need.

You don't even need to worry about whether they've set things up using Chef or Puppet or just shell scripts. (Okay, so you might need to do a bundle install or otherwise make sure you've got everything installed, but still not a big deal.)

By tying everything together, and providing a unified interface for it all, it can make all but the simplest use cases much much easier. At first you may feel like you're just relearning a new way to do what you're already doing, but once you get deeper into Vagrant use you'll discover you can do much more with much less effort. It'll be well worth the initial time investment.

  • 13
    But it's a hell of a lot easier and faster for me to send a developer a presetup VM image than it is for them to install vagrant, learn how to use it, and deal with any of the myriad problems that come up, particularly when supporting windows boxes. I just really DO NOT get it, either. Seems to be nothing but fanboys.
    – hopeseekr
    Nov 26, 2014 at 1:40
  • 7
    Installing Vagrant is unbelievably easy these days. Anyone who can't install it can't possibly be trusted to write code. Having a Vagrantfile in your source code that the developer checks out is actually far easier than sending a VM. The Vagrantfile defines the setup, including the URL from which to download the base VM (which it then configures). If you don't initially need to make configuration changes, then you're all set. But as you work on your project, you'll likely need to make changes. Do that in your Vagrantfile.
    – iconoclast
    Nov 26, 2014 at 3:33
  • 6
    Since you're keeping the Vagrantfile with your code, all developers joining the project will automatically get the changes you make to your VM, since you're making them in the Vagrantfile. Configuring your Vagrantfile doesn't need to be difficult. You can use shell provisioning if you find the Chef and Puppet to be overkill (which they often are). If you can enter the shell commands in the VM, then it's a tiny hurdle to set up shell provisioning commands in the Vagrantfile. It will take a small up-front effort and save you lots of headaches in the long run.
    – iconoclast
    Nov 26, 2014 at 3:33
  • 5
    and when you need to change something on all 50 computers?
    – iconoclast
    Nov 2, 2015 at 17:02
  • 8
    The discussions here are really about premature optimisation. Dont use vagrant if you dont need it. Use vagrant when you find creating VMs is becoming tedious.
    – cammil
    May 27, 2016 at 8:57

Here are two more developer use-cases that vagrant simplifies (over "plain" VirtualBox). I didn't see these use-cases called out specifically in the previous answers.

  1. Vagrant helps with the aim of keeping the development and production platforms as close to each other as possible. In an ideal world, you would provision the production environment with THE SAME scripts used to provision the Vagrant VM, minimising surprises at deploy time.

  2. Integration tests and continuous integration: Vagrant is easy to control from tests, and therefore entire multi-machine stacks can be easily controlled from tools such as Jenkins when doing test runs.

Yes, "plain" VirtualBox can be used here too - but the conventions used by vagrant make it more simple to set these scenarios up.

  • 1
    I seriously just copy the vmx and vmdk from Windows to Linux. Maybe it's different in the virtualbox world, but I doubt it! What's easier? Copying a file or messing with vagrantfiles and the myriad of problems that can go wrong?
    – hopeseekr
    Nov 26, 2014 at 1:42
  • 6
    To put a finer point on it, Vagrant can be thought of as a virtual definition language that can describe the characteristics of a virtual machine --independent of whether it is hosted under VirtualBox, VMware, Parallels, or what-have-you. See how Vagrant is not "competition to" VirtualBox, but works with it, or beyond it.
    – MarkHu
    Feb 14, 2015 at 4:36
  • One would typically use a Vagrantfile to describe how a virtual machine is to be set up for a project - the Vagrantfile would be committed to source control (git, etc) with the project, for sharing on GitHub etc. This is much smaller to download than an entire VMDK.
    – Ben XO
    Aug 1, 2018 at 10:05

Ability to integrate chef or puppet in with VM provisioning is key. Most Vagrant users will tell you they run 'vagrant provision' and occassionally 'vagrant reload' much more often than 'vagrant up' or 'vagrant destroy'. These tasks indicate the real work is not in spinning up/down VMs but 'managing' them after the fact.

To pose a better question (posed by proficient Chef users, anyway) might be why use Vagrant and not knife with the appropriate plugin (will get to virtualbox plugin, in a moment)? For instance, passing argument values stored in a data bag to a knife plugin is (way) more intelligent, flexible and manageable than juggling one giant Vagrantfile. I typically define my 'dynamic' resources like # of CPUs, amount of memory, which OS to deploy, hostname, IP, routes, etc, in chef databag(s) such that I don't need to keep changing my recipe ;-). Editing a databag through Chef web interface is a really easy data entry task I can give to the most junior operators. With Vagrantfile, your forever modiyfing code and believe it or not - code breaks - which pretty much guarantees you'll NOT be handing off simple changes to Operations staff, ever.

Aside from the fact knife does not yet have a plugin for virtualbox (though I envision one in the not too distant future), there are already plugins for most 'enterprise' virtualization products, including vmware, xenserver and just about every major 'cloud' provider, as well. This means knife is far superior to what Vagrant offers if/when you are ready to move beyond virtualbox. For now, Chef community seems happy to let virtualbox users limp along with Vagrant by not integrating virtualbox apis for a knife plugin. There is a knife-vagrant plugin that does allow for use of data bags to pass arguments. But, it still requires vagrant software and it's monolithic Vagrantfile to function.

So, I'll go out on a limb and say Vagrant is definitely NOT 'better' than Chef with knife; but necesary (for now) if you insist on virtualbox and perhaps 'easier' than managing chef with data bags, provided you have a fairly simple environment to manage.


Vagrant abstracts virtual machines so it allows you to easily switch virtual machine implementations. You can switch from Virtual Box to AWS or Digital Ocean. It's like using SQL instead of a database-specific query language.

Vagrant allows developers to set up their environment quickly with only one command and it is exactly the same as everyone else's. This is important in large companies where developers come & go often. It can reduce time to setup from 3 days to 1 hour.

+ What Adam said.

(I still haven't found a use for Chef or Puppet though...)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .