1 compiled binary, on your own network
The gateway is a single Go executable. There is no interpreter to install, no virtualenv to resolve, and no runtime to patch separately from the application. You copy 1 file and run it.
What that costs you to run
Figures from the v2026.8.1 binary on an Apple silicon laptop, running the control plane with its managed proxies idle.
Chosen for the shape of the workload
A gateway sits in the request path. It has to inspect every byte, fan out to several checks at once, and never become the reason a request is slow. That favours a compiled runtime with cheap concurrency. It is a real trade, though, so the honest version of both sides is below.
What the compiled binary buys
- One artifact to ship and verify No interpreter, no virtualenv, no dependency resolution on the target host. The thing you tested is byte-for-byte the thing that runs.
- Starts in milliseconds There is no import graph to walk at boot, so restarts, crash recovery, and autoscaling are close to instant rather than close to a second.
- Real parallelism in 1 process Every request fans out to the policy engine, guardrail providers, identity verification, and redaction at the same time across all cores. There is no global interpreter lock forcing you into multiple worker processes to use the machine.
- Predictable memory 37MB resident covers the entire control plane. A multi-worker interpreted service typically multiplies its baseline by the worker count just to reach the same core utilisation.
- Cheap concurrency per connection Goroutines start at a few kilobytes, so thousands of simultaneous SSE and WebSocket streams stay affordable instead of becoming the scaling limit.
- Steady latency on the hot path Policy matching runs compiled regex over every request body with no interpreter overhead, and the garbage collector is tuned for short pauses rather than throughput.
- Smaller runtime attack surface There is no system interpreter and no package installation at deploy time, so there is no second CVE stream to track alongside the application itself.
Where an interpreted runtime would win
- Editing in place With Python you can patch a file on a running host and restart in a second. Go needs a recompile and redistribute cycle, so an urgent code change takes longer to reach production. Detection rules are the common case here, and those are JSON that loads without a rebuild, but anything outside the policy files does need a new binary.
- Richer regular expressions Go's standard library uses RE2, which guarantees linear-time matching and cannot suffer catastrophic backtracking. That is a real security property when you run untrusted input through patterns all day. The cost is that RE2 has no lookahead, lookbehind, or backreferences, so some detections need more rules to express than the equivalent Python pattern would.
- Model inference inside the request path Running a local classifier in-process is more natural on an interpreted stack. The gateway calls out to guardrail providers over the network instead, which adds a hop that an in-process model would not have.
- Live introspection Attaching a REPL or a debugger to a running production process is easier in Python. Go leans on pprof, structured logs, and metrics, which is a different workflow rather than a strictly better one.
What it means for operating it
| Operation | This gateway | A typical interpreted service |
|---|---|---|
| Install | Extract and run | Runtime, virtualenv, then resolve and build dependencies |
| Deploy artifact | One executable | Source tree plus a lock file plus a resolved environment |
| Cold start | Milliseconds | Interpreter start plus import graph |
| Using all cores | One process | Multiple worker processes, each with its own memory |
| Rollback | Swap the file back | Rebuild the environment at the previous versions |
| Patching the runtime | Not applicable | Track interpreter and package CVEs separately |
| Urgent code change | Recompile and redistribute | Edit and restart |
| Urgent detection change | Edit JSON, no rebuild | Edit and restart |
A clean, multi-layered design
A Vue front end talks to a single Go control plane over REST and WebSocket. That control plane manages unlimited proxy instances and persists everything to SQLite, with optional replication to an external database for long-term retention.
Real-time dashboard · proxy management · alerts · policy editor
Proxies · alerts · logs · users · tokens · tools · audit
Deploying it and driving it
The binary is 1 way to run it. There are container and web-server paths too, and every capability in the dashboard is reachable over the API.
Deployment
Operating it
Try it on your own hardware
Extract the archive, run the installer, and the dashboard is up on localhost:8080.