Yerd rewrote itself in Rust and left a Go binary in your PATH

A leftover Go binary will block the Arch install

There is an Arch-specific note that tells you more about this project's history than any changelog entry. If you have a leftover /usr/bin/yerd from the old v1 Go project, remove it first, because pacman refuses to install over a file it does not own. The same note asks you to run pacman -Syu before installing or upgrading, so the WebKit and GTK libraries the app links against match what it was built with. Both instructions exist because the current Yerd is a native Rust application where the previous one was written in Go, and the migration left residue on installed machines. This is the kind of detail a project only publishes after enough Arch users hit it, and it is worth searching your PATH for before you download anything rather than after the package manager refuses.

One elevation covers CA trust, DNS routing and ports 80 and 443

Yerd needs root exactly once. On first launch the app starts its bundled daemon, then walks you through a one-time elevation:

sudo yerd elevate    # trust the CA · route *.test · allow 80/443

Three separate privileges are bundled into that single step: trusting the local certificate authority so browsers accept generated certificates, adding a route so that *.test names resolve to the machine, and binding ports 80 and 443. Everything after that runs as your user and never as root, which is the whole basis of its rootless claim. The fallback matters for locked-down networks. If you cannot route .test at all, every site is still reachable at http://localhost:8080/~<name>.test, so a machine that forbids DNS interception and privileged ports still works, just at a less convenient address. On Linux the CLI lands on your PATH through the package; on macOS you install it from Settings, Terminal CLI, Install.

Three binaries in one bundle, and a workspace with twenty-four members

Nothing is downloaded at runtime. The desktop app embeds three executables: the daemon named yerdd, the CLI named yerd, and a privileged one-shot helper named yerd-helper. The tray interface is described as a thin client over a background daemon of roughly eight megabytes, which is what lets every button in the GUI map onto the same daemon the CLI drives, so the two surfaces cannot drift apart. The Cargo workspace makes the structure concrete and it is more granular than the feature list suggests. Alongside the obvious pieces for config, TLS, platform, DNS, supervision, PHP, services, tunnel, proxy, doctor, mail and updates, there are separate crates for IPC, dependency checking, service control, release manifest building, and one for MCP. The bins are workspace members in their own right, and there is an xtask crate on top for build automation.

Six package formats, two architectures, four distributions, no Intel Mac

Installation is a download from the releases page followed by the native installer for your platform. macOS has one artifact, an Apple Silicon dmg you open and drag to Applications. Debian and Ubuntu have a deb for x86-64 and another for arm64, installed with sudo apt install. Arch has a pkg.tar.zst for x86-64 installed with sudo pacman -U, and Fedora has rpms for both architectures installed with sudo dnf install. That is six packages covering three Linux distributions and one macOS architecture. There is no macOS Intel build in the table, which means an Intel Mac user is not served by any listed artifact even though macOS support is marked as present in the feature comparison. The comparison also carries Windows as unsupported with a note saying it is planned, and the project says plainly that Yerd runs today on macOS and Linux.

Per-site PHP pinning is the feature the comparison argues about

The PHP version story has two levels and the second one is the differentiator. Installing a version and making it the global default are two separate actions:

yerd install php 8.5    # download + install a PHP version
yerd use 8.5            # make it the global default

Then a version can be pinned to one site alone, which is what lets a legacy application and a new one coexist:

yerd park ~/Sites            # ~/Sites/blog -> http://blog.test
yerd link my-app ~/code/my-app   # -> http://my-app.test
yerd secure my-app           # -> https://my-app.test (trusted local CA)
yerd use my-app 8.3          # pin just this site to a PHP version

Parking a folder turns every sub-folder into a name.test site, while linking attaches one project. Native MySQL, MariaDB, PostgreSQL and Redis run as processes with no Docker, and mail capture plus a Laravel dump and query inspector are included rather than held back. In the comparison table those database, mail and dump features are marked as Pro-only for Herd and absent for the container-based alternative, while the tunnel is missing from that alternative entirely.

The row that decides the comparison is the one under the hood

A feature table with fifteen rows of ticks is marketing, and the row that actually separates the three tools is the last one. Herd is a native application built on nginx and dnsmasq. The container-based alternative runs everything in rootless Podman, so it adds database and cache services trivially but pulls and runs container images rather than native processes. Yerd is native Rust, described as a rustls proxy with embedded DNS. That single difference propagates upward: no containers means no image pulls and no container runtime to install, and the eight megabyte daemon is the size of the whole running system rather than a front end to something heavier. The notes also place all three against Laravel Valet, the original macOS-only tool installed through Homebrew and Composer, and state that none of the three require it.

Update verification uses minisign while the tree sits on a release candidate

The dependency list shows how updates are checked. Two crates handle signature work: minisign-verify at 0.2 for verification and minisign at 0.7, alongside sha2 for digests, and separate crates exist for the update logic and for assembling a release manifest. Several dependencies are pinned with an exact version rather than a range, including tempfile, rcgen at 0.13.2 for certificate generation with ring, the time crate, and clap. The workspace itself declares resolver 2, edition 2021, a minimum rust-version of 1.77, licence MIT, and publish set to false, so this is not a library anyone installs from a registry. The workspace version reads 2.1.0-rc.1, which is the same string as the newest tag. The install instructions, meanwhile, tell you to grab the latest stable release.

Editorial conclusion

Yerd fits a team that wants Laravel-style local serving without Docker and without root on every command, and its per-site PHP pinning is the feature that would justify the move. Before installing, check whether you have a leftover yerd binary from the earlier Go release, because on Arch it will block the package manager outright, and decide whether the rootless-but-elevation-requiring model matches your machine policy. If you need Windows, the project says it is not supported yet, so look elsewhere. Read the comparison table under the hood row rather than the feature ticks, since that row is where Yerd and the container-based alternative actually differ.

Frequently asked questions

Official sources

1. forjedio/yerd on GitHub
2. Issues
3. License: MIT
4. README
5. Releases