Tools That Run on the Router: Why We Build Single-Binary, Local-First Infrastructure Software

This year we released three open-source tools: nftably for managing nftables, birdy for managing BIRD, and meerkat for making sense of Suricata. They do different jobs, but anyone who looks at all three will notice they are the same shape: a single Go binary, backed by SQLite, running on the router itself, serving a web UI out of the binary, applying changes with an armed auto-revert.

That shape is not an accident. This post is the reasoning behind it — the values, and the tradeoffs we accepted to hold them.

The control plane belongs where the consequences are

The prevailing model for infrastructure tooling is a control plane somewhere else: a SaaS dashboard, a fleet controller, an agent that phones home. It has real advantages at scale. It also means that the thing configuring your firewall, your BGP sessions, or your IDS depends on a vendor's uptime, a subscription's continued existence, and a network path that may be exactly what just broke.

We build the other way around. The tool runs on the box whose behaviour it changes. If the box is up, its control plane is up. If the internet is down, you can still SSH-tunnel in and fix the firewall — with the same tool, seeing the same state. Nothing leaves the machine: no telemetry, no alert data shipped to someone else's backend before you can read it, which also happens to be the right behaviour on the metered uplinks where edge routers actually live.

A router should outlive every vendor relationship its owner has. Software that manages it should be built accordingly.

One binary, one file of state

Each tool is one static Go binary. The web UI is embedded with go:embed, so there is no node build step and no assets directory to keep in sync. State is one SQLite file. There is no agent, no message bus, no controller to stand up first.

The operational consequences are the point:

• Install is: put the binary on the box, run init, start the service.
• Upgrade is: replace the binary, restart. Seconds of downtime for a management UI, none for the data plane it manages.
• Backup is: copy one file.
• Debugging is: one process, one log, on the box you were already looking at.

Every dependency a tool drags in is a promise someone has to keep for years. We would rather promise less and keep it.

Safety is a feature, not a disclaimer

Software that runs with root on routing and firewall infrastructure has to treat "what if this change is wrong?" as a first-class design problem, because the person applying the change is usually reaching the box through the thing they are changing.

So all three tools share the same discipline:

1. Dry-run first — candidate configs are syntax-checked (nft --check, BIRD's own parser) before anything is applied.
2. Show the diff — you review exactly what will change, and applying it is a deliberate act in the UI, never a side effect.
3. Apply atomically — the change lands as one transaction, not a sequence of half-states.
4. Arm the revert — after the apply, a rollback is armed. If the change cut you off, the previous config comes back on its own; if you can still reach the UI, you confirm and it stays.

Just as important is explicit ownership. nftably renders the entire contents of every table it manages and never touches one it doesn't. birdy renders the whole bird.conf from its database. That is a sharp rule, and both READMEs say so in a caution box you cannot miss: hand-written rules in managed territory will be gone after the next apply; do not point the tool at a config you care about without importing it first. We think an honest destruction warning is worth more than a merge feature that silently half-works. You can reason about "the tool owns this file"; you cannot reason about "the tool usually preserves most things."

Opinionated defaults beat infinite knobs

birdy will render RFC 8212 default-deny on export, bogon prefix and ASN filtering, RPKI invalid drop, and enforce-first-AS on eBGP — and it will refuse outright to render a config it believes is a route leak. nftably ships best-practice presets and validates that a raw rule cannot break out of its chain.

Exposing every knob and letting the operator hang themselves is easier to build and easier to defend — "the tool did what you asked." But most single-router operators do not need every knob; they need the config a careful engineer would have written. Encoding good practice as the default means the lazy path and the correct path are the same path. The escape hatch (raw rules, raw config blocks) exists, guarded, for the genuinely unusual case — the defaults are not a cage, they are a floor.

Why 0BSD

All three tools are licensed 0BSD — functionally public domain. No attribution requirement, no license text to ship, no legal review needed to vendor a file into your own tree. These are tools for operators; the license should never be the reason one sits unused. If a company builds something on top of them, that is the license working, not failing.

The tradeoff, stated plainly

This philosophy has a boundary, and it is worth naming: these are tools for one box done well, not for fleets. One router is managed locally; multiple birdy routers can be observed side by side, but management stays local to each box, deliberately. When you are running fifty routers, you want your source of truth in an IPAM/automation pipeline and your configs generated centrally — and at that scale, the SaaS and controller models we argued against above start earning their complexity.

Most networks are not fifty routers. They are one or two — the small AS, the colo edge, the lab that quietly became production. That long tail is badly served by tooling built for fleets, and it is who we build for.

Takeaways

1. Local-first is a reliability position, not nostalgia: the control plane shares fate with the box, not with a vendor.
2. Boring distribution is a feature — one binary, one SQLite file, upgrades by replacement.
3. Safety mechanisms and honest ownership rules matter more in this niche than feature count.
4. Know the boundary — one box done well, and no pretense of being a fleet manager.

If your edge is one or two important boxes and you want them run with this kind of care — routing, firewalling, monitoring, hosting — that is exactly what we do.