zeroserve: A New Approach to Web Servers with eBPF Scripting

In the crowded web server landscape, a new contender called zeroserve is making bold claims about performance and simplicity. Created by Heyang Zhou, zeroserve presents itself as a small, fast, zero-config HTTPS server that serves websites from tarballs while allowing developers to script request handling using eBPF programs.

The core innovation lies in how zeroserve approaches configuration and extensibility. Traditional web servers like nginx and Caddy separate configuration from scripting - using declarative config languages with optional scripting runtimes bolted on the side. zeroserve collapses this into a single concept: the eBPF program is the configuration.

"Those servers give you a declarative config language - location blocks, rewrite rules, map directives, try_files - and then, once the declarative language hits its limits, an optional scripting runtime bolted on the side," explains the creator. "Behavior ends up split across two layers: directives that quietly grow their own control flow, plus scripts that run somewhere in the request lifecycle you have to keep in your head. zeroserve collapses that into one thing. There is no config file. The eBPF program is the configuration."

The implementation is technically intriguing. Developers package their entire website into a single tar file, which zeroserve indexes on load and serves directly from using byte-range reads - nothing is ever unpacked to disk. This approach simplifies deployment to a single atomic file swap.

What makes zeroserve particularly interesting is its use of eBPF programs as middleware. Any .c file placed in the .zeroserve/scripts/ directory gets compiled to an eBPF object at pack time and runs on every request. Importantly, these eBPF programs run entirely in userspace, using the async-ebpf runtime which JIT-compiles the bytecode to native machine code.

"The eBPF runs entirely in userspace: zeroserve loads the bytecode into a runtime (async-ebpf) inside its own ordinary, unprivileged process, so the kernel's BPF subsystem and CAP_BPF stay out of it," the documentation explains. "async-ebpf JIT-compiles the bytecode to native machine code (it vendors uBPF), so your 'config' runs as native x86-64."

The sandboxing approach uses a pointer cage to keep programs from accessing unauthorized memory, with every memory access masked into the program's own arena. The runtime is also fully preemptible, ensuring a slow script won't stall other connections.

Performance benchmarks suggest zeroserve is competitive with established players. In tests against nginx 1.26 and Caddy 2.11 over HTTPS on an 8-core Ryzen 7 3700X, zeroserve outperformed competitors in several scenarios:

• Small static file (174 B): zeroserve served 36,681 req/s compared to nginx's 31,226 and Caddy's 12,830
• Large static file (100 KB): zeroserve achieved 8,000 req/s with nginx close behind at 7,600
• Proxying small responses: zeroserve handled 26,486 req/s versus nginx's 21,761

When compared to nginx with LuaJIT for scripting tasks, zeroserve's eBPF approach showed advantages, particularly when the preemption timer interval was tuned from the default 2ms to 10ms.

The project represents a significant technical achievement, combining several modern technologies: io_uring for I/O operations, BoringSSL for TLS termination, and a custom eBPF runtime. The complete package includes features like TLS 1.3, HTTP/2, Encrypted Client Hello, SNI certificate selection, and JA4 fingerprinting.

For developers, the programming model offers a chain of scripts that run in sorted filename order, sharing a per-request metadata map. The helper surface is broad, including request inspection and mutation, crypto and encoding utilities, JSON handling, rate limiting, AWS SigV4 support, and even OIDC login flows.

"A dynamic endpoint is just a script that responds," the documentation illustrates with a simple health check example. "Each script runs under a memory-footprint cap (256 KB by default), the runtime time-slices long-running scripts off the executor and throttles the runaways, and scripts can even call each other (zs_call) up to a bounded depth."

The project is open source on GitHub, inviting developers to explore and potentially adopt this new approach to web serving. While zeroserve currently lacks the extensive ecosystem of nginx or the user-friendly configuration of Caddy, its technical innovations and performance characteristics make it a compelling option for specific use cases.

As web server technology continues to evolve, projects like zeroserve demonstrate how combining modern kernel technologies with thoughtful user experience design can challenge established solutions. The question remains whether this technical innovation will translate into broader adoption in an already mature market.

For more information, you can explore the zeroserve GitHub repository and examine the documentation for implementation details and examples.