Ship a Vagrant configuration with each project, and every developer will work on the same environment locally. So what is actually the point? The main argument is the consistency of the environments among developers working on the same project, and more importantly that these environments reflect the production ones. As its support is shipped with Vagrant, we will use VirtualBox, but others exist.

It relies on a VM provider, that deals with virtualization itself. Vagrant is a VM manager, in the sense that it reduces the management and the configuration of VMs to a handful of commands. All inside your own machine (which is then called the host).

To understand what a Virtual Machine (VM) is, think of an emulator: you install it on your computer so you can then run software that believe they are running in the environment they were designed for. Vagrant greatly simplifies the use of Virtual Machines to spawn development environments in no time (well, it's probably more like no effort than time). Access the host machine when using a private network.In case of trouble, don't hesitate to refer to it. The final result of this tutorial is available as a Github repository. The point of Vagrant is precisely not to have to worry too much about it. This is indeed written from a web developer's standing point, and I will not spend too much time describing how things work under the hood (not that I am an expert anyway). This article shows how to quickly get up and running with Vagrant, to create and use local Virtual Machines as development environments, all with a single command. Heads-up!While Vagrant served me well for years, I do not recommend using it for local development anymore and advise to use Docker instead, for which I wrote an entire tutorial series which I invite you to read. You can also subscribe to the RSS or Atom feed, or follow me on Twitter.

Vagrant up provider virtualbox