Yerd - The open-source Herd alternative for macOS & Linux
by•
Yerd is a rootless, open-source local PHP dev environment for macOS & Linux - a Laravel Herd alternative with no Docker, no sudo, no subscription. Drop a folder in and it's live at a .test domain with automatic HTTPS. Per-site PHP versions, managed Composer/Node/Bun, databases, a mail catcher, and live Laravel telemetry - all from one tiny ~8MB Rust daemon. MIT-licensed and built in the open.
Replies
Hey Product Hunt 👋
I'm Richard, a co-founder of FORJED, and the main developer behind Yerd.
Yerd came out of a simple frustration: getting a PHP project running locally still means picking your poison. Docker eats RAM and battery and turns a fast request into a slow one. The convenient native option is closed-source, macOS-only, and paywalls the good parts behind a subscription. And the DIY route - Homebrew PHP, nginx configs, mkcert, dnsmasq - works right up until it silently doesn't.
I wanted something that just gets out of the way: drop a folder in, get a .test site with real HTTPS, switch PHP versions per project, and never think about it again. So I built it. Yerd started off as a CLI using Go, but has been rebuilt from the ground up using Rust, with a GUI first approach (although the CLI still exists!)
A few things I'm proud of:
- It's a single ~8 MB Rust daemon. No containers, no VM, no Electron.
- It's rootless - setup asks for elevation exactly once, and nothing runs as root afterwards.
- HTTPS is automatic via a local CA. No mkcert, no browser warnings.
- Databases, a mail catcher, managed Composer/Node/Bun, and live Laravel telemetry are all built in.
- It's MIT-licensed and open source. No subscription, ever.
It runs on macOS and Linux today, and Windows is on the roadmap.
I'd genuinely love your feedback - what your current local setup looks like, what's missing, and what would make you switch. I'll be here all day answering everything.
Thanks for taking a look
How does the automatic HTTPS work without sudo or touching system trust stores, and does that ever conflict with existing certs from something like Laravel Herd or Valet already installed?
@necdetc2xx
Good question - and worth clearing up one thing in the premise first, because I'd rather be straight about it: Yerd does add its CA to your system trust store, and that step does need sudo. What it doesn't need is sudo for everyday work. The trust happens once, as part of the single sudo yerd elevate at setup - the same one-time step that routes *.test and lets the proxy bind ports 80/443. After that, the daemon, CLI and GUI all run as your own user and never touch root again.
The actual flow: on that first elevate, Yerd generates a local certificate authority on your machine and adds its root to the system trust store. From then on, whenever you secure a site it mints a per-site leaf certificate signed by that CA, on demand, and the rustls-based reverse proxy terminates TLS with it. The CA's private key is generated locally and never leaves your machine - nothing phones home. Issuing and serving certs is all unprivileged, so yerd secure my-app day to day needs no sudo; only that initial "trust this CA" did.
On Herd/Valet: the certificates themselves won't clash. A trust store happily holds many root CAs, and each site's cert is validated against whichever CA signed it, so Yerd's CA sitting alongside Herd's is fine. The real overlap is elsewhere - Herd, Valet and Yerd all want to own .test resolution and bind 80/443, and only one tool can hold those at a time. So the practical advice is to run one at a time: stop Herd/Valet before starting Yerd (or vice versa). Yerd backs up an existing .test resolver when it takes over and restores it if you unelevate/uninstall, so switching back is clean.
If you want the gory details, the Architecture and HTTPS & Certificates pages in the docs walk through the CA and the proxy. Happy to go deeper on any part!