To get started, go ahead and install these tools:

• VirtualBox
• Vagrant
• Get a copy of both PuTTY and PuTTYGen here.

Now that you have it all set up, you can start your first Vagrant project by creating a project folder, which will house the various configurations for each of your VMs. You’ll use the command line to run Vagrant commands from within these folders.

Create your first project folder and call it C:\vm\test\.

Tip: As a Windows user, you can quickly open a command prompt to your project by holding down shift and right-clicking the project folder, then choose “open command window here”.

The only commands we need to get servers up and running are vagrant init and vagrant up.

Open a command line and change directories to your test project folder. Then, type vagrant init and a new vagrant file will be created in the current directory. Open and read that file, there are lots of comments you can study. You can set shared folders between guest and host, turn on port forwarding, set the hostname, and more.

Browse the Vagrant Cloud for user-created base boxes you can use. For this example, we’ll use “ubuntu/trusty64” which is the “official” base box for Ubuntu Server 14.04 LTS (Trusty Tahr). Delete the Vagrant file you just created, and type the following:

vagrant init ubuntu/trusty64

This time, if you open the vagrant file, you’ll notice it lists the base box in there.

Now that you have a vagrant file, you can spin up the VM with this command:

vagrant up

Vagrant will use the configuration in that vagrant file and spin up the VM for you.

To explain what’s happening here, Vagrant first imports the base box if you don’t already have it. It then checks if your box is up to date. You can see it sets up the SSH forwarding port as “2222” — you’ll need this to use PuTTY.

Lastly, you’ll see it checking for guest additions and mounting the shared folders between host and guest.

These base boxes live in your %userprofile%/.vagrant.d/boxes folder. You can list all installed boxes by typing vagrant box list. You can delete boxes with vagrant box remove box/name

Yes! Kind of!

You see, Vagrant has to be able to log in to the new server and perform additional provision, such as setting the configured IP, port forwarding, folder shares, VirtualBox Guest Additions, etc. In order to do this, all base boxes are required to have the Vagrant public key already installed, along with a user named “vagrant”, with password-less sudo privileges.

Once the VM is created, Vagrant will provide some output, which you should check for errors. See the previous screenshot. Most basebox installs won’t have problems, but advanced scripted provisions can sometimes run into trouble and will have hundreds of lines of text output during the provision process.

The problem we face now is that Windows doesn’t come with an SSH command line client. This means the built-in SSH functions of Vagrant won’t necessarily work for us Windows users. But that’s why we have PuTTY. Type this to get your SSH info:

vagrant ssh-config

It will tell you the IP and SSH port to use and a few other bits of info.

Even though many base boxes are barebones OSes, they do require an SSH server to be installed as one of the requirements of being usable by Vagrant. Most base boxes will have nothing BUT OpenSSH installed.

Open PuTTY, enter the IP and port, give the connection a name, and save it. You can now connect to the new server over SSH with PuTTY. The username is “vagrant” and the password should be “vagrant” as well, but this can be individualized to the base box in special cases. Vagrant doesn’t care about passwords so much, because base boxes are required to have the pubic key installed and Vagrant uses that method rather than a password. And so can we.

Note the different port number than what is in the earlier screenshot. Vagrant will automatically choose another port if the default is taken. All your VMs will get a new port, so be sure to note which VM is which!

Side note: You can install a Windows SSH client, such as Cygwin or MinGW. Even Git comes with an SSH client. Type vagrant ssh and see what happens! Linux and Mac users should already have SSH clients.

You can use the same public key Vagrant does and install it to your saved PuTTY connection. However, PuTTY cannot use the OpenSSH style key. This is why we downloaded PuTTYGen, so open that now.

Click “Load” and browse to the %userprofile%/.vagrant.d/ folder and you’ll see the “insecure_public_key” file. Open that.

You can immediately click the “Save Public Key” button. This will create a file with a “.PPK” extension. Name it “insecure_public_key.ppk” to match the other one. You can close PuTTYGen and go back to PuTTY now.

In PuTTY, load your connection to the new server or type it in again if you didn’t save it. Then go to Connection→SSH→Auth in the sidebar and click “Browse” to find the private key. You will see the PPK version but not the other one since PuTTY doesn’t use that type. Now be sure to save your configuration so you can keep using it later.

With that done, the next time you open this connection and type “vagrant” as the user, it will automatically authenticate with the key and you will be logged in without having to type the password.

You can also create your own secure public/private keys with PuTTYGen and replace the vagrant key but that is beyond the scope of this article. You would need to paste the key into the ~/.ssh/authorized_keys file as well as make an edit to the vagrant file.

The vagrant file is where all configuration takes place. This file is meant to be managed by a version control system, and is how you would share your development setup with a team. If everybody uses the same vagrant file, they’ll get the same VM setup with the same boxes and provisions. Note that scripts can be called external to this file, meaning some complex vagrant projects could have many files and folders.

You can use VirtualBox to see any VMs you have made, but you don’t actually have to open or use VirtualBox at all when using Vagrant. If you make certain changes to the VM from VirtualBox, there’s a chance Vagrant could lose the association to the VM.

The “base” boxes are stored in the %userprofile%/.vagrant.d/boxes folder. These will be used over and over for any projects you create that use the same box.

If you destroy all VMs that use a certain box, this does not delete the box itself.

Vagrant creates a shared folder between your project folder and a folder in your VM which is /vagrant by default. Any files in your C:\vm\test folder will show up in the VM and vice-versa. New shares can be setup in your vagrant file. Often boxes are used as development machines, so a common folder to share is your Apache or Nginx www folder.

You can turn the VM off by using vagrant halt, or suspend it with vagrant suspend. Then turn it on again any time with vagrant up. Type vagrant status to see the current state of the VM.

All commands can be found here.

Because anybody can create base boxes, the Vagrant rules state that they should create a user and password vagrant/vagrant. It also states that it does not expect the root user to have any password i.e., it does not use root nor expect a password for it. It would be good practice, if you feel the need, to know what the default users and password are on the box you choose to install.

The rules also state that Vagrant needs password-less sudo on the vagrant user so that it can perform the setup, so you should be aware of this if you are trying to increase security.

Vagrant sets SSH ports to bind to localhost, so it won’t accept connections from the “outside”. This can be changed if you wanted access to your VM from some other host somewhere else. You would need additional setup to do this.

The insecure public/private keys are used by default. These can be replaced using PuTTYGen.

Now that you’ve learned how it works, you’ll want to go further. You can find additional boxes apart from Vagrant Cloud, such as http://www.vagrantbox.es. Using a box from another source is as simple as typing vagrant init box/name url where the ‘box/name’ and ‘URL’ will be provided for you.

George Fekete covered how to create your own base box in a previous article.

You can even use DigitalOcean as a provider and deploy droplets using Vagrant.

Automation tools like PuPHPeT and Protobox help you create the provisioning scripts for deploying more full-featured development VMs.

You may have heard of the popular Vagrant box Laravel Homestead which can be used to deploy a development server for Laravel projects. SitePoint’s Bruno Skvorc has built off of Homestead to create what he calls Homestead Improved with some alternate configuration.

There is a box called VVV which not only creates a development box for WordPress devs, but actually sets it up so you can host multiple WordPress sites on one VM. Homestead does the same thing, so that you aren’t using one whole VM for each project you work on. Aleksander Koko wrote about VVV on SitePoint.

The sky’s the limit, so jump in and look around for cool boxes, provisioning scripts, or create your own!

I hope that helps get you started! Let us know in the comments if you finally took the plunge, and how you found it.