Developing with Vagrant and Git on a Windows box

We as developers at Enrise are pretty much free to decide what tools we want to use for developing our products with. Be it Zend Studio or Vim, MacOSX or Linux, graphical tools or their command line counterparts, it’s all up to the personal preferences of the developer.

I will try to explain how my choice for Microsoft Windows as OS on my machine collided somewhat with the decision we made at Enrise to start using Vagrant for our virtual devboxes, and how I set up my pc to overcome these collisions and be able to work to my satisfaction.

Vagrant on Windows

Out with the old, in with the new!

Enrise’s strength is in developing complex Web and API projects, with not only a web and database server to support projects, but various caching mechanisms, other storage backends, and queue handlers as well.

Until recently we used to develop on a standardized Virtualbox environment which could support multiple projects side to side, but as more and more of the above mentioned tools come into play, sometimes this would mean e.g. having to switch the Varnish or Memcached configuration for different projects we would work on.
Besides that, whenever a new developer joined a devteam, he or she had to setup their own Virtualbox environment which could easily cost a day’s labour labor. (Exporting / importing Virtualboxes proved to be as time consuming as setting up the project again, because of personal changes done to or personal data on the Vboxes.)

Because of above reasons, we decided to start using Vagrant, which is basically automated setup of Virtualbox machines combined with a automated configuration / installation process within that vbox to tailor it to the needs of a specific project. This means that once configured properly, every project has its own environment that’s up and running in minutes, so no more fiddling around with switching settings between projects, and no more wasted days setting up development environments.

Vagrant on Windows

While Vagrant works really great in POSIX compliant OSes like Linux or MacOS due to their mature terminals and command line tools, on the OS from Redmond things were not so great.

What I wanted to achieve was to work just like I would have been able to if I was running Linux on my machine, so my requirements were:

  • A proper terminal (Bash) environment, with a git PS1 helper, support for colours, etc.
  • The ability to run the funtoo keychain project as a background process which enables me to push and pull code to and from github without having to supply a password every time I do so.
  • Fast git status and git diff command execution
  • Resizing the terminal window just the way Putty works

Because we decided at Enrise to include the Vagrant config within our project source, this means working with Vagrant cause the source code of projects to be on the host OS, in my case Windows 7 Professional x64, and it seemed these were options to pick from:

  • Installing GitBash which provides the Git commandline tools on Windows from within a Bash environment
  • Mounting the same Windows directory to both the Vagrant Vbox and a separate virtual Linux box on which I have a proper tool setup
  • Migrate to Linux or get a Mac
  • Setup a Cygwin environment with the tools I want

Exploring my options


This option turned out to be a pain, because GitBash runs in a small Windows CMD window which is unable to resize beyond a rather small width, and has no proper copy/paste support. Using Windows PowerShell instead somewhat solved the resizing issues (the terminal itself still isn’t resized, only the window it’s in) although I seriously doubt I would have been able to fix other nuisances things like a keychain (actually, there is an option called plink which integrates with Putty / Pageant but this turned out to be pretty slow)

Mounting twice

Making the source directory (which is located in Windows) available to both the Vagrant box and a separate Linux box via mounts seemed to work just fine, as this provided me with proper tools and a proper terminal, but once I started running the commands git status or git diff it turned out this setup was way too slow for everyday use. I like coffee and all (every developer does, right?), but getting a fresh cup every 15 minutes just because I had to wait to see my changes is a bit too much even by my standards. A colleague warned me about this twice, but then again I believe Christopher Columbus was warned (and more than twice) that he would fall off the end of the earth before he left on his great journey to find India, and instead found America, so I had to try it anyway. I also tried running a NFS server on my Windows machine and mounting that from within the Linux box my tools were on, and although it was much faster than vboxfs, it still was too slow for me to work comfortably.

Switching to Linux or getting a Mac

Switching to a different OS the minute one encounters obstacles probably means I would be switching every week. No OS is perfect and although I can live most of the OSes out there, Windows has never let me down and enables me to use nice software like Adobe Photoshop or Foobar2000 audio player out of the box. So, this idea was quickly discarded.


Even though Cygwin isn’t officially supported as far as I know, I decided to give this a try, as it might meet the requirements I stated above. After some fiddling, it turned out to be best solution I have seen so far, and actually works to my full satisfaction! In the section below I will go into detail on how I set up the various tools involved.

The setup


First of all, I needed Cygwin on my Windows box, so i grabbed it from the official site.
After installation I quickly found out that a few things were not to my liking:

  • I missed my beloved Gentoo style bash config
  • A proper package manager was missing, too
  • ‘vagrant up’ and ‘vagrant ssh’ would not work on Windows

Gentoo style bash config

This was quickly fixed by copying over the bashrc and .bashrc from a Gentoo box I was running.
The home dir of your user resides in C:\cygwin\home, it’s easy to access the Cygwin filesystem from Windows.

A proper package manager

