HN Debrief

Caddy compatibility for zeroserve: 3x throughput and 70% lower latency

  • Infrastructure
  • Security
  • Open Source
  • Developer Tools

The post announces “Caddy compatibility” for zeroserve, a Rust web server that uses io_uring and user-space eBPF, and claims a big speedup over Caddy on a simple HTTPS benchmark. The compatibility layer is deliberately partial. It targets core Caddyfile-style behavior, not the parts most operators lean on in production. That shaped the reaction. People were impressed that it can beat Caddy so decisively and still land near NGINX, which many see as the real reference point for optimized HTTP serving. But the praise stopped there. The biggest practical complaint was that ACME support is intentionally absent, which makes automated TLS certificate issuance and renewal unavailable out of the box and kills the “Caddy compatible” pitch for many readers. Several comments also pointed out that the benchmark is extremely synthetic. For most applications, the origin app or database is slower than the proxy, so a faster frontend only matters in narrow cases like heavy TLS handshake load, high connection churn, or huge rates of tiny responses.

Treat zeroserve as an interesting high-performance experiment, not a drop-in reverse proxy choice. If you care about replacing Caddy or NGINX, the practical blockers today are certificate automation, ecosystem maturity, and whether your workload is actually proxy-bound enough to justify the extra risk and operational novelty.

Discussion mood

Impressed but unconvinced. People liked the engineering and the fact that NGINX still remains hard to beat, but the dominant reaction was that missing ACME, immature ecosystem, synthetic benchmarking, and security concerns around io_uring and JITed eBPF make this hard to justify outside very specific high-throughput edge cases.

Key insights

  1. 01

    mTLS browser UX is still broken

    Client certificates are not inherently shady. The problem is that browsers still present them with terrible context and recovery paths, so a valid mutual TLS setup can look indistinguishable from a misconfigured or hostile site. That matters more than the protocol purity. If a public demo prompts users to pick from personal certificates, trust drops immediately and support burden goes up. The pain gets worse once you mix mutual TLS with cross-origin requests, where preflight handling can fail in inconsistent ways across browsers.

    If you use mutual TLS for anything user-facing, test the full browser flow and not just the crypto. For public demos and broad audiences, avoid certificate prompts entirely unless client auth is the core product requirement.

      Attribution:
    • 1a527dd5 #1
    • KronisLV #1
    • mook #1
    • Avamander #1 #2
  2. 02

    No ACME means no real Caddy replacement

    Automated certificate issuance and renewal is not a nice-to-have here. It is the main reason many teams choose Caddy in the first place. Calling the project Caddy-compatible while intentionally excluding ACME turns the compatibility claim into a parser and config-shape story, not an operational one. A plugin might eventually close the gap, but until it exists this does not replace the workflow people actually depend on.

    If you are evaluating frontend servers, score certificate lifecycle automation as a first-class feature. Benchmarks do not compensate for losing hands-off TLS operations.

      Attribution:
    • tln #1
    • codys #1
    • codingjoe #1
    • __natty__ #1
  3. 03

    The benchmark only matters for edge-heavy traffic

    Proxy performance is usually not the bottleneck because app code, databases, and upstream services dominate latency and CPU. The cases where frontend efficiency suddenly matters are specific and brutal: lots of short-lived TLS connections, poor session resumption, or massive rates of tiny responses where parsing and allocation overhead become the workload. That makes the reported speedup credible but narrow. It says more about a class of edge workloads than about typical web apps.

    Check where your CPU time actually goes before chasing a faster reverse proxy. If your traffic pattern is not handshake-heavy or ultra-small-response, this result probably will not move your production latency or costs much.

      Attribution:
    • keynha #1
    • zsoltkacsandi #1
    • miladyincontrol #1
  4. 04

    User-space eBPF changes the risk profile

    Zeroserve uses the eBPF instruction set without relying on the Linux kernel's eBPF runtime, so the usual verifier limits and kernel-safety assumptions do not automatically apply. That cuts both ways. It frees the design from kernel runtime constraints, but it also means you cannot borrow the kernel eBPF security story wholesale and call the problem solved. Defenders of the design were right that JIT alone is not the issue. The hard question is whether this specific implementation is simple enough to audit and strong enough to sandbox safely.

    Do not generalize from “eBPF is researched” to “this server is safe.” Ask for the exact execution model, isolation boundaries, and audit surface before exposing it to untrusted traffic.

      Attribution:
    • codys #1
    • bastawhiz #1
    • 10000truths #1
  5. 05

    NGINX is still the real performance baseline

    The standout result for several readers was not that Caddy lost badly. It was that NGINX stayed highly competitive despite being older and far more feature-rich. That reinforces a familiar lesson in systems software. Mature infrastructure that has spent years shaving hot paths is hard to outrun by enough to matter operationally. A new server has to beat it on speed and still close the feature and reliability gap, which is a much taller order than winning a benchmark chart.

    When a new proxy claims breakthrough performance, compare it against NGINX and your own deployment constraints, not just against a more convenience-oriented server. The incumbent to displace in serious edge serving is still NGINX.

      Attribution:
    • phillipseamore #1
    • augunrik #1

