Developer-specific Laravel Homestead Configurations

Since joining Liquid Web, I’ve gotten to revisit Laravel, my favorite application framework for PHP. I’m still doing plenty of WordPress work, of course, but when building web applications — especially those with robust APIs — building atop Laravel makes so much more sense than shoehorning it into a WordPress environment.

In their mission to make application development delightful, Taylor Otwell and the other Laravel developers (including my friend Joe Ferguson) maintain Laravel Homestead, a pre-packaged Vagrant box for Laravel development. While the environment can be installed globally (in the way you might use VVV for WordPress development), Laravel Homestead can also be installed on a per-project basis, ensuring each application has its own, dedicated virtual machine.

Since we may have multiple developers working on any given application, I’m a huge fan of the per-project installation, which simplifies development environment setup to:

I’ve also recently gotten into the habit of adding an alias to my composer.json file:

This lets developers who want to leverage Laravel Homestead to run composer homestead following composer install for an even easier setup process.

What happens when I install Laravel Homestead?

Running composer homestead creates a Homestead.yml in the local directory (don’t worry, it’s already blocked from being committed via the .gitignore file). The Homestead.yml file contains settings local to your Homestead instance, including hostnames, folder mapping, and resources allocated to the virtual machine.

Laravel Homestead’s installation procedure also generates an script that, when present, will execute additional provisioning steps. This is extremely helpful if your application has dependencies that aren’t bundled in the default Homestead image (for example, RabbitMQ).

Customizing Laravel Homestead on a per-developer basis

After using Homestead on a few separate apps, I noticed a pattern — every time I provisioned the box, I’d have to go through the same steps over and over:

  1. Change the default editor from Nano to Vim
  2. Set my name and email address in the local Git configuration
  3. Configure Git to use the “simple” push strategy (so it stops bugging me)

These are settings that not every developer who works on the project will want (especially if their name isn’t “Steve Grunwell”); as a solution, I’ve started using the pattern:

Adding that bit to the end of instructs the setup script to look for the presence of and file (use whatever filename makes the most sense for your team) and, if it exists, execute it. For example, my file looks like this for Liquid Web projects:

Finally, add to your project’s .gitignore file, and your development team is now free to customize a Laravel Homestead box according to their preferences without forcing those decisions on every other developer!

Leave a Reply