Zeroserve: A zero-config web server you can script with eBPF

What do you mean it's dead? It's up at: https://www.techempower.com/benchmarks/#section=data-r23 with the last benchmark having been in February 2025, but they don't run their benchmarks that often, only once a year or less as its rounds history indicates.

LLM UI/UX is so bad. Like how hard is it to put a weekends effort into UX for something like this.

I wouldn’t be so sure.

Seems like every configuration file format starts off simple. Look at YAML - the basics started off pretty sensibly.

And then people decided they wanted to get fancier with anchors and aliases. Even GitLab has its own form of conditionals and variables, which is all a bit of a hack (only works in certain places).

Even Apache fell into this with its XML based config format.

So we end up with numerous “bespoke” programming languages for configuration management. Of course enterprise people don’t edit these directly - they script Ansible workflows to remotely perform the surgery.

Sadly, could have skipped all that and just have embedded a Lua/Python/etc. interpreter into servers to do the configuration management. Would be simpler than trying to programmatically edit bespoke config files.

Sure, one will say all the bespoke attempts are optimized for a specific use the way a general language isn’t. Except that only fits a narrow class of toy examples which wouldn’t have needed their machinery in the first place!

Remember Windows INI files? Back in the good ol’ days when code was code and data was data….

I'd wager that in the next 96 hours, with a LLM, someone could create a translator that would 'pack' a nginx or caddy configuration file into the relevant code that zeroserve could use. Or even more simply, just pickup all the Ingress manifests in a kubernetes cluster and rebuild the pack. The point being, the interface between the tool and the configuration is just another API, system operators are already describing the state of the system at higher level constructs, and the specific bytes that make up the configuration are an artifact of that.

I suspect it's worth exploring if that will change as AI is allowing more and more "human words -> machine effect", which may be more ergonomic for the AIs. It could take a long time for that kind of shift to become clearly a good idea since the AI can make either work.

What about abstracting the complexity and achieving "config file" configuration with macros?

Why are you so eager to credit LLMS.. Just because they wrote the article with the help of an LLM doesnt mean they're out here having LLMs do the experiments for them.

Hi, author here - a few critical pieces of this, like async-ebpf, were written long before those coding agents were released. I use AI assistance a lot when creating zeroserve itself, but I manually check AI output and take responsibility for it :)

Given the benchmarks:

Small static file (174 B) - the bread and butter of static sites:

server req/s p99

zeroserve 36,681 5.4 ms

nginx 31,226 7.8 ms

Caddy 12,830 22 ms

zeroserve serves small files about 17% faster than nginx on a single core, with a tighter tail. HTML pages, small JSON, CSS - this is the case zeroserve is tuned for.

Large static file (100 KB):

server req/s throughput p99

zeroserve 8,000 782 MB/s 22 ms

nginx 7,600 773 MB/s 28 ms

Caddy 6,084 590 MB/s 44 ms

I'd go with a more storied project that's been audited, battle tested, hardened etc than this upstart. There's not enough improvement to justify the risk.

> It's a weird world, if this would've been announced without any AI disclaimers some years earlier I would've eaten it up without a doubt. But right now if I see a fancy README with several good-looking command line parameters I immediately wonder if the README is hallucinated and the command line parameters actually exist.

Yeah, that is unfortunate. Recently there was this ffmpeg-wasm project. I tested it. It worked. But it was vibe-coded AI. I can't stand AI. Even if things work.

I decided to stay in the oldschool era as much as possible. Clever people publish software. Clever people maintain software. They don't need AI. That's my niche.

We may die out but I still prefer that. (Oh, and only if these clever people write documentation. Many clever people hate writing documentation. I decided a long time ago that if software comes without documentation, it is not worth my time, no matter how great that documentation is. This refers mostly to on-the-application side; I only rarely looked at the Linux documentation, but others stated that it is not too terrible either, so who knows.)

Hi, thanks!

Will implement forking + SO_REUSEPORT. I've been using nftables for things like this so haven't needed it for myself yet :)

I was curious for the same thing, so I quickly (with an agent) threw support for .rs scripts together on my fork:

https://github.com/tekacs/zeroserve/commit/b33f261615d20d55b...

It does leave me wondering about other runtimes that could be used as the go-between though, because at the point of compiling Rust, an approach like Cloudflare's Pingora (https://github.com/cloudflare/pingora) which I've tried using before... in _theory_ should be a 'nicer' solution - just historically awkward when I've tried using it the way that I'd have liked. Wish it were more library-shaped!

I did last week (converted ghost to static) and was half wondering if some self contained binary wouldn't be faster so I feel like this was made for me, but I accept I'm not the typical user

Depends on the domain. There's a bunch of sciences using large datasets served up efficiently using static file formats, e.g., https://zarr.dev/ and https://parquet.apache.org/

I did it yesterday.

how did you come to this conclusion ?

It's a simple format easily suitable for accessing resources by byte ranges, that everyone has tooling for, and which _doesn't_ compress things.

Well, according to first paragraph of the section titled "One tarball, served in place":

The whole site is a single tar file. zeroserve indexes it on load - building a path -> byte-range map - and then serves files by issuing byte-range reads against the tarball itself. Nothing is ever unpacked to disk. The site lives entirely in that one file, so there's no document root for a stray location rule to expose, and a deploy is a single atomic file swap.

OTOH, that could be an LLM justification, since the copy is littered with -isms like "the right shape" or "the surface is broad".

Well there's less concern because of how no one cares about latency these days.

You don't serve up a bazillion js files and care about latency. You also don't serve up files from all over the web (fonts from google, jquery or whatever from their site) unless you don't care about having control over your own latency.

A static HTML page renders in under 20ms for me these days, if the site is near. Some of these pages with immense blather of js take > 10 seconds to fully download and render. So... in that world, who cares if it's 5 seconds or 6 seconds?

> All you did was ask the slop generator to make it.

Is this founded? I know it's popular to trash every new project that's built with AI in the pipeline somewhere, but there's a big difference between a project built by someone with years of experience writing software and some vibing a repo with Claude. Isn't it worth distinguishing between the two?

In the case of this project: a non-technical person couldn't even conceive of this product. So I think some kind of evidence should be presented before we say things like "Is it a logical design? Who knows."

EDIT: Taking a look at the source, it looks very good. https://github.com/losfair/zeroserve/blob/main/src/server.rs is an important part of the functionality, and it looks like it had a fair amount of attention paid to the implementation, including multiple refactors.

You should post the results of your source code audit.