Against the grain

  1. 01

    The certificate prompt is normal mTLS

    The scary browser popup was framed by some as suspicious behavior, but the simpler explanation is a standard client-certificate request. Browsers ask whether to present a certificate, users can decline, and the server may still continue if client auth is optional. In environments with strict internal security, this is routine. The alarming part is mostly the browser interface, not the protocol itself.

    Do not treat every client-certificate prompt as malicious. First check whether the site is doing optional mutual TLS, then judge whether that choice makes sense for the audience.

      Attribution:
    • naturalmovement #1 #2
  2. 02

    JIT itself is not the security problem

    The strongest pushback on the security critique was that many mainstream stacks already run dynamically compiled or embedded code on request paths, from Spring Boot to PHP to NGINX with Lua. The presence of a JIT does not determine the attack surface by itself. What matters is whether the runtime is small, sandboxed, and auditable. That does not prove zeroserve is safe, but it does undercut blanket “JIT is terrifying” objections.

    When reviewing systems that execute generated code, focus on sandbox boundaries and implementation complexity. Rejecting a design because it uses JIT misses the part that actually predicts risk.

      Attribution:
    • cowsandmilk #1
    • 10000truths #1

In plain english

ACME ↩
Automatic Certificate Management Environment, a protocol for automatically issuing and renewing TLS certificates, commonly used with Let's Encrypt.
Caddy ↩
An open source web server and reverse proxy known for simple configuration and automatic HTTPS certificate management.
client certificate ↩
A digital certificate presented by a user or device to prove its identity to a server.
eBPF ↩
Extended Berkeley Packet Filter, an instruction set and execution model originally popularized in the Linux kernel for running restricted programs safely and efficiently.
HTTP ↩
Hypertext Transfer Protocol, the standard application protocol used by web browsers and web services.
HTTPS ↩
HTTP carried over TLS, which encrypts web traffic between client and server.
io_uring ↩
A Linux interface for high-performance asynchronous input and output operations.
JIT ↩
Just-in-time compilation, where code is compiled during program execution instead of ahead of time.
latency ↩
The time it takes for a request to get a response.
Lua ↩
A lightweight scripting language often embedded inside other software such as web servers.
nginx ↩
A widely used web server and reverse proxy that handles network traffic for websites and applications.
PHP ↩
A widely used server-side programming language for web applications.
Spring Boot ↩
A popular Java framework for building web applications and services.
TLS ↩
Transport Layer Security, the encryption layer used to secure HTTPS and many other network protocols.

Reference links

Project documentation

Security and authentication references

  • Passkey PRF
    Mentioned as a modern way that might improve parts of the client-authentication experience around mutual TLS.
  • Is eBPF Turing-complete
    Shared to discuss whether eBPF should be thought of as Turing-complete and how that differs from verifier limits in the Linux kernel runtime.