Cygwin does not have an internal package manager, therefore packages you would like to install require starting up setup.exe again, selecting the required package, and installing it by finishing the Cygwin installation process. A nice little project exists however, that decides it wants to do things differently. It is called apt-cyg, can be found at and gives us the power of maintaining packages in our Cygwin environment via a command line package manager similar to apt-get.
The procedure to install apt-cyg is described on site as installing Subversion, then exporting the source code into a directory.
I feel however that you should decide whether you would like to have Subversion as a package on your Cygwin installation because you use it, or have since moved on from this great software that served us well for many years but I feel is now deprecated to its successor git/
There is a simple way of circumventing the installation of Subversion, which is running the following commands from your Cygwin terminal:

$ cd /usr/local/bin/
$ wget
$ chmod + x apt-cyg

Pat yourself on the back, for you now have installed a working cygwin installation and a proper package manager to maintain it. Just type apt-cyg to try it out!

Fixing vagrant up and vagrant ssh

Vagrant refused to run, instead it showed following error message:
/cygdrive/c/Program Files (x86)/Vagrant/vagrant/bin/vagrant: line 42: /cygdrive/c/Program: No such file or directory
This to me looked that a script was being run with some variables, one of which is the (unescaped!) path to vagrant, which results in ‘/cygdrive/c/Program’ instead of ‘/cygdrive/c/Program Files (x86)/vagrant’.
The fix turned out to be easy. In the file noted in the error message was this line:
Encapsulating the variables with double quotes solved the problem, as ruby now interpreted the complete path a single argument:

After this, I could successfully run the command ‘vagrant up’ and my Vagrant box appeared \o/

Next up: vagrant ssh. Vagrant detected I was running Windows, which, at least to Vagrant, can’t possibly have a commandline ssh client, thus Vagrant showed the message I should use Putty to connect.

I found this patch on Github which solves the issue by doing a proper SSH check, but at the time of writing the stable release version of Vagrant is 1.0.5, which does not have this fix yet.

Luckily it is possible to just grab the fix from the Pull Request and apply it to the installed version of Vagrant, after which I was able to not only do ‘vagrant up’, but ‘vagrant ssh’ as well.

Other tools and configuration

Because the way we setup Vagrant within projects, the code needs to be on the host OS.
Therefore, I decided the project sources would be stored in the My Documents folder, in a directory named Projecten (Dutch for Projects).

From the Cygwin terminal, this is accessible via /cygdrive/c/Users/svessen/Documents/Projecten/. Since I don’t like to type long paths over and over again, I created a symlink to my home dir called projects, so I can just ‘cd projects’ and be in the projects folder within My Documents.

All I then really needed was some software like funtoo keychain, git and vim, luckily this was super easy thanks to apt-cyg!


After setting the default Cygwin window size and transparency (which is pretty nice) I found a system that met my requirements in every way:

  • A proper terminal (Bash) environment, with a git PS1 helper, support for colours, etc.
  • The ability to run the funtoo keychain project as a background process which enables me to push and pull code to and from github without having to supply a password every time I do so.
  • Fast git status and git diff command execution
  • Resizing the terminal window just the way Putty works

Running Vagrant in Cygwin

So if you are running Windows as host OS and want to be able to develop with virtualboxes using Vagrant, I can really suggest running the above mentioned setup.

If you have found a better / different way of working with Vagrant on Windows, let me know in the comment box below!


Web developer, tweaker, sport car enthusiast, geek

Showing 22 comments
  • Onno Schmidt

    Nice read, I am in the same situation and experience slow performance with windows hosts. I was thinking about sharing the folder in windows and mount it in the Linux guest with smb_mount. Did you try this setup yet?

    • Stefan van Essen

      Hi Onno,

      I didn’t try sharing the Windows directory via Windows Networking, and mounting it within the Linux VirtualBox.

      I did however share the virtualbox directory via Samba and used that in Windows via the UNC path, this should give the same speed results (pretty slow).

      I also tested sharing a Windows directory via NFS and mounting that in Linux, this turned out to be too slow to use, too.

      In the end, I did not find a workable (fast enough) solution when not having the code, the editor, and the commandline tools all in one place.

      • Chris Geisel

        Did you use the git installed via cygwin or a different binary?

        Also, have you had any issues with symlinks in your repo? That seems to be a sticking point for some Windows hosts.

      • Chris Geisel

        On second read, you didn’t go into detail about how you’re sharing your code between the Windows host and *nix guest. Are you using the built-in Vagrant/VB shared folder? If so, did you run into any performance issues?

        • Stefan van Essen

          Hi Chris,

          If I recall correctly I installed git via apt-cyg, like I did with most software in my cygwin environment.

          Symlinks do cause problems, so a collegue of mine developed a little tool that grabs all symlinks from git (looks for files of type 120000) and creates them with the Windows mklink.exe command.

          As for the performance problems: the trick is having the files on your disk in Windows which gives direct access from the IDE and Git to them. It seems that the Vbox (at least with our projects) is much less demanding in terms of speed than the IDE or Git, so I do not have any performance issues whatsoever between Vbox <> code.

      • Leo Shaw

        Great article, I have the same problem with the performance of the shared drive. Running tests takes roughly double the time (five minutes -> ten minutes) and the performance of my (web) app is painfully slow. TortoiseSVN is also unusable (yes still using Subversion!) and searching within my text editor is horrible.

        My current workaround is to copy the project files onto the VM’s file system for working, then when all of tests pass copy back to /vagrant. It sounds dire but only takes about 10s for the copy.

        A solution that used to work nicely with VMWare was to run Samba on the guest and mount the shared drive under Windows – I haven’t tried this with VirtualBox yet so it may be that the speed difference was down to VMWare rather than the sharing mechanism.

  • Jürg

    Very nice article! This realy realy helped me!
    So here just two things I want to mention as I had some problems during the setup:

    1. If Vagrant doesn’t start up with some kind of error that a gem is not found (Something with “Could not find vagrant (>= 0) amongst []” in it), follow these instructions:!topic/vagrant-up/UEixJVaHYMw.

    2. If you have any other VM’s which are not managed with vagrant and the cygwin home directory is not the same as the windows home directory, you should create links to your .VirtualBox and “VirtualBox VMs” directory. How to achiev this is explained over there: (Section Now: Vagrant!)

    • Stefan van Essen

      Hi Jürg,

      thanks for the information, this might come in handy for people who have problems setting things up!

  • Steve Romanow

    Another possibility may be to use Console2 with gitbash.

    • Stefan van Essen

      Hmm, I should try that. Thanks!

    • Tamlyn

      +1 for Console2. Recently discovered it and it makes all the difference. There’s also MinTTY but I had compatibility issues with that.

  • Clint

    I liked your cygwin color setup. Can you post your configuration or email it to me? Are you using MinTTY for transparency?

  • yantaq

    this is very helpful Thanks.
    BTW, Instead of Windows CMD, try using “Far Manager”. it integrates well with windows CMD. you can resize, change colors. “Far Manager” also features extra stuff that makes file browsing much easier.

  • tunesmith

    FYI, it looks as if that pull request (to enable vagrant ssh from windows) has been approved and pulled into Vagrant 1.1 .

  • bullfish

    Thanks for the great article, Stefan!

    Just in case somebody is experiencing problems with the old apt-cyg: You find the updated file on github, the URL is:

    Also you need to update the mirror, because the old one is not working anymore (you will get setup.ini not found errors):
    apt-cyg –mirror

  • James Hilliard

    I know how you can get around the windows performance issues, although some of the ruby syntax for getting parts of the configuration set up is causing me trouble. Pretty sure this requires professional/ultimate for windows 7 with native NFS. The general method is to simply keep all files off of the windows file system and use windows native NFS client to access files stored on a guest drive. The easiest way to do this while still allowing generic base images is to simply add a data drive image, this also allows you to keep the small OS image on a SSD with the data image on a larger slower drive. In virtualbox that can be created and added with the following under the provider configuration.:
    disk2_path = Dir.pwd() + “/” + “Crossdev-Data” + “.vmdk”
    vb.customize [“createhd”, “–filename”, disk2_path, “–size”, 300*1024, “–format”, “vmdk”, “–variant”, “Standard”]
    vb.customize [“storageattach”, :id, “–storagectl”, “SATAController”, “–port”, “1”, “–device”, “0”, “–type”, “hdd”, “–medium”, disk2_path]
    After this the guest will be able to see the drive but will still need to format and mount it. This is ideal for working with certain source trees especially ones that need case sensitivity as the code simply can’t be allowed to touch the windows filesystem without getting severely broken. At least thats my take on the windows cross platform development problem. What I have so far is here although theres still a lot I need to get scripted . Feel free to get in touch with me on git hub or send a pull request. I commented out most of the performance enhancements that may not have universal compatibility so you should look at if your system can handle those.

  • Zachery Newmark

    You actually make it sewem so easy with your presentation but
    I find this topoic to be really something thawt I think I would never understand.
    It seems too complicated and very broad for me. I’m looking forward for your next post, I’ll try
    to get the hang of it!

  • Hai Gronowski

    Thanks for finally talking about >Developing with Vagrant and Git on a Windows box <Liked it!

  • Plan

    May I just say what a relief to discover somebody that genuinely understands what they are discussing on the web.

    You definitely realize how to bring an issue to light and
    make it important. More people really need to look at this and understand this
    side of the story. I can’t believe you aren’t more popular since you surely possess the gift.

  • Yusuf Fidan

    Hi Stefan,

    in our company we’re using Vagrant and git on MacOS. I’m supported my Windows colleagues to the change to Vagrant with an OpenSuse Mashine, and GIT-Bash. Most of the time it work’s fine…but:
    if my colleague clones a repository, while Vagrant is running, the repos is not readable. The file-permissions are broken. If he trys the same after he did stop the Vagrant Maschine, the file permissions are okay. Do you have any similar Problems actual or in the past?

pingbacks / trackbacks

Leave a Comment

Start typing to search