PHP
Article

Re-introducing Vagrant: The Right Way to Start with PHP

By Bruno Skvorc

I often get asked to recommend beginner resources for people new to PHP. And, it’s true, we don’t have many truly newbie friendly ones. I’d like to change that by first talking about the basics of environment configuration. In this post, you’ll learn about the very first thing you should do before starting to work with PHP (or any other language, for that matter).

We’ll be re-introducing Vagrant powered development.

Note that this topic (among other best practices) is covered in much more depth in SitePoint’s Jump Start PHP Environment Book.

Please take the time to read through the entire article – I realize it’s a wall of text, but it’s an important wall of text. By following the advice within, you’ll be doing not only yourself one hell of a favor, but you’ll be benefitting countless other developers in the future as well. The post will be mainly theory, but in the end we’ll link to a quick 5-minute tutorial designed to get you up and running with Vagrant in almost no time. It’s recommended you absorb the theory behind it before you do that, though.

Just in case you’d like to rush ahead and get something tangible up and running before getting into theory, here’s the link to that tutorial.

What?

Let’s start with the obvious question – what is Vagrant? To explain this, we need to explain the following 3 terms first:

  • Virtual Machine
  • VirtualBox
  • Provisioning

Virtual Machine

In definitions as simple as I can conjure them, a Virtual Machine (VM) is an isolated part of your main computer which thinks it’s a computer on its own. For example, if you have a CPU with 4 cores, 12 GB of RAM and 500 GB of hard drive space, you could turn 1 core, 4 GB or RAM and 20GB or hard drive space into a VM. That VM then thinks it’s a computer with that many resources, and is completely unaware of its “parent” system – it thinks it’s a computer in its own right. That allows you to have a “computer within a computer” (yes, even a new “monitor”, which is essentially a window inside a window – see image below):

A Windows VM inside a Mac OS X system
A Windows VM inside a Mac OS X system

This has several advantages:

  • you can mess up anything you want, and nothing breaks on your main machine. Imagine accidentally downloading a virus – on your main machine, that could be catastrophic. Your entire computer would be at risk. But if you downloaded a virus inside a VM, only the VM is at risk because it has no real connection to the parent system it lives off of. Thus, the VM, when infected, can simply be destroyed and re-configured back into existence, clean as a whistle, no consequences.
  • you can test out applications for other operating systems. For example, you have an Apple computer, but you really want that one specific Windows application that Apple doesn’t have. Just power up a Windows VM, and run the application inside it (like in the image above)!
  • you keep your main OS free of junk. By installing stuff onto your virtual machine, you avoid having to install anything on your main machine (the one on which the VM is running), keeping the main OS clean, fast, and as close to its “brand new” state as possible for a long time.

You might wonder – if I dedicate that much of my host computer to the VM (an entire CPU core, 4GB of RAM, etc), won’t that:

  • make my main computer slower?
  • make the VM slow, because that’s kind of a weak machine?

The answer to both is “yes” – but here’s why this isn’t a big deal. You only run the VM when you need it – when you don’t, you “power it down”, which is just like shutting down a physical computer. The resources (your CPU core, etc.) are then instantly freed up. The VM being slow is not a problem because it’s not meant to be a main machine – you have the host for that, your main computer. So the VM is there only for a specific purpose, and for that purpose, those resources are far more than enough. If you really need a VM more powerful than the host OS, then just give the VM more resources – like if you want to play a powerful game on your Windows machine and you’re on a Mac computer with 4 CPU cores, give the VM 3 cores and 70-80% of your RAM – the VM instantly becomes powerful enough to run your game!

But, how do you “make” a virtual machine? This is where software like VirtualBox comes in.

VirtualBox

VirtualBox is a program which lets you quickly and easily create virtual machines. An alternative to VirtualBox is VMware. You can (and should immediately) install VirtualBox here.

VirtualBox logo

VirtualBox provides an easy to use graphical interface for configuring new virtual machines. It’ll let you select the number of CPU cores, disk space, and more. To use it, you need an existing image (an installation CD, for example) of the operating system you want running on the VM you’re building. For example, if you want a Windows VM as in the image above, you’ll need a Windows installation DVD handy. Same for the different flavors of Linux, OS X, and so on.

Provisioning

When a new VM is created, it’s bare-bones. It contains nothing but the installed operating system – no additional applications, no drivers, nothing. You still need to configure it as if it were a brand new computer you just bought. This takes a lot of time, and people came up with different ways around it. One such way is provisioning, or the act of using a pre-written script to install everything for you.

With a provisioning process, you only need to create a new VM and launch the provisioner (a provisioner is a special program that takes special instructions) and everything will be taken care of automatically for you. Some popular provisioners are: Ansible, Chef, Puppet, etc – each has a special syntax in the configuration “recipe” that you need to learn. But have no fear – this, too, can be skipped. Keep reading.

Vagrant

This is where we get to Vagrant. Vagrant is another program that combines the powers of a provisioner and VirtualBox to configure a VM for you.

You can (and should immediately) install Vagrant here.

Vagrant, however, takes a different approach to VMs. Where traditional VMs have a graphical user interface (GUI) with windows, folders and whatnot, thus taking a long time to boot up and become usable once configured, Vagrant-powered VMs don’t. Vagrant strips out the stuff you don’t need because it’s development oriented, meaning it helps with the creation of development friendly VMs.

Vagrant machines will have no graphical elements, no windows, no taskbars, nothing to use a mouse on. They are used exclusively through the terminal (or command line on Windows – but for the sake of simplicity, I’ll refer to it as the terminal from now on). This has several advantages over standard VMs:

  1. Vagrant VMs are brutally fast to boot up. It takes literally seconds to turn on a VM and start developing on it. Look how quickly it happens for me – 25 seconds flat from start to finish:
    Vagrant up
  2. Vagrant VMs are brutally fast to use – with no graphical elements to take up valuable CPU cycles and RAM, the VM is as fast as a regular computer
  3. Vagrant VMs resemble real servers. If you know how to use a Vagrant VM, you’re well on your way to being able to find your way around a real server, too.
  4. Vagrant VMs are very light due to their stripped out nature, so their configuration can typically be much weaker than that of regular, graphics-powered VMs. A single CPU core and 1GB of RAM is more than enough in the vast majority of use cases when developing with PHP. That means you can not only boot up a Vagrant VM on a very weak computer, you can also boot up several and still not have to worry about running out of resources.
  5. Perhaps most importantly, Vagrant VMs are destructible. If something goes wrong on your VM – you install something malicious, you remove something essential by accident, or any other calamity occurs, all you need to do to get back to the original state is run two commands: vagrant destroy which will destroy the VM and everything that was installed on it after the provisioning process (which happens right after booting up), and vagrant up which rebuilds it from scratch and re-runs the provisioning process afterwards, effectively turning back time to before you messed things up.

With Vagrant, you have a highly forgiving environment that can restore everything to its original state in minutes, saving you hours upon hours of debugging and reinstallation procedures.

Why?

So, why do this for PHP development in particular?

  1. The ability to test on several versions of PHP, or PHP with different extensions installed. One VM can be running PHP 5.5, one can be running PHP 5.6, one can be running PHP 7. Test your code on each – no need to reinstall anything. Instantly be sure your code is cross-version compatible.
  2. The ability to test on several servers. Test on Apache in one VM, test on Nginx in another, or on Lighttpd on yet another – same thing as above: make sure your code works on all server configurations.
  3. Benchmark your code’s execution speed on different combinations of servers + PHP versions. Maybe the code will execute twice as fast on Nginx + PHP 7, allowing you to optimize further and alert potential users to possible speed gains.
  4. Share the same environment with other team members, avoiding the “it works on my machine” excuses. All it takes is sharing a single Vagrantfile (which contains all of the necessary configuration) and everyone has the exact same setup as you do.
  5. Get dev/prod parity: configure your Vagrant VM to use the same software (and versions) as your production (live) server. For example, if you have Nginx and PHP 5.6.11 running on the live server, set the Vagrant VM up in the exact same way. That way, you’re 100% certain your code will instantly work when you deploy it to production, meaning no downtime for your visitors!

These are the main but not the only reasons.

But why not XAMPP? XAMPP is a pre-built package of PHP, Apache, MySQL (and Perl, for the three people in the world who need it) that makes a working PHP environment just one click away. Surely this is better than Vagrant, no? I mean, a single click versus learning about terminal, Git cloning, virtual machines, hosts, etc…? Well actually, it’s much worse, for the following reasons:

  1. With XAMPP, you absorb zero server-config know-how, staying 100% clueless about terminal, manual software installations, SSH usage, and everything else you’ll one day desperately need to deploy a real application.
  2. With XAMPP, you’re never on the most recent version of the software. It being a pre-configured stack of software, updating an individual part takes time and effort so it’s usually not done unless a major version change is involved. As such, you’re always operating on something at least a little bit outdated.
  3. XAMPP forces you to use Apache. Not that Nginx is the alpha and omega of server software, but being able to at least test on it would be highly beneficial. With XAMPP and similar packages, you have no option to do this.
  4. XAMPP forces you to use MySQL. Same as above, being able to switch databases at will is a great perk of VM-based development, because it lets you not only learn new technologies, but also use those that fit the use case. For example, you won’t be building a social network with MySQL – you’ll use a graph database – but with packages like XAMPP, you can kiss that option goodbye unless you get into additional shenanigans of installing it on your machine, which brings along a host of new problems.
  5. XAMPP installs on your host OS, meaning it pollutes your main system’s space. Every time your computer boots up, it’ll be a little bit slower because of this because the software will load whether or not you’re planning to do some development that day. With VMs, you only power them on when you need them.
  6. XAMPP is version locked – you can’t switch out a version of PHP for another, or a version of MySQL for another. All you can do is use what you’re given, and while this may be fine for someone who is 100% new to PHP, it’s harmful in the long run because it gives a false sense of safety and certainty.
  7. XAMPP is OS-specific. If you use Windows and install XAMPP, you have to put up with the various problems PHP has on Windows. Code that works on Windows might not work on Linux, and vice versa. Since the vast, vast majority of PHP sites are running on Linux servers, developing on a Linux VM (powered by Vagrant) makes sense.

There are many more reasons not to use XAMPP (and similar packages like MAMP, WAMP, etc), but these are the main ones.

How?

So how does one power up a Vagrant box?

The first way, which involves a bit of experimentation and downloading of copious amounts of data is going to Hashicorp’s Vagrant Box list here, finding one you like, and executing the command you can find in the box’s details. For example, to power up a 64bit Ubuntu 14.04 VM, you run: vagrant init ubuntu/trusty64 in a folder of your choice after you installed Vagrant, as per instructions. This will download the box into your local Vagrant copy, keeping it for future use (you only have to download once) so future VMs based off of this one are set up faster.

Note that the Hashicorp (which, by the way, is the company behind Vagrant) boxes don’t have to be bare-bones VMs. Some come with software pre-installed, making everything that much faster. For example, the laravel/homestead box comes with the newest PHP, MySQL, Nginx, PostgreSQL, etc pre-installed, so you can get to work almost immediately (more on that in the next section).

Another way is grabbing someone’s pre-configured Vagrant box from Github. The boxes from the list in the link above are decent enough but don’t have everything you might want installed or configured. For example, the homestead box does come with PHP and Nginx, but if you boot it up you won’t have a server configured, and you won’t be able to visit your site in a browser. To get this, you need a provisioner, and that’s where Vagrantfiles come into play. When you fetch someone’s Vagrantfile off of Github, you get the configuration, too – everything gets set up for you. That brings us into HI.

Hi!

HI (short for Homestead Improved) is a version of laravel/homestead. We use this box at SitePoint extensively to bootstrap new projects and tutorials quickly, so that all readers have the same development environment to work with. Why a version and not the original homestead you may wonder? Because the original requires you to have PHP installed on your host machine (the one on which you’ll boot up your VM) and I’m a big supporter of cross-platform development in that you don’t need to change anything on your host OS when switching machines. By using Homestead Improved, you get an environment ready for absolutely any operating system with almost zero effort.

The gif above where I boot up a VM in 25 seconds – that’s a HI VM, one I use for a specific project.

I recommend you go through this quick tip to get it up and running quickly. The first run might take a little longer, due to the box having to download, but subsequent runs should be as fast as the one in my gif above.

Please do this now – if at any point you get stuck, please let me know and I’ll come running to help you out; I really want everyone to transition to Vagrant-driven-development as soon as possible.

Conclusion

By using HI (and Vagrant in general), you’re paving the way for your own cross-platform development experience and keeping your host OS clean and isolated from all your development efforts.

Below you’ll find a list of other useful resources to supercharge your new Vagrant powers:

  • SitePoint Vagrant posts – many tutorials on lots of different aspects of developing with Vagrant, some explaining the links below, some going beyond that and diving into manually provisioning a box or even creating your own, and so on.
  • StackOverflow Vagrant Tag for questions and answers about Vagrant, if you run into problems setting it up
  • PuPHPet – a way to graphically configure the provisioning of a new Vagrant box to your needs – select a server, a version of PHP, a database, and much more. Uses the Puppet provisioner. Knowledge of Puppet not required.
  • Phansible – same as PuPHPet but uses the Ansible provisioner. Knowledge of Ansible not required.
  • Vaprobash a set of Bash scripts you can download (no provisioner – raw terminal commands in various files that just get executed) as an alternative to the above two. Requires a bit more manual work, but usually results in less bloated VMs due to finetuneability.
  • 5 ways to get started with Vagrant – lists the above resources, plus some others.

Do you have any questions? Is anything unclear? Would you like me to go into more depth with any of the topics mentioned above? Please let me know in the comments below, and I’ll do my best to clear things up.

Meet the author
Bruno is a coder from Croatia with Master’s Degrees in Computer Science and English Language and Literature. He’s the editor of SitePoint’s PHP channel and a developer evangelist for Diffbot.com. He avoids legacy code like the plague and when picking projects makes sure they’re as cutting edge as possible. He’s a treadmill desk enthusiast and active (board)gamer who sometimes blogs.
  • Aleksander Koko

    Really good article @swader. I am using Vagrant (+ Homestead) for more than a year but still enjoyed this article.

    • http://www.bitfalls.com/ Bruno Skvorc

      Thanks :)

  • http://auct.eu/ Dima Taras

    edit:founded
    thx for article. I really need to start using virtual machine. Hate that I have 0 knowledge in command line for unix

  • Todd Zmijewski

    Good article. I now have something to direct people to when asked about using *AMPP instead of VMs.

  • Mat Gargano

    Isn’t the company behind Vagrant, Hashicorp? (not Atlascorp?)

    • http://www.bitfalls.com/ Bruno Skvorc

      Doh! Thanks, fixed. That’s a mistake I often make because Atlascorp just sounds so much cooler :)

    • http://www.skooppa.com s.molinari

      I’d say it is. https://www.hashicorp.com/

      Scott

  • http://www.skooppa.com s.molinari

    Great article and reasoning for using a VM. I had used a Windows configuration for some time until a wiser developer than I told me about using Virtualbox around 2 years ago. I’ve never looked back since.

    I’d like to throw in another reason to use a VM for development. It is sort of mentioned with “Since the vast, vast majority of PHP sites are running on Linux servers, developing on a Linux VM (powered by Vagrant) makes sense.”

    My added reason is, when you get into a bind and try to find a solution, 99.9% of the solutions you will find on the Internet (and on Sitepoint too!) will also be based on some Linux derivative.

    In general, using a VM simply makes you wiser about the right things faster.

    One of the nice side effects I have with my Virtualbox VMs is my dev boxes are all accessible through the URL “awesome.dev”. LOL! Nothing like a bit of positive reinforcement, when wor……um…..no…when having fun! ;-)

    Scott

  • RobM

    Just a correction … You don’t need PHP installed to use Homestead, only Git.

    • http://www.bitfalls.com/ Bruno Skvorc

      Missed that update – that’s rather recent. Will look into it, thanks!

  • Taylor Ren

    Using Vagrant all the time. Whenever there is a need to test something new (and possibly risky), I will create a new Vagrant VM. It cost nothing… LOL

  • Kevin Vandenborne

    We’ve recently switched from vagrant to docker, it’s much faster in general – I wouldn’t want to return to vagrant.

    • http://www.bitfalls.com/ Bruno Skvorc

      Do you have any disparity regarding development platform operating systems in your team? I’m having a hard time believing your people have a smooth Docker workflow on Windows, OS X and Linux – which is something a Vagrant setup will handle flawlessly.

      • Kevin Vandenborne

        We all have company Macbook Pro’s setup via ansible, all the requirement are added to the playbooks – no one has to figure out how to set up their machine or manually install certain things. I use Windows at home but I’ve not yet tested docker on it. We’re using boot2docker, which is also available for windows, so I’m not expecting to run into much problems.

        • http://www.bitfalls.com/ Bruno Skvorc

          Is boot2docker treating you well in regards to shared folders? I hear there are many problems with that.

          • Kevin Vandenborne

            So far so good, I’ve not heard any complaints from colleagues and I’ve not encountered any issues myself either. I had more issues with shared folders on vagrant, specially with large applications.

            We’re using a docker compose file (https://gist.github.com/veloxy/17d91421813856d4cd79) and some basic images (https://github.com/yappabe). The learning curve is a bit higher i think, but it’s worth it to me. I’m not yet convinced to use it in production, haven’t found a proper zero downtime deploy method yet.

            It also boots up a bunch faster than a vagrant, at least our own vagrant box which had contained a bunch of dev tools, provisioning took a very long time.

      • http://glend.me Glend Gjermeni

        Vagrant in Fedora is a nightmare. They use libvirt which is cool, but PuPHPet is not going to support it and most helper tools are not designed for libvirt at all. I tried using VirtualBox as a provider and it simply doesn’t work whereas in Ubuntu the same config works fine.

    • http://glend.me Glend Gjermeni

      You can use Vagrant with Docker as a provider to get the best of both worlds http://docs.vagrantup.com/v2/docker/

  • Wirlez

    Great article! Though the “Hi” project tutorial could have been a little more user friendly. I didn’t quite understand the “map” and “site” part. The “Hi” tutorial also mention that you should edit the hosts file on your “host machine”, which made me confused since I just used a “virtual machine” to “host” my website.
    Say bye bye XAMPP and hello to Vagrant.

    • http://www.bitfalls.com/ Bruno Skvorc

      Thanks for the feedback, that’s very good to know – I’ll work on making it more approachable.

  • http://anorgan.com/ Marin Crnković

    Just to spice things up, for provisioning I use SaltStack. It is easy as Ansible, but you don’t have to have Ansible installed on host machine. Here is my somewhat lengthy intro to SaltStack: http://blog.anorgan.com/2015/03/27/saltstack-installing-setting-up-and-provisioning/

  • http://www.crazyws.fr CrazyMax

    Neard (https://sourceforge.net/projects/neard/) is also a nice alternative to XAMPP ;)

  • http://www.bitfalls.com/ Bruno Skvorc

    Thanks :)

  • http://www.bitfalls.com/ Bruno Skvorc

    You really shouldn’t be using that. It’s much worse than XAMPP

  • http://www.bitfalls.com/ Bruno Skvorc

    I’ll give those a go, thanks

  • Mark Richards

    I agree with the use of Vm’s but take a slightly different approach. My Vms are on my Test Server so that I can develop against the final environment.

  • http://www.danieldogeanu.com/ Daniel Dogeanu

    Too bad that you have to use VirtualBox as provider. You can use VMware, which is a more stable and more powerful choice, but you have to pay license for the Vagrant VMware plugin, as well for VMware, separately. This was the reason I avoided to use Vagrant until now.

    • http://www.bitfalls.com/ Bruno Skvorc

      If you avoided it, how do you know which is more stable/powerful?

      • http://www.danieldogeanu.com/ Daniel Dogeanu

        It’s very simple, VMware doesn’t crash randomly. VirtualBox crashes all the time. You can try installing a normal OS in it and after that keep it running to see how long it last without crashing. For me it’s a very frustrating thing, so I avoid it as much as possible.

        • http://www.bitfalls.com/ Bruno Skvorc

          My currently booted VM has been running for 8 days now, for an ongoing project. Zero crashing. Same with other projects when I leave them on for a while.

          • http://www.danieldogeanu.com/ Daniel Dogeanu

            What OS do you have? I run it on Windows 8.1 and it still crashes. I had it on XP, 7 and 8 too, and it was way worse. However I see that it doesn’t crashes with Vagrant. Maybe Vagrant doesn’t use some of its buggy features. Or maybe I haven’t used it for long enough.

          • http://www.bitfalls.com/ Bruno Skvorc

            Windows 8.1 and OS X, works flawlessly. Virtualbox != Vagrant, so don’t judge one based on the other. Give it a go.

          • http://www.danieldogeanu.com/ Daniel Dogeanu

            I know VirtualBox != Vagrant. I’m already giving it a go ever since I left the first comment. Still, VirtualBox on it’s own crashes a lot. It’s really annoying. As I said, when I’m launching Vagrant, it seems to work fine. I’m gonna have to see how Vagrant really uses VirtualBox.

  • http://quran.2index.net/ Said Bakr

    Do you know AMPPS? http://www.ampps.com/

  • http://www.benbachrach.com/ BenBachrach

    If you create a page such as myapp.php, following the procedure you detail, what URL do you enter in your local browser to view myapp.php?

  • http://www.jgbnd.com/ Jean Gérard Bousiquot

    Thanks a lot! I’ve been hearing about Vagrant for some time now, and never understood what it was. But your writings helped me get some grasps on the subject. I’m going to try it out. Seems cool. Thanks again!

    • http://www.bitfalls.com/ Bruno Skvorc

      You’re welcome!

  • Mister Krinkle

    Just wondering, how using Vagrant is better than creating a regular VirtualBox VM, installing your OS plus software stack the normal (long) way and then simply cloning that VM each time you need a new environment? So, the first VM becomes your clean, pre-built “template” environment with PHP, MySQL and whatever else already installed and you just drop in your application/destructive experiment/whatever and away you go. Just need to change a few little things like the machine’s hostname and MAC address(es) each time you clone. Been doing this for a while and it seems to work well.

    • http://www.bitfalls.com/ Bruno Skvorc

      Vagrant way is much faster, much lighter on resources, far more automatable and much easier to manage in regards to port forwarding, key configuration and, last but not least, sharing with other people. Sharing a VM your way would require uploading a XXX MB file. Sharing one with Vagrant means uploading a 1kb editable text file.

  • Randy_A

    Sorry for the noob question, but I noticed that with Virtual Box you need to have an install cd for the operating system you want to work from. Is this also true if you choose using Vagrant instead?

    I’m a good ways off from being able to use any of this because I still have a rather lengthy and in depth command line tutorial to work my way through, and very little experience with using it as of now. Once done though, I would like to give Vagrant a go.

    Please advise.

    • keithpickett

      Nope. No startup CD needed. Start here. Install both Vagrant and Virtualbox and follow the instructions.

      • Randy_A

        Thanks @keithpickett:disqus

  • anonymous

    $ vagrant up

    ==> default: Successfully added box ‘laravel/homestead’ (v0.2.7) for ‘virtualbox’!
    There are errors in the configuration of this machine. Please fix
    the following errors and try again:

    vm:
    * The host path of the shared folder is missing: /var/www/myapp
    * The host path of the shared folder is missing: /var/www/myapp2

    how to fix the above?

  • Ronald Hristov

    “Vagrant VMs are brutally fast to use – with no graphical elements to
    take up valuable CPU cycles and RAM, the VM is as fast as a regular
    computer.”

    I would argue on this one. It’s terribly SLOW thanks to shared folders (and you need them).
    And yeah it’s not vagrant’s fault it’s Virtual Box’s.
    It’s actually mine for using vagrant.
    Either way I’m using a scripting language with compiling times.
    12 seconds for opening a single page from a zf2 project.
    So you try rsync and NFS which have their own drawbacks.

    Brutally fast to use is lxc.
    Booting in lxc takes max 5 seconds and there is no dedicated memory for the container (It takes what it needs).

    • http://www.bitfalls.com/ Bruno Skvorc

      That won’t work as smoothly on all host platforms, and the aim of this guide is to have a *truly* multi-platform development environment.
      The folder sharing issues are very easily solved, even with behemoth frameworks like ZF2 or Symfony2:

      1. Moving cache and log folders outside of shared space
      2. Moving vendor folder outside of shared space (that’s one config variable in composer.json)
      3. Upgrading realpath cache in php.ini for bigger size and TTL
      4. Enabling APC cache for the autoloader.
      5. Disabling XDebug

      By applying these, my recent Symfony app test went from 25 seconds per page load, to 400ms – and that’s in dev mode, which is considerably slower than prod mode.

      • Simone Pescina

        what????!!! let me try instantly all of this. A big question mark. How? Can you elaborate a little more?

        • M S i N Lund

          Simple!
          Just open up a window and type “gooobeldygook”.

          Whaaat, It didn’t work?
          Well, then just follow this simple 1000-step description!

    • http://www.bitfalls.com/ Bruno Skvorc

      That won’t work as smoothly on all host platforms, and the aim of this guide is to have a *truly* multi-platform development environment.
      The folder sharing issues are very easily solved, even with behemoth frameworks like ZF2 or Symfony2:

      1. Moving cache and log folders outside of shared space
      2. Moving vendor folder outside of shared space (that’s one config variable in composer.json)
      3. Upgrading realpath cache in php.ini for bigger size and TTL
      4. Enabling APC cache for the autoloader.
      5. Disabling XDebug

      By applying these, my recent Symfony app test went from 25 seconds per page load, to 400ms – and that’s in dev mode, which is considerably slower than prod mode.

  • http://www.dmcworks.com/ Devin Columbus

    How do I execute the `php` command in Terminal that comes with the Vagrant Box that I’ve installed, as opposed to the system `php` alias?

    • http://www.bitfalls.com/ Bruno Skvorc

      You must enter the VM with Vagrant SSH. From the moment you’re in, everything you execute is executed in the context of the VM, and the system stuff is left alone.

      • http://www.nikush.uk/ Nikush Patel

        You can also send commands into the VM without having to drop yourself completely into it: `vagrant ssh -e ‘php –version’` will execute the provided statement from inside the VM and print it’s output.

  • Kenneth John Falbous

    I have xampp installed on my PC can I have vagrant set up along with it or do I need to uninstall xampp first.

    • http://www.skooppa.com s.molinari

      You can run both together. However, it makes little sense.

      Scott

  • M S i N Lund

    I have a question about the list of vagrant-boxes
    that all tutorials like this tells you to go to and download from.

    How exactly do i find what i need there?
    All I see is a endless collection of boxes, like this:

    * Supertrustworty (There isn’t a description.)
    * greatestboxintehworld (There isn’t a description.)
    * superduperbox (There isn’t a description.)
    * containsnomalware (There isn’t a description.)
    * yippeee!!box (There isn’t a description.)
    * blahblahbox (There isn’t a description.)
    * etc etc etc (There isn’t a description.) (There isn’t a description.) (There isn’t a description.)

    How do i choose?
    They all seems so great, and so trustworthy.
    (Especially the ones with the word “trust” right there in the name)

    And I especially like how there is no info about where they came from, or who made them.

    • http://www.bitfalls.com/ Bruno Skvorc

      If you’d given it a proper read, you’d see that I’m linking to Homestead Improved at http://www.sitepoint.com/quick-tip-get-homestead-vagrant-vm-running/, an extended version of Laravel Homestead. It’s quite obvious (it says so in the post) that it was created by Taylor Otwell, improved by me, and is maintained in that form by SitePoint and its authors and editors. That’s pretty much the only box we’ll regularly recommend here, but when in doubt, feel free to build your own using PuPHPet or something, or just start from a blank Ubuntu box if you really don’t “trust” anyone and install the software you need manually. All these approaches are fine – ours (like many boxes) is just a shortcut.

  • Artemis

    I’m new to this and I’ve hit a wall just in start up (I’m on Windows 10). I installed Vagrant and VirtualBox (will install Git later). I keep getting “LogLevel Fatal” when entering the vagrant ssh-config command. Among a few attempts at trying to fix the issue, I’ve reinstalled both a few times and have deleted the privatekey as someone on another site said it fixed their problem, but still no luck for me. I’m anxious to get started and get learning, I’d appreciate any help!

    • Bruno Škvorc

      Why are you entering the ssh-config command? What specifically are you trying to accomplish?

  • Nguai al

    Your explanation is clear as a whistle. I want Vagrant NOW!!! What a revelation and revolution. Why I didn’t know about this sooner?

  • Bruno Škvorc

    There is absolutely no need to use that, just follow the quick tip and it’ll work out of the box: http://www.sitepoint.com/quick-tip-get-homestead-vagrant-vm-running/

    • Artemis

      Ooh k. Thanks! :) I’ll give it a shot.

Recommended

Learn Coding Online
Learn Web Development

Start learning web development and design for free with SitePoint Premium!

Get the latest in PHP, once a week, for free.