Every subsystem, with its actual config

A route is a match plus a destination. The match side reads host, path prefix, method, and exact headers; the first route that fits, top to bottom, takes the request. The destination is either an upstream pool or a canned respond — handy for health endpoints and redirects that have no business waking a backend. Need to reshape the request on its way through? rewrite strips or prepends a path prefix and can swap the Host header before the backend ever sees it.

One thing we deliberately left out: regex. Hosts match exactly, paths match on prefix, and that's the whole grammar. It keeps configs boring to read — but if your routing genuinely needs a regex engine, omlb will frustrate you today.

Every pool chooses its own algorithm: weighted round_robin, random, power_of_two (pick two backends at random, keep the less-loaded one — the sensible default), or consistent Ketama hashing for when clients need to stick to a backend. Weights are per-backend, and any backend can be dialed over TLS with its own SNI.

The gate sits in front of routing, so a request gets judged before omlb even decides where it would go — which means scans against hostnames you don't serve still get caught. It watches three things: request rate per IP (a token bucket; over the limit means 429), trap paths (touch /.env or /wp-login.php once and that IP eats a 403 on every host until ban_duration expires), and — optionally — repeated 404s inside a strike window. Strikes ship off: a Matrix homeserver or a REST API 404s legitimately all day, and we'd rather not ban your users.

Bans track the real client address even behind Docker, survive config reloads, and show up in metrics as omlb_abuse_*. Ranges on the allowlist are never touched — put your own infra there.

One YAML document, three layers: compiled-in defaults underneath, your file on top of them, and OMLB_* environment variables above both for the knobs that differ per machine. The schema rejects unknown keys outright — omlb --check fails on a typo'd key instead of quietly ignoring it, which is the difference between a config language and a suggestion box. While running, a file watcher applies edits atomically: routes, plugin chains, rewrites, cache policy, and retry/timeout budgets all swap without dropping a connection.

Structural edits — listeners, backend sets, algorithms, health checks, TLS, HA — don't hot-apply, on purpose. omlb refuses the reload and keeps serving the last good config, because half of a new topology is worse than all of the old one.

Not everything at the edge speaks HTTP. l4 entries forward raw TCP — an IRC daemon, a Postgres, anything — with two optional TLS twists: tls: true terminates client TLS using the same certificate store as the HTTPS listeners, and backend_tls: true dials onward to the backend over TLS.

Six filters ship in-process, written in Rust against zero-copy accessors: rate limiting, basic auth, IP ACLs, CORS, header injection, request IDs. This is the always-on logic an edge actually runs, and at roughly 86% of unfiltered baseline throughput it's cheap enough to leave enabled everywhere it matters.

When you need custom logic, sandboxed WASM modules load and unload at runtime through the admin API against a stable, versioned ABI. You pick the isolation per plugin: per_request spins up a completely separate instance for every call, so the worst a broken plugin can do is fail its own request — while pooled recycles warm instances through a lock-free queue and gets sandboxed code surprisingly close to native speed (a pooled header-inject plugin holds ~61% of baseline versus ~24% per-request). The catch with pooling: a guest's heap survives between requests, so save it for stateless filters you trust.

It works, and the engineering is real — but it isn't the reason to run omlb today. Treat WASM as a serious experimental extension point; for anything always-on, the native filters are the answer.

Metrics are Prometheus on a dedicated listener (127.0.0.1:9091 by default): requests and responses by class, upstream errors, backend ejections, cache hits and misses, plus the omlb_abuse_* family for the gate — bans applied, bans enforced, rate-limited requests, active bans. Logs come out pretty for humans, JSON for shippers, or native journald — pick per deployment.

The admin REST API (127.0.0.1:9090 by default) is the control plane: read status, drain or undrain a backend, trigger a reload, load or unload a plugin. The web UI is a client of this same API — anything it does, you can curl.