The Platform

BareProxy is an operating system for web traffic. It has a kernel, the core, which is a complete web server and reverse proxy for the part of the job most sites need, and stops there. Everything else runs on top of it as plugins, the way apps run on an operating system: installed and removed one at a time, each in its own sandbox, each asking the kernel for what it needs through one fixed interface. The core needs none of them.

In an operating system In BareProxy
Kernel The core: TLS, routing, static files, backend health, safe config changes, request tracing
Apps Plugins: WebAssembly modules, one config line each
System calls Proxy-Wasm, the plugin interface of Envoy and Istio
Process isolation A sandbox per plugin, with a memory cap and a time limit on every call
Package manager plan, apply and rollback, for plugins as for everything else
Task manager why, explain and status, which show what each plugin did

The Kernel: BareProxy Core

What it does How
Static files A folder served as a site: index.html for folders, precompressed copies, ETags, ranges and a 404 page. Nothing outside the folder is ever reached.
Reverse proxy HTTP/1.1 and HTTP/2 from clients, HTTP/1.1 to backends. WebSocket and streamed responses pass straight through.
TLS Certificates from Let’s Encrypt or any ACME CA, which BareProxy gets on first use and renews 30 days before they expire, or a certificate file and a key file for each HTTPS site. TLS 1.2 is the minimum. Wildcard and catch-all sites need certificate files.
Routing By host name, exact path or path prefix, method and header. The first matching rule wins.
Backend health Active checks plus failure counting on live traffic. Requests go to the healthy backend with the fewest requests in flight.
Config changes A new config is checked in full, then swapped in at once. plan says first which requests change hands, and a plan ID makes apply refuse if anything changed since. Requests in flight finish on the old config, removed backends drain, and one command rolls back. The last 100 versions are kept.
Request tracing Every request gets an ID and leaves one record, kept in memory and in a trace log that rotates. why and tail read the records, and a W3C traceparent header joins the application’s own traces.

Apps: Plugins

A plugin is a WebAssembly module named in the config. A site runs the plugins its use lines name, in that order, and nothing else. Plugins can be written in any language that compiles to WebAssembly; BareProxy’s own are written in Rust. The plugin catalog lists the twenty-one on the way, each with its own page.

System Calls and the Sandbox

A plugin can’t touch the server, the disk or the network on its own. It asks the core through Proxy-Wasm calls: read or change a header, answer a request, call an address, keep a value. The core grants only what the plugin’s config line allows. Each plugin has a memory cap and a time limit on every call. A plugin that crashes or loops loses its own instance, the request follows the plugin’s on-error setting, and a fresh instance starts in the background. The server and the other plugins keep going.

The Task Manager

Every request leaves one record, and the record says which plugins ran, what each did and how long it took. why turns a record into a story, explain says how a request would be handled, and status shows every plugin’s working instances and counters. Extensions are usually where a server’s visibility ends. In BareProxy they report in.

Design Rules

  • Match on what you forward. The path is normalized once, routed on, sent to the backend in that same form, and looked up in the folder in that same form.
  • First match wins. Rules are read from the top. There is no precedence order to learn.
  • Matchers are exact values, prefixes or sets. No regular expressions, no variables, no scripting. That is what lets plan say exactly which requests a change affects.
  • A bad config never replaces a good one. Every config is checked in full on apply, on reload and at startup. If the file is broken at startup, BareProxy runs the last good version and says so.
  • One record per request, and any record can be explained, plugins included.
  • A small kernel. A feature every site needs goes in the core; anything else becomes a plugin, or waits.
  • Two outside modules. Go’s standard library, the Go team’s own x/crypto for certificates, and wazero, the pure-Go WebAssembly runtime that runs plugins. Nothing else.

How a Request Is Handled

  1. The connection arrives, and the TLS handshake picks the certificate and HTTP/1.1 or HTTP/2.
  2. BareProxy gives the request an ID and checks it, and the host picks the site.
  3. The site’s plugins run, in order. Any of them can change the request or answer it.
  4. The path is normalized, and the site’s rules are tried from the top.
  5. The rule serves a file from a folder, names a pool, redirects, or answers directly.
  6. A file is looked up inside its folder and sent, plain or precompressed. A pool picks the backend with the fewest requests in flight, and BareProxy forwards a fresh request to it, with one retry if the connection can’t be opened.
  7. The response goes back through the plugins, last one first, and the request’s record is written.

The config behind all this fits on one page. The config reference has a complete example, and the plugin catalog shows what each plugin will add.

License

The entire project, the core and everything built around it, is open source under the Apache License 2.0 for now. Copyright 2026 BareProxy.com. Later, premium add-ons may be offered under different licenses. The code repository on GitHub has the code, and its releases page has the binaries for Linux, macOS and Windows.