Vermell: a zero-dependency C++ web framework built directly on Linux epoll

What Vermell is

Vermell is a newly released open-source web framework for modern C++ that surfaced on the Hacker News front page via its GitHub repository. According to the project's README, it is deliberately small: one header to include, one static library to link, and nothing else — no runtime, no garbage collector, no framework-specific DSL and no vendored dependencies. The code you compile is ordinary C++ with no intermediate layer, and the README positions the project as the successor to an earlier framework called Vibe. Full documentation is hosted at vermell.cc in a bilingual English and Spanish manual.

An epoll loop with a worker pool

Under the hood Vermell is event-driven. A non-blocking epoll loop reads incoming requests and hands work off to a pool of worker threads. The README credits this split for keeping the server fast under load and resilient against slow clients, since the event loop never stalls waiting on a single connection. The framework's entire dependency footprint consists of base Linux APIs: sockets, epoll, pthreads and fork/exec.

That design makes Vermell Linux-only. macOS and Windows are explicitly unsupported because epoll is a Linux kernel facility, but the README says anything Linux-derived with a C++20 g++ toolchain can build it — x86_64 and ARM hardware, Raspberry Pi, containers, WSL, and even Android through Termux.

One command to build

The pitch for systems developers is compile-time simplicity. A basic server is produced by a single g++ invocation — g++ -std=c++20 server.cpp -o exe -lvermell — with no extra flags or link-order gymnastics. Larger projects can use CMake, and the project also distributes an npx scaffold, a Docker image, and signed APT repositories for Debian and Ubuntu covering amd64, arm64 and armhf.

A minimal program constructs a Router, registers a handler with router.get(), and calls listen(), which blocks and serves forever; a listenOne() variant handles a single request and returns, which the README suggests for tests and one-shot servers. Handlers are plain C++ lambdas taking a Query reference and returning void, so shared state follows normal capture semantics. The README spends notable space on this: by-copy captures produce a private snapshot at registration time, by-reference captures give a live view, and reference-capturing stack locals that die before the server stops creates a dangling reference. Because handlers run concurrently on worker threads, shared mutable state requires a mutex.

Routing, JSON and configuration

The router exposes one registration method per HTTP verb, including the rarely seen LINK, UNLINK and PURGE, and static routes dispatch in O(1) through a hash map. Path parameters such as /users/:id are supported, and route groups can be declared separately and mounted with router.use(). The naming has one C++ quirk: the delete verb is registered as deleteX() because delete is a reserved keyword.

JSON is handled in-tree with a strict RFC 8259 parser and serializer, alongside typed parameters, raw bodies and multipart uploads. A small templating layer built on compose() and render() rounds out the feature set. All knobs live in a single Config struct passed through one configure() call using designated initializers: network options such as the listen backlog, and request-pipeline options such as a 30-second inactivity timeout between chunks and a 60-second total deadline that guards against slowloris-style attacks. SO_REUSEPORT ships disabled by default, with the README noting that a same-UID process could otherwise bind the port and intercept a share of the traffic.

Hardened by default

According to the README, security measures are enabled out of the box rather than opt-in: timeouts, request caps, connection limits and a sandboxed rendering environment are all active from the first run. For a young framework aimed at people writing bare-metal services, those defaults arguably matter more than feature breadth.

Why it matters

Most C++ web development today routes through heavyweight stacks — frameworks layered on Boost.Asio, or event libraries pulled in through package managers. Vermell's bet is that zero external dependencies, one header and one static library meaningfully lower the barrier: no vcpkg or Conan setup, no dependency resolution, no ABI headaches, just g++ on Linux. Its epoll loop plus worker pool mirrors the architecture used by high-performance production servers, applied at framework scale, which makes it a natural fit for embedded targets like Raspberry Pi, Termux and minimal containers.

The trade-offs are real: it will never run on macOS or Windows, and a project this new carries the usual maturity risk. But the Hacker News attention suggests a genuine audience of systems developers who want a tiny, hardened, dependency-free C++ HTTP stack — and until now have mostly had to build one themselves.