LAN sharing Beta

Beta feature

LAN sharing is new and still settling. If you hit a problem, please report it on GitHub - include your OS, yerd lan status output, and what you expected.

By default Yerd serves your .test sites only to the machine they run on - every listener binds 127.0.0.1. yerd lan opts into exposing them to other devices on your local network (a phone, a tablet, another laptop) over the same ports 80/443, and yerd remote-setup provisions a device so it trusts Yerd's CA and resolves .test.

This exposes your dev sites to the network

LAN sharing binds the web proxy and DNS responder to 0.0.0.0, so anything that can route to your machine can reach your sites (subject to the peer filter and your host firewall). It is opt-in and off by default. Turn it off with yerd lan disable when you're done. Don't enable it on an untrusted network.

Commands

Command	Description
yerd lan enable	Expose .test sites to the LAN, then restart the daemon to re-bind.
yerd lan disable	Return to loopback-only, then restart the daemon.
yerd lan status	Show configured-vs-effective state, the LAN IP, and the next step.
yerd remote-setup	Mint a one-time command to provision another device.

How it works

• The web proxy and DNS responder bind 0.0.0.0 while LAN mode is on. A peer filter drops any connection whose source address isn't private (RFC 1918 / link-local / loopback) - a blast-radius reducer, not authentication, so a host firewall is still recommended.
• DNS answers split-horizon. Your own machine keeps resolving .test to 127.0.0.1; other LAN devices get your machine's LAN IP. IPv6 (AAAA) is not served in LAN mode.
• Databases, mail capture, dumps, and the IPC socket stay loopback-only. Only the web + DNS + the bootstrap endpoint leave loopback.
• Enabling or disabling restarts the daemon (a listen socket's bind address is fixed when it's opened), so the change is enforced, not merely saved.

Privileged setup for ports 80/443

LAN devices expect the well-known ports. Binding them needs a one-time, per-machine privileged step - the same mechanism as ordinary Yerd use:

• macOS: run sudo yerd elevate ports (if you haven't already) andsudo yerd elevate lan. The first installs the loopback redirect for on-host access; the second installs a pf redirect that carries inbound LAN 80/443 to Yerd on your LAN IP. Remove the LAN rule later with sudo yerd unelevate lan.
• Linux: run sudo yerd elevate ports once (it grants cap_net_bind_service, which covers the 0.0.0.0 bind). No separate LAN step.

yerd lan status tells you whether these are in place.

Firewall

Yerd does not configure your firewall. Allow these from your LAN subnet only:

Port	Protocol	Purpose
80, 443	TCP	web proxy
1053	UDP + TCP	.test DNS responder (or your configured dns_port)
7073	TCP	remote-setup bootstrap (or your configured lan_setup_port)

Example (ufw, replace the subnet):

sudo ufw allow from 192.168.1.0/24 to any port 80,443,7073 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 1053

IPv6

Yerd binds only IPv4 (0.0.0.0) listeners, so there is nothing to reach over IPv6 today. Note only that IPv4 firewall rules don't cover IPv6 in general.

Provisioning a device — yerd remote-setup

A remote device needs two things to use your .test sites: it must trust Yerd's CA (for HTTPS) and resolve .test to your machine. yerd remote-setup prints a command that does both. It only works while LAN mode is up.

$ yerd remote-setup
Run this on the OTHER device (needs sudo, curl, and openssl):

  curl -fsS --retry 3 -o yerd-setup.sh 'http://192.168.1.42:7073/remote-setup?code=…' && [ "$(openssl dgst -sha256 -r yerd-setup.sh | cut -d' ' -f1)" = "<sha256>" ] && sudo bash yerd-setup.sh

It is a single line: download the self-contained installer, check its SHA-256 matches, then run it. The installer embeds Yerd's CA, so there is nothing else to fetch.

The hash is the trust anchor - verify it

The installer is served over plain HTTP, so its integrity comes entirely from the SHA-256 printed on your screen. The pasted command checks the download against that hash and, on any mismatch, the && chain stops before sudo runs. The hash travels by your eyes, not the wire - that's what makes this safe. Do not edit it out. The code is single-use and expires in 15 minutes.

Supported devices: macOS and Linux with dnsmasq or NetworkManager. A Linux box using systemd-resolved alone is not supported (it can't forward a single domain to a custom port) - install dnsmasq or use NetworkManager. On Linux the CA is installed into whichever trust anchor directory the distro provides (Debian/Ubuntu, RHEL/Fedora or Arch) and into the desktop user's NSS databases, so Firefox, Chromium and Brave trust it too (best-effort, when certutil from nss / libnss3-tools is present).

Windows devices are not supported. Windows has no built-in way to forward a single domain to a nameserver on a non-standard port - its NRPT rules (Add-DnsClientNrptRule) take a server address but no port, and the hosts file can't express a wildcard. Pointing a Windows box at Yerd needs a local DNS proxy (such as Acrylic) configured by hand, so there is no bootstrap script for it.

Undoing it on a device

Yerd can't revert a device it doesn't control. On each provisioned device, run the installer's uninstall mode to remove the CA (system store and browser NSS databases) and the resolver entry:

sudo bash yerd-setup.sh uninstall

Headless / always-on hosts

If you share from a machine you don't stay logged into, enable a persistent user session so yerdd keeps running (Linux):

sudo loginctl enable-linger "$(whoami)"

See the daemon guide for details.

Turning it off

yerd lan disable

This restarts the daemon back onto loopback. On macOS the pf LAN redirect is separate privileged state - yerd lan status flags it as residual until you run sudo yerd unelevate lan. A full yerd uninstall removes it too.