A web server that JIT-compiles your Caddyfile to machine code claims 3x throughput — the thread asked: 35k qps for whom?

A Caddyfile compiled down to machine code

zeroserve's post (157 points, 49 comments) describes an unusual pipeline. zeroserve is a zero-config, io_uring-based HTTPS server; the new Caddy-compat mode takes a Caddyfile, JIT-compiles it to eBPF, then lowers that to native x86_64/ARM64 machine code and runs it inside an io_uring event loop. The headline claim is 3x throughput and 70% lower latency versus Caddy. The supported surface is a deliberate subset — request routing, matchers, header mutation, URI rewriting, static file serving, single-upstream reverse_proxy, basic auth, maps and variables.

What's left out is the catch. Per the project's compatibility doc, there is no TLS automation or ACME runtime, no Caddy/Go plugins, no response-body rewriting, no FastCGI, no Prometheus metrics, and only gzip/zstd compression. The thread split immediately on whether the speed is worth the subtraction.

"Caddy compatible minus everything that matters"

The two most-cited missing pieces were the two people actually rely on:

"No ACME! That is a dealbreaker" — tln

"'Caddy compatible' minus everything that matters, like ACME and plugins. And NGINX still steals the show. Not everything needs to be rewritten." — codingjoe

Automatic HTTPS via ACME is the single feature most people choose Caddy for. A compat mode that drops it is compatible with the syntax, not the reason. A separate observer noted nginx held up surprisingly well in the comparison — the incumbent quietly winning the benchmark it was being measured against.

The number that reframed the whole project

The sharpest reversal wasn't skepticism about the benchmark — it was accepting it and asking who it's for. A senior engineer ran the arithmetic on the project's own figures:

"My back end on a single host isn't pumping at 35k qps. If each request is 500 bytes, 35k qps is nearly 20mbps sustained with zero other io… And this is using only two threads! …It's optimizing for a metric that wasn't a bottleneck in the first place." — bastawhiz, Senior engineer at Runway

That is the load-bearing critique. The earlier, gentler version of it came from a reader who asked the obvious question before any numbers landed: "has anyone ever encountered a use case where the Caddy was the bottleneck?" If horizontal scaling already exceeds your real traffic, a 3x web-server speedup optimizes the part of the stack that was never the constraint.

io_uring, JIT, and the security bill

The deeper unease was about attack surface, not speed. JIT-compiling a config into a running web server alarmed practitioners:

"The idea of jit compilation of a web server in a small project is pretty terrifying to me. The attack surface here is enormous." — bastawhiz, Senior engineer at Runway

io_uring drew its own warnings. "Exposing services that use io_uring is a hard pass. It's only been a handful of weeks since the last security advisory," wrote one reader; another said every resource he found called io_uring less safe for a public web server. A French commenter eyed the "3400 lines lock file and AGENTS.md" as signs of AI-heavy authorship, and one reader dismissed it outright:

"Another vibe coded, dead in 6 month Rust project. People that trully need performance are not going to use a random server that has 0 support/ track record." — Thaxll

A real engineering trick aimed at a problem most people don't have

The pipeline is genuinely clever — lowering a declarative config to native code on io_uring is the kind of thing that wins benchmarks. But the thread's verdict is a coherent one: the throughput is real and largely irrelevant, because the bottleneck for a typical backend isn't the web server, and the trade — no ACME, a JIT attack surface, io_uring's exposure profile, no track record — costs more than the speed returns. If you operate at a scale where 35k qps on two threads is your floor, this is interesting. Almost nobody does.