Hi HN,

Sōzune is a reverse proxy I've been building on top of Sōzu (https://github.com/sozu-proxy/sozu), the Rust proxy from Clever Cloud. Sōzu is fast and reload-without-downtime, but it's a low-level building block — you talk to it over a socket and feed it config. Sōzune wraps it with the part most people actually want from a proxy in 2026: it discovers your services automatically (Docker/Podman labels, Swarm, Kubernetes Ingress + Gateway API, Nomad, an HTTP endpoint, or a plain YAML file), provisions and renews Let's Encrypt certs, and applies every change live with no restart.

The mental model is Traefik, but the data plane is Sōzu instead of a Go proxy. That's the bet I'd most like feedback on.

Try it:

    # compose.yaml
    services:
      sozune:
        image: kemeter/sozune:latest
        ports: ["80:80", "443:443"]
        volumes:
          - /var/run/docker.sock:/var/run/docker.sock
      whoami:
        image: traefik/whoami
        labels:
          - "sozune.enable=true"
          - "sozune.http.whoami.host=whoami.localhost"

    docker compose up -d
    curl -H "Host: whoami.localhost" http://localhost

What works today: HTTP/HTTPS/WebSocket/raw TCP, HTTP/2 over ALPN, wildcard + regex hostnames, header rewriting, method-based routing, forwardAuth (Authelia/Authentik), Docker HEALTHCHECK-gated readiness, and a dashboard for diagnostics.

  What's deliberately not there yet: DNS-01 / wildcard certs, IPAllowList, per-router TLS options, GRPCRoute/TCPRoute on the Gateway API. The roadmap is public and honest about the gaps.

  Questions I'd genuinely like answered:
  - Is "Traefik UX on a Sōzu data plane" a reason to switch, or a curiosity? What would make it a reason?
  - For people running Traefik/Caddy/nginx in prod: what's the one feature whose absence is a hard no?
  - Anyone running Sōzu directly — does a higher-level layer on top help or get in your way?

Repo: https://github.com/kemeter/sozune — Site & docs: https://sozune.kemeter.io — MIT licensed. I'll be around all day to answer.

Author here — happy to expand on the design choice that I expect to be the first question: why Sōzu as the data plane, instead of Pingora, Envoy, or writing the proxy myself?

  Three reasons:

  1. Reload without downtime is a primitive in Sōzu, not a feature I had to build. Config changes — new backend, cert rotation, route change — are applied to live connections without dropping them or restarting a process. For an autodiscovery
  proxy where the config changes every time a container starts or stops, that's the whole game. Building that correctly on top of hyper/tokio myself would have been the bulk of the project, and I'd have shipped a worse version of what Sōzu already
   does.

  2. It's a proven data plane, not a weekend's worth of socket code. Sōzu has been run in production by Clever Cloud for years. I'd rather inherit that hardening than re-discover every TLS/HTTP edge case the hard way.

  3. Pingora vs Sōzu: Pingora is a library you build a proxy *with* — it gives you the networking, you still write the proxy. Sōzu is a proxy you *drive* over a control socket. Sōzune is fundamentally a control-plane problem (discover services,
  reconcile desired state, manage certs), so starting from a thing I drive rather than a thing I build was the shorter path to something correct. Envoy would have worked too, but xDS + the operational weight of Envoy is exactly the complexity I'm
  trying to spare people.

  The honest trade-off: I inherit Sōzu's constraints. Backends must be IpAddr (no DNS backends — I resolve to pod/container IPs myself), and feature velocity on the data plane isn't mine to control. The roadmap calls out what that blocks. If
  you've run Sōzu directly, I'd really like to hear where a layer on top helps vs. gets in the way — that's the feedback I posted for.