platform

BareProxy Is an Operating System for Web Traffic: A Small Core and a Long Stream of Plugins

BareProxy started as a question: how little machinery does it take to do the part of nginx most sites use? The answer turned out to be a small core. With plugins in place since 0.2.0, it has become something more useful to describe as an operating system for web traffic.

The comparison is meant as a way to see how the parts fit. BareProxy doesn’t run hardware. But it has the same shape as a good operating system, and the shape explains the design.

The Parts, the OS Way

  • The kernel is the core. TLS, routing, static files, backend health, and the machinery for changing a running config safely: plan, apply, rollback. Like a kernel, it is small, it changes slowly, and everything else depends on it being right. It is about 5,000 lines of Go, and it’s meant to stay that size.
  • Plugins are the apps. Crawler control, caching, logins, analytics: each is a WebAssembly module, installed by one line in the config and removed by deleting the line. The core doesn’t grow when a plugin is added. A site runs the plugins it needs and none of the others.
  • Proxy-Wasm is the system-call interface. A plugin can’t touch the server directly. It asks through a fixed set of calls (read this header, answer this request, call this address, keep this value) and the core decides. The same interface runs plugins in Envoy and Istio, so plugin authors work with tools they already know.
  • The sandbox is process isolation. Each plugin runs in its own sandbox, with a memory cap and a time limit on every call. A plugin that crashes or loops loses its own instance; the server and the other plugins keep going. Files, network and storage exist for a plugin only when its config line grants them.
  • why, explain and status are the task manager. For any request, why says which plugins ran, what each one did and how long it took. status shows every plugin’s instances and counters. On most servers, extensions are where visibility ends. Here they report in.
  • Plan, apply and rollback are the package manager. Adding, upgrading or removing a plugin is a config change. plan shows it before it goes live, and rollback brings back the exact plugin file that ran before, from the history, whatever is on disk now.

Why This Shape

Proxies usually grow by adding features to the core. Every feature makes the core bigger, every site carries every feature, and an old feature nobody uses can still hold a bug. nginx’s rewrite module carried one for eighteen years.

The other shape is to keep the core small and move everything else outside it, behind a narrow interface and a sandbox. That’s the bet BareProxy is making. The core stays small enough to read. The plugins can come in any number, from anyone, in any language that compiles to WebAssembly, and BareProxy’s own are written in Rust.

The Stream of Plugins

Twenty-one plugins are on the list now. Each has its own page on this site, which will be updated as it is built:

Two things that might look like plugins are part of the kernel instead: automatic certificates from Let’s Encrypt, and plan and explain. Every site needs the first, and the second is what makes everything else visible, plugins included.

They are built easiest first, so the stream starts moving quickly. The first three are out: maintenance and failover pages and CORS in 0.4.0, header and rewrite rules in 0.5.0. Redirects from a file come next, and RenderCache, which needs a headless browser beside BareProxy, comes last. The full order is on the roadmap, and the catalog is on the plugins page.