Pages on BareProxy.com

About

Mon, 01 Jan 0001 00:00:00 +0000

BareProxy is a project at an early stage. It asks how little machinery it takes to provide the part of nginx that most applications use, and answers with a bare core and a set of add-on modules around it. Version 0.1 is an Alpha. This site shows where the project stands.

Why the Project Exists

Most applications use a small part of nginx. They need TLS, routing by host name and path, requests spread over backends that are actually up, config changes that don’t drop traffic, and a way to find out what happened to a request when something breaks. The proxies that do this well carry decades of features most sites never touch. Each of those features is code that runs at the edge, in front of everything else.

Contact

Mon, 01 Jan 0001 00:00:00 +0000

The project would like to hear from:

Teams running nginx who would like to try a smaller proxy on their own traffic.
Engineers with a config, a traffic pattern or a failure the project should test against.
Anyone with a question about the core, the modules or the figures on this site.

Write to info@bareproxy.com.

If you are writing about your own setup, it helps to mention what you run today, roughly how many sites and backends sit behind it, and which nginx features you actually use.

The Platform

Mon, 01 Jan 0001 00:00:00 +0000

BareProxy is a bare core with add-on modules around it. The core does six things and stops there. Modules add the rest, one at a time, and the core needs none of them.

BareProxy Core

What it does	How
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, obtained and renewed on their own, or loaded from files. TLS 1.2 minimum.
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. Requests in flight finish on the old one, removed backends drain, and one command rolls back.
Request tracing	Every request gets an ID and leaves one record. `why`, `tail`, `explain` and `plan` read them.

Design Rules

Match on what you forward. The path is normalized once, routed on, and sent to the backend 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.
One record per request, and any record can be explained.
Nothing from outside the Go project. Go’s standard library and the Go team’s own packages, and nothing else.

How a Request Is Handled

The connection arrives, and the TLS handshake picks the certificate and HTTP/1.1 or HTTP/2.
BareProxy gives the request an ID, checks it and normalizes its path.
The host picks the site, and the site’s rules are tried from the top.
The rule answers directly, redirects, or names a pool.
The 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.
The response streams back, 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 modules page shows where each add-on plugs in.