relayd

Last reviewed Sep 13, 2026 · 772 words

relayd is not something you install. It ships inside OpenBSD's base system, and the correct way to run it is on an OpenBSD box, configured from one text file, with the pf firewall doing half the work. If your infrastructure is Linux containers, that single fact should end the evaluation: HAProxy does the same job there with far more documentation and community answers. relayd earns its place when you already run OpenBSD at the edge and want a load balancer that is audited with the OS, needs about 32 MB of RAM, and has no package to update separately.

Two modes that people confuse

relayd does two different things and the config keywords are not interchangeable. A redirect is layer 3: relayd health-checks a table of backends and rewrites pf rules so the kernel forwards traffic straight to the healthy ones. Throughput is whatever pf can do, and relayd is only ever in the data path for health checks. A relay is layer 7: relayd terminates the TCP connection, can terminate TLS, inspects HTTP, and opens a new connection to the backend. Use redirects for raw TCP services where you want speed and use relays where you need TLS offload or header rewriting.

A working redirect for two web servers looks like this:

ext_addr="203.0.113.10"
table <web> { 10.0.0.11 10.0.0.12 }

redirect www {
    listen on $ext_addr port 80
    forward to <web> check http "/" code 200
}

For it to do anything, /etc/pf.conf must contain anchor "relayd/*" so relayd can load its rules. Forgetting that anchor is the most common first-hour failure, and the daemon does not complain about it loudly.

TLS termination is fine, certificate handling is manual

A layer 7 relay with TLS looks like:

http protocol https {
    match request header set "X-Forwarded-For" value "$REMOTE_ADDR"
    tls keypair example.com
}

relay https {
    listen on $ext_addr port 443 tls
    protocol https
    forward to <web> port 80 check http "/" code 200
}

relayd reads the certificate from /etc/ssl/example.com.crt and the key from /etc/ssl/private/example.com.key. There is no built-in ACME client; the OpenBSD pattern is acme-client renewing on a cron and relayctl reload afterwards. If automatic certificates with zero configuration are the main thing you want, Caddy is the right tool and relayd is the wrong one. The reverse proxy showdown covers that end of the spectrum.

Operational feel: terse, but predictable

relayd -n validates the config, rcctl enable relayd and rcctl start relayd bring it up, and relayctl show summary shows every table, host and health state in a few lines. Health checks support ICMP, TCP, HTTP status codes, HTTP body digests and TLS handshakes, with intervals in seconds. The man pages are the documentation, and they are complete, which is a different experience from wading through blog posts. The cost is that the config language gives you no hints when you get something wrong; a misplaced keyword produces a one-line parse error and nothing else.

Where it stops

There is no dashboard. There is no metrics endpoint you can scrape without writing a wrapper around relayctl. HTTP/2 to clients is not something I would rely on. Sticky sessions exist in a limited form. Layer 7 throughput is well below HAProxy's on the same hardware, because HAProxy has had fifteen years of tuning for exactly that. For a home lab with under 100 requests per second none of that matters; for a busy public service it does.

Who actually runs this

Three kinds of people: OpenBSD firewall admins who want failover for a couple of internal services without adding a second daemon from ports; people building a small hosting edge who value the OS's security posture over feature count; and tinkerers who like a system where the whole stack is one coherent, audited codebase. Everyone else is better served in the proxy category by HAProxy, Traefik or Caddy, which is not a criticism of relayd, just a description of its scope.

What I'd do

If I already had an OpenBSD box as a firewall, I would use relayd for redirects to internal services and TLS relays for anything simple, with acme-client on a weekly cron and a relayctl show summary check wired into monitoring. I would not install OpenBSD to get relayd. On a Linux host, HAProxy for load balancing and Caddy for web fronting cover the same ground with far less friction, and that is what I run on every non-OpenBSD machine I own.