HashiCorp Vagrant

A command-line tool that builds the same development virtual machine for everyone from a Vagrantfile kept in the repo.

What it is: Virtual machines
Type: Commercial product
Made by: HashiCorp, an IBM company
License: Business Source License 1.1 since Vagrant 2.4.0 (October 2023; source-available, not OSI open source); MIT before
Facts checked: 5 October 2026

What it is

You commit a Vagrantfile to the project: a short Ruby file, mostly plain assignments, naming a box (a packaged base image such as bento/ubuntu-24.04), the CPUs and memory, forwarded ports and provisioners. vagrant up downloads the box if it isn’t cached, asks a provider to create the machine, connects over SSH, mounts the project folder inside it at /vagrant as a synced folder, and on first boot runs the provisioners: shell scripts, Ansible, Chef, Puppet and others. VirtualBox, Hyper-V and Docker providers ship with Vagrant; VMware Fusion and Workstation need HashiCorp’s open-source plugin plus the VMware software, and libvirt/KVM a community plugin. Vagrant records which real machine belongs to the project in a .vagrant directory, so vagrant ssh, halt and destroy know what to act on, and one Vagrantfile can describe several machines, such as a web server and a database.

Vagrant is mature and changes slowly. It moved from the MIT licence to the Business Source License with 2.4.0 in October 2023; the latest stable release is 2.4.9 from August 2025, with only nightly builds since. HashiCorp is also shutting down HCP Vagrant, the hosted box catalog that replaced Vagrant Cloud: no new boxes since October 1, 2026, and the service closes on December 31, 2026, after which box owners must host box files themselves. For everyday app development, many teams now use a dev container instead: a container described by a devcontainer.json file, supported by VS Code, GitHub Codespaces and other tools. Vagrant still fits when you need a whole machine: a different operating system or kernel, Windows or BSD guests, or a multi-server setup to test provisioning scripts.

Why teams pick it

One command, vagrant up, gives every developer the same provisioned VM from a file in version control
Provisioning reuses real tools (shell, Ansible, Chef, Puppet), so the scripts that build production can be tested locally
Full virtual machines: other kernels, Windows or BSD guests, and multi-machine topologies that containers can’t imitate
Swap the provider (VirtualBox, Hyper-V, VMware, Docker, libvirt) without changing the workflow

Watch out for

No longer OSI open source since 2.4.0; the BUSL blocks building a competing commercial product on it
HCP Vagrant, the public box catalog, closes on December 31, 2026; shorthand names like bento/ubuntu-24.04 resolve against it, so teams need their own box hosting and config.vm.box_url
Slow release cadence: no stable release since 2.4.9 in August 2025
Full VMs are heavier and slower to start than containers; on Apple silicon, VirtualBox runs only Arm guests, so you need boxes built for arm64
The default synced folder doesn’t work on every host and guest combination; NFS, rsync and SMB synced folders are the alternatives, each with its own trade-offs

Alternatives

What all virtual machines have in common →

Amazon EC2AWSAWS’s virtual machines: pick an instance type, boot an image, and you have a server in minutes.

KubeVirtOpen sourceAdds virtual machines to Kubernetes as ordinary resources, so VMs and containers share one cluster, one API and one set of tools.

How it fits with other technologies

What HashiCorp Vagrant uses

HashiCorp Vagrantcan run environments as containers withDockerContainers

What uses HashiCorp Vagrant

An Ubuntu VM provisioned with a shell script, then booted · bash

cat > Vagrantfile <<'EOF'
Vagrant.configure("2") do |config|
  config.vm.box = "bento/ubuntu-24.04"
  config.vm.network "forwarded_port", guest: 80, host: 8080
  config.vm.synced_folder ".", "/vagrant"   # the project, inside the VM

  config.vm.provider "virtualbox" do |vb|
    vb.cpus   = 2
    vb.memory = 2048
  end

  config.vm.provision "shell", inline: <<-SHELL
    apt-get update
    apt-get install -y nginx
  SHELL
end
EOF

vagrant up          # download the box, create the VM, run the provisioner
vagrant ssh -c 'curl -s localhost | head -n 4'
vagrant destroy -f  # throw it away; vagrant up rebuilds it identically

Providers#

A provider is what actually runs the machine. The Vagrantfile stays mostly the same; boxes are built per provider and, since 2.4.0, per CPU architecture.

	How you get it	Notes
VirtualBox	Built in; VirtualBox installed separately	The original and default provider. VirtualBox 7.1 added Arm Linux and BSD guests on Apple silicon Macs; Vagrant supports 7.1 from 2.4.2 and 7.2 from 2.4.9.
Hyper-V	Built in since 1.5 (2014)	Windows 8.1 and later, with Hyper-V enabled.
Docker	Built in since 1.6 (2014)	Runs the environment as containers; where Linux containers can’t run natively, Vagrant starts a host VM for Docker.
VMware Fusion / Workstation	Official `vagrant-vmware-desktop` plugin plus the Vagrant VMware Utility	The plugin is open source (MPL); the VMware product is a separate install.
libvirt (KVM, QEMU)	Community `vagrant-libvirt` plugin	For Linux hosts; its last release was 0.12.2 in June 2023.

Vagrant or a dev container?#

Vagrant

a whole VM

Pick it when the environment must be a real machine: a specific OS and kernel, Windows or BSD guests, several networked servers, or testing Ansible, Chef or Puppet code before it touches production.

Dev container

a container

A devcontainer.json in the repo describes a container to code in. It is an open specification supported by VS Code, Visual Studio, IntelliJ IDEA, GitHub Codespaces and others, and suits most application work that runs on Linux.

Plain Docker Compose

services only

If you only need the databases and queues an app depends on, a Compose file starts them as containers next to your normal editor, with no VM or dev environment at all.

See it in a real stack

No architecture uses HashiCorp Vagrant yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2010–2026

Around 2010, web developers ran every project’s databases, queues and web servers on their own laptops, each at its own version, and teammates drifted apart: one on MySQL, another on PostgreSQL. In production, virtual machines on EC2 and similar clouds were already the norm. Vagrant’s early guide said it aimed to put “those very same principles” to work in development, with lightweight, reproducible virtual machines anyone on the team could rebuild.

Mitchell Hashimoto and John Bender started Vagrant on January 21, 2010, and released 0.1.0 on March 7 as a Ruby gem that drove Sun’s VirtualBox and provisioned machines with Chef or Puppet. It was a volunteer project, “not backed by any single company”. Vagrant 1.0 came out in March 2012, the year Hashimoto and Armon Dadgar founded HashiCorp, which went on to build Packer, Terraform and Vault alongside it.

Vagrant 1.1 in 2013 added providers, so the same workflow could drive VMware and other backends, and dropped RubyGems for installers that bundle Ruby. Vagrant 1.5 in 2014 launched Vagrant Cloud for sharing versioned boxes. In 2023 Vagrant moved to the Business Source License, and in 2026 HashiCorp began shutting down the hosted box registry, leaving the CLI as a self-hosted tool.

Why it’s built this way

Configuration as a Ruby file in the repo: One Vagrantfile per project, committed to version control, means every developer who clones the repo gets the same machine. The syntax is Ruby, but most files need little more than variable assignments, so users don’t have to know Ruby.
Reuse existing provisioning tools: Vagrant “stands on the shoulders of giants”: VirtualBox ran the VM and Chef or Puppet set it up, so developers got environments built by the same scripts used for production.
Providers as plugins: Vagrant 1.1 separated the workflow from VirtualBox so the same commands could manage VMware, Hyper-V or Docker as well.
Installers instead of a Ruby gem: Hashimoto found that most Vagrant users weren’t Ruby developers and many bugs came from broken Ruby setups, so from 1.1 Vagrant shipped as packages with Ruby and its libraries bundled.

Timeline

2010
Started in January; 0.1.0 released in March for VirtualBox
2012
Vagrant 1.0 in March; HashiCorp is founded
2013
Vagrant 1.1 adds providers and native installers
2014
Vagrant 1.5 launches Vagrant Cloud; 1.6 adds the Docker provider
2017
Vagrant 2.0 released in September
2023
Vagrant 2.4.0 adds box architectures and moves to the BUSL
2024
Vagrant Cloud is migrated into HCP Vagrant Registry
2026
HCP Vagrant stops new boxes in October and closes December 31

Sources31 · facts checked 5 October 2026

Improve this page on GitHub