BareProxy: An Agile Reverse Proxy That Explains Every Routing Decision
Teams shipping features fast need infrastructure that gets out of the way. The reverse proxy is supposed to be boring: TLS termination, serve static files, route traffic to the app, maybe some health checks. In practice, the config grows one regex at a time, until routing decisions become cargo cult superstition. Someone changed a block six months ago and nobody knows what would break if you moved it.
BareProxy is built on the insight that you can reason about routing only if you remove the things that are hard to reason about. No regular expressions. No scripting. Every matcher is an exact value, a prefix, or a set. With those constraints, the requests your site can get fall into a finite number of classes, and the server can enumerate them all.
That foundation pays off for teams in three commands. bareproxy explain takes a URL and shows which rule matched it, which file or backend would serve it, and which rules above it didn’t match. You’re adding a new microservice endpoint, or someone’s reporting a 404 on a path that should work, and you ask the proxy to account for what it just did. The answer is plain English, not a trace you have to read backwards.
bareproxy why tells the story of a request that already happened, starting from the ID in a response header. You pull that header from your browser’s network tab, pass it to the tool, and the proxy walks back through exactly which rules matched, which decisions were made, in order. For sprint debugging, this is a lifesaver: you know what the proxy saw and why it made the choice it did. Hours of log digging becomes a direct answer.
The third command, bareproxy plan, is the agile win. Before a config goes live, it compares your new file with the running one and lists which existing requests would change hands. If you wrote a rule that can never match because an earlier rule takes all its traffic, you get a warning. If a change would silently flip traffic between two backends, you see it before anyone runs into it in production. This is what code review looks like for infrastructure: you see the delta, you understand the consequences, you approve or iterate.
For teams running their own static sites or microservices, BareProxy serves them directly with TLS from Let’s Encrypt. You add caching headers, rate limits, request inspection, or custom responses as modules that compile in only when you need them. You start with 5,000 lines of Go and no external dependencies, and you add what your sprint requires.
BareProxy is at version 0.1. The numbers on the site are design budgets: under 5,000 lines in the core, no dependencies from outside the Go project, with memory and speed measured against nginx coming next. The demo page shows each command’s output on a sample config you can read and modify, so you can see how the tool would read your own rules.
The appeal to teams is confidence in deployment. Your sprint lead can change a routing rule, ask the proxy to explain it, see the impact before it runs, and know the change is safe. The appeal to infrastructure engineers is simplicity: no regex to debug, no scripting to maintain, just rules that do what they say. For teams shipping multiple services from one host, or teams that deploy frequently, a proxy you can reason about is the difference between easy deploys and anxious ones.