Honest comparison

How omlb stacks up against the incumbents

Let's start with the part vendor pages bury: on raw throughput and on years in production, the incumbents beat us. nginx and HAProxy have had two decades of C tuning; a young Rust proxy doesn't out-sprint that on a loopback. What omlb changes is the number of moving parts — balancing, health checks, HTTPS, rate limiting, and failover stop being five installs and become one process.

vs nginx vs HAProxy vs Traefik vs Caddy vs Envoy vs keepalived
Feature & operational comparison

The full matrix

built in · partial, paid tier, or bolted on · not offered. The row that matters most is the one bolded below.

capability omlbnginx (OSS)HAProxyTraefikCaddyEnvoykeepalived
L7 HTTP proxy L4 only
Automatic HTTPS (ACME) +certbot
Active health checks Plus-only
Passive outlier / circuit-break basic partial
Built-in VRRP self-HA + VIP
Rate limit + auto-ban +fail2ban no bans
Live service discovery DNS xDS
Single binary, no deps
L7 and HA in one process/config +keepalived +keepalived +proxy
Memory-safe core Rust C C Go Go C++ C
GC-free runtime
Maturity / battle-tested 🆕 young ✓✓✓ ✓✓✓ ✓✓✓ ✓✓ ✓✓✓ ✓✓✓

omlb is young — the maturity row says so plainly. nginx, HAProxy, Traefik, Envoy, and keepalived are all far more battle-tested; Caddy sits one notch behind them.

Memory-safe and GC-free

One combination in that table is genuinely rare

Every proxy in that table makes you choose: Go gives you memory safety and charges you GC pauses for it; C gives you a pause-free runtime and a long CVE history in exchange. Rust on Pingora doesn't make you choose — and the edge is exactly where you don't want to: it's where tail latency is visible and where a process is expected to run for years.

Go — Traefik, Caddy

Memory-safe. Pays GC pauses under load.

C / C++ — nginx, HAProxy, Envoy

Pause-free. Memory-unsafe by construction.

Rust on Pingora — omlb

Memory-safe and pause-free — both, at once.

Same job, three stacks

Reverse-proxy two backends, a health check, automatic HTTPS

Three ways to get there. Judge the configs yourself.

omlb — one file, done
tls:
  acme: { enabled: true, contacts: ["mailto:you@x.com"], terms_of_service_agreed: true, domains: [x.com] }
listeners:
  - { name: https, address: "0.0.0.0:443", tls: { managed: true }, http2: true }
upstreams:
  app: { algorithm: power_of_two, backends: [{addr: "10.0.0.1:80"}, {addr: "10.0.0.2:80"}],
         health_check: { kind: http, path: /health } }
routes:
  - { name: app, match: { host: x.com }, upstream: app }
nginx — nginx.conf + certbot + cron
upstream app { server 10.0.0.1:80; server 10.0.0.2:80; }
server {
  listen 443 ssl http2;
  server_name x.com;
  ssl_certificate     /etc/letsencrypt/live/x.com/fullchain.pem;   # certbot writes these
  ssl_certificate_key /etc/letsencrypt/live/x.com/privkey.pem;
  location / { proxy_pass http://app; proxy_set_header Host $host; }
}
# + certbot certonly … ; + certbot renew (cron) ; + nginx -s reload on renewal
Caddy — genuinely tidy
x.com {
  reverse_proxy 10.0.0.1:80 10.0.0.2:80 {
    health_uri /health
  }
}

Our honest read: for plain HTTPS proxying, Caddy is every bit as tidy — that's its whole pitch, and it deserves the credit. The gap opens when your edge is more than a proxy. Ask each stack for health thresholds, circuit-breaking, least-conn balancing, per-IP bans, and a failover VIP: the omlb answer is still that one file, while the nginx and Caddy answers grow a keepalived, a fail2ban, and a tuning afternoon. HAProxy can do the most of the four on its own — but you'll write it in the least approachable config language of the four, and you're still bringing keepalived for HA and certbot for certificates.

Is it for you?

Pick honestly

Pick omlb when…

  • Your edge is a VPS, a bare-metal box, or a homelab that got serious — and it currently takes nginx or Caddy plus certbot plus keepalived plus fail2ban to run properly.
  • You want a second node to take over when the first one dies, without learning and operating a whole separate daemon to get it.
  • Your backends live in a config file or as Docker containers on the same host — you know what they are and where.
  • You want CI to reject a broken edge config before it ships, and you want to be able to read the whole thing in one sitting.

Pick something else when…

  • You're on Kubernetes, or backends come and go behind Consul, DNS-SRV, or xDS — omlb doesn't do live discovery; that's Traefik and Envoy territory.
  • You need mTLS client auth, HTTP/3, regex routing, or auto-issued wildcards today — none of those have shipped yet.
  • The only number on your scorecard is single-box RPS. A decade of C tuning still wins that race, and pretending otherwise would be silly.

If a single box's request rate is the whole contest, take nginx or HAProxy and don't look back. If what you want is an edge you can read, --check, and reason about as one thing — that's what omlb is for.

Numbers, not vibes

The throughput, latency, and failover measurements behind this page — methodology, caveats, and how they line up with independently published Pingora-vs-nginx results.