Initial Thoughs on Herd Pro

At $WORK, my team has been officially using Homestead since ~2017 as our development environment. This is a VM managed with Vagrant, and that's become a problem when we issue people newer macbooks. So I've been evaluating a new first-ish¹ party solution: Laravel Herd Pro.

Needs

Since this is for a fairly large team, it's really helpful for everything to work consistently. That makes it easier to support: if somebody has a problem, they can write it down, and it's good odds that the next person with that error is having the same problem. Every member of the team learns the common issues and can help new hires.

We're using a mix of Windows 10 & MacOS machines. MacOS is at various versions. I imagine soon it'll be a mix of Win 10 & 11.

There are ~20 Laravel apps being developed. Somebody might need to work on a couple in a day, for bugfixes or updates or whatever. Swapping between apps should be as easy as opening the project in your IDE. This precludes Laravel Sail from consideration, since that needs extra setup for this use-case.

And keep in mind this isn't for personal development, but for a team of people of varying skills, levels, and backgrounds. This includes fresh-out-of-college grads who may have never done any PHP development before. I want it to be easy, repeatable, and consistent. If you drop me in a fresh Minecraft server and tell me to set up a PHP dev environment, I'll punch a few trees and shortly thereafter have some bastardized version of PhpStorm implemented in redstone². But that isn't everybody!

Homestead

Homestead was never a perfect solution, but it was good enough. We had one config file with all our apps, and as we upgraded them or added/removed apps from our list, somebody would update that and it'd fan out to all the other devs easily. Each app was always ready to go with Homestead.

The biggest issue with it is we relied on VirtualBox to run the VM, and that's always been a janky mess. It has long-running issues with node_modules/: if you try to use npm (or similar) inside the VM, it either performs terribly, or you get weird random errors because the shared folder between the host OS & VM doesn't like symlinks or the length of paths or something else.

To get around this, everyone ran node stuff in their host OS. I would prefer the node version live inside the VM, so everyone has a consistent version without having to think about it, and not need two terminals open. But this was a minor problem.

Homestead started falling apart as Apple Silicon rolled out. It took a while for VMs to become available for ARM Macs. When they did, it was OK for a time, but Virtualbox started breaking on M2/M3 chips. There are some beta builds available, but I think Oracle eventually gave up, so those will probably stop working entirely soon.

Homestead, despite being nominally under the "Laravel" umbrella and included in the framework docs, has always been maintained by Joe Ferguson with a smattering of help here-and-there from the community. The reason it took so long to get an ARM VM is Joe didn't have an M1 Mac -- somebody (not Laravel) donated one to facilitate this.

And Homestead isn't under the Laravel umbrella anymore. After PHP 8.3 stabilized, it looks Joe decided to end Laravel Homestead:

I decided to stop working on laravel/homestead because I felt that the community largely ignored the project, and it was a good time to wind down my involvement with the official project. The problem is I still use Homestead nearly every day. It is not always for PHP or web development. It turns out Homestead is a neat little highly customizable and extendible distribution. So, I forked the project and kept it up to date. The primary Homestead users I care about are me, Beth, Becky, and my GitHub sponsors.

It will live on as Svpernova09 Homestead.

But. Homestead's (maybe?) direction change, plus Virtualbox giving up on MacOS, meant it was time for a new solution.

Reviewing Herd

Laravel Herd is similar to Valet, but with management for services & PHP versions built-in. Valet itself relied on Homebrew to install PHP, DBs, Minio, node, etc -- but this is responsible for downloading and installing that stuff itself, on MacOS and Windows. There's no VM or Docker stuff involved.

It's early days -- so far it's just me testing it out -- and it works reasonably well. It is a bit different between MacOS & Windows. I'm not sure if this is going to be a problem or not. But for me, on both platforms, it's working reasonably well for a couple large Laravel applications.

There have been a few problems. Some are slated to be fixed, and others I've opened bugs/discussions on.

TLDs

Firstly: in valet, you can run valet tld devsites.godless-internets.org and all the sites it runs become {foldername}.devsites.godless-internets.org. Valet issues certs using its own self-signed CA so this works nicely. We need it for some legacy SSO tech that relies on a cookie shared across a domain.

In Herd, this doesn't work. It has the herd tld command, but it warns you that this isn't supported. I emailed the support address and their CEO got back to me pretty quickly: there's a PR to fix this, but they're still testing the changes -- particularly around handling changing the TLD after sites have been set up with certificates.

I don't need to change them; I can dictate everyone run that command before it generates certs. So I was able to get this working, although it works wildly differently on Windows & MacOS. For MacOS, it involved updating two config files:

echo "nameserver 127.0.0.1" | sudo tee /etc/resolver/devsites.godless-internets.org

# change .test to .devsites.godless-internets.org in here:
vi ~/Library/Application Support/Herd/config/dnsmasq

On Windows, it involves rewriting the hosts file every time Herd restarts:

# In a Git Bash terminal Run as Administrator
sed -i 's/\.test$/.devsites.godless-internets.org/' /c/Windows/System32/drivers/etc/hosts

Postgres Services

Out of the box, Herd will install PHP & Node versions for you. Herd Pro, the subscription version, will install DBs and other useful services.

The way this works is pretty inconsistent across Windows & MacOS. I started testing on MacOS and I installed the latest postgres it offered me, version 17. I put this in a config file for the project so every developer would get postgres 17 installed when they ran herd init.

Then I started testing it on Windows. The newest postgres offered by this version of Herd is 16. This isn't cataclysmic, but I would expect Herd Pro to offer me the same version of servides regardless of platform -- I now annoyingly had to go tear out my DB on MacOS and set it up again on 16, so developers on Windows would be able to use herd init.

The other big issue is one of our Laravel apps uses the spatie/laravel-db-snapshots package, and Laravel's own built-in dump/restore functionality. Internally, these rely on psql and pg_dump being available in the $PATH. The way Herd manages services, this only half-works on MacOS, and not at all on Windows.

The other use case here is emulating Homestead's databases: section in their YAML config file: list all the DBs you want created, and it'll run CREATE DATABASE for you. I wrote a one-liner to loop a list and echo the appropriate CREATE DATABASE foo to the psql command. This is something I'd love for their config file to support, though.

Herd has its own bin/ directory that it adds to your $PATH. On MacOS, it linked psql from the postgres 17 install to that folder, so I was able to use the command just fine. The pg_dump command is not linked here, but for the one app that's required, it's not a big deal to fix that³.

On Windows, the psql binary is not linked to Herd's bin dir at all. This is fixable, and it's a minor difference, but I was annoyed that stuff like this isn't consistent in a product labelled "pro". Please make my life easy 😭

Other Services

Minio & redis didn't suffer from any problems with different versions available for MacOS vs. Windows.

We run Minio with a proxied HTTPS URL over it, since in some apps, we'll have <img> tags that point to the bucket to get resources⁴. Some browsers will refuse to load <img src="http://localhost:9000/bucket-name/whatever.jpg"> on a site that's served with HTTPS, so that's important.

herd proxy --secure minio http://localhost:9000

This works fine, but it runs into a problem with the webserver's config for uploading large files. There's no setting in Herd to adjust that, so that's a little annoying. I think Valet had the same problem?

Minio does not come with the mc CLI utility, so creating buckets is a pain. I don't believe Minio ships mc with their server package, so I understand how this happened. But if I'm paying extra for an installer, I'd expect it to handle this sort of vendor peculiarity.