6 Reasons to Move to Laravel Homestead
Note: to quickly get up and running with Homestead, see this quick tip. For an explanation on what it is, read below.
Laravel Homestead is, in a nutshell:
an official, pre-packaged Vagrant “box” that provides you a wonderful development environment without requiring you to install PHP, a web server, and any other server software on your local machine.
In other words, it automatically does what we’ve done before manually through Vagrant and PuPHPet in articles like these.
So what makes it different from your run-of-the-mill Vaprobash/Vagrant/PuPHPet setup? Let’s see.
1. It Works
Unlike the other popular solutions out there for simplifying Vagrantfile setups, Homestead seldom fails to boot, and if it does, it’s fixed within minutes. If you’ve dealt with GUI Vagrant solutions, you’ve likely noticed how rare it is to get it all up and running after the very first
vagrant up. It’s always something like an outdated or over-updated Puppet, out of date Ubuntu repos, or some other cryptic error that requires vigorous “foruming” to deconstruct. Homestead simply… works.
Homestead installs on Ubuntu 14.04. with PHP 5.5, so as new as it gets without diving into beta/RC territory, Nginx (because we’ve all given up on Apache by now, right?), MySQL and Postgres so you’re instantly ready for Heroku as well (their default is Heroku Postgres), Node (for all your static resource compilation needs, background tasks, and other less business critical things), Redis, Memcached and Beanstalkd (for all your caching and queueing needs), Laravel Envoy (for all your remote server task needs) and Fabric + Hipchat Extension so you can do application deployment through Hipchat (also known as chatops).
2. It’s Otwell Approved
Homestead being official, as in, made by Taylor Otwell, the father of Laravel, means it’s automatically assumed to hold to certain standards. While the Laravel community isn’t without its drama (who cares what a class is called? If a revolutionary new framework calls a model a potato, a facade, or a rocketship, it’s perfectly fine as long as the potato/facade/rocketship works), it’s the exclusivity of Taylor’s involvement with it that gives it a note of simplicity and quality that’s much needed in today’s PHP world. We’ve seen far too many open source projects ruined by team egos, zealous contributors, or incompetent jacks-of-all-trades and it’s my personal opinion that Taylor’s almost exclusive involvement in Laravel’s betterment is what makes it shine above the rest and truly allows it to compete with Phalcon in quality.
Homestead is his own project, termed the “official local development environment”, and he’ll do everything he can to keep it high quality and make sure it always works. Anything less, and it’s a smudge on his reputation. In PHP these days, there’s no better guarantee of a project’s long term reliability, than it being (mostly) owned by a person who cares that much about quality.
3. It’s Fast to Set Up
Setting Homestead up is a piece of cake. Following the instructions on the documentation page, all you need to do is add the homestead box to your Vagrant (if you don’t have it yet) and clone the repo.
There’s an extra step we’re not used to – setting up SSH. This is simple to do as well, and requires editing your Homestead.yaml file after cloning the repo. Just point the relevant lines to your SSH key(s) and you’re good to go. In my case, I had to change this:
--- ip: "192.168.10.10" memory: 2048 cpus: 1 authorize: /Users/me/.ssh/id_rsa.pub keys: - /Users/me/.ssh/id_rsa folders: - map: /Users/me/Code to: /home/vagrant/Code sites: - map: homestead.app to: /home/vagrant/Code/Laravel/public variables: - key: APP_ENV value: local
--- ip: "192.168.10.10" memory: 2048 cpus: 1 authorize: C:\Users\Bruno\.ssh\id_rsa.pub keys: - C:\Users\Bruno\.ssh\id_rsa folders: - map: D:\VM\vagrant_boxes\homestead\Homestead to: /home/vagrant/Code sites: - map: homestead.app to: /home/vagrant/Code/Laravel/public variables: - key: APP_ENV value: local
After we run
vagrant up, everything should fall into place:
As you can see, my procedure produced some errors, but it still ended up working just fine:
Homestead opens certain important ports by default which make maintaining and managing your database and other installed software on the VM from the host machine a breeze. For example, to connect to the installed MySQL database with MySQL Workbench installed on your host machine (in my case Windows), you just input the required credentials into the connection window:
The default MySQL and Postgres ports simply have a zero appended to them (i.e. 33060 for MySQL instead of 3306) which lets you connect to localhost (127.0.0.1:33060) and grants access to the DB on the VM.
The potential downside to this is the fact that you can’t have multple boxes running at the same time without changing ports due to conflicts. It would be better if the database connections were simply open, and one could connect to the IP of the VM as usual, but that’s easily fixed if need be – just see some of my previous vagrantfiles for what that looks like.
5. Best Practices and Common Ground
Due to Homestead being official, you can rest assured you’ll have a huge community available at all times for any assistance in the matter, should you encounter any problems. You’ll have the same starting point as everyone else using Homestead, and problems will automatically become much easier to diagnose.
6. Easy to add sites
Due to the simplicity of the configuration file one can tweak when fine tuning Homestead, adding new sites (vhosts) is a breeze – you don’t even have to deal with individual vhost configurations in nginx files.
By default, the Homestead.yaml file registers a single vhost called “homestead.app” and that one serves as the default site for the VM’s server configuration. You can access it directly by going to the IP of the VM in your browser, on the regular port 80: http://192.168.10.10. However, you might want to have additional applications or projects running and accessible name-wise through your host machine’s browsers. That’s where the “sites” block comes in. By defining another site like so:
sites: - map: homestead.app to: /home/vagrant/Code/Laravel/public - map: homestead2.app to: /home/vagrant/Code/H2/public
you register a new vhost. Then, if you add that new site’s name to your
hosts file (on any platform) you can access the new site by name through your browser, only you need to do so through port 8000 now: http://homestead2.app:8000.
This procedure allows you to add as many vhosts to your VM as you wish, serving multiple projects from a single box as needed.
Among some of the missing features, I’d name the following:
- Homestead is missing a global composer installation, which means you have to obtain it manually for every project
- The aforementioned ports issue – it would be better if ports were simply open, so one could connect to the IP of the VM, and not the localhost IP via a specific port. This would avoid port conflicts and would let one have multiple Homestead VMs running at the same time
- There is no Laravel. Homestead would do well to include the basic Laravel project by default in the default vhost, so one can start developing instantly without having to create a new one from scratch
- HHVM support would be neat, in the spirit of Vaprobash
Laravel Homestead is among the best and most stable PHP Vagrant environments yet. It’s extremely fast to boot, contains very few dependencies which can break during
up time, and configures a modern, up to date PHP environment for one to immediately start hacking in.
Are you using it? Let us know.