birdy: a Web UI for BIRD 2.x That Runs on Your Router

We've open-sourced birdy, a web UI for BIRD 2.x that runs on the router. It models eBGP/iBGP sessions, import/export policy, RPKI, RTBH, and BFD in a database, renders the whole bird.conf from that model, and applies it with a syntax check, a reviewable diff, and an armed auto-revert. It also gives you something BIRD itself never has: a live dashboard of what every session is actually doing.

It's 0BSD licensed — no strings, not even attribution. Here's what it is, why we built it, and — just as important — what it deliberately is not.

The Problem: bird.conf Over SSH at 2 AM

BIRD is excellent software with a config format that rewards expertise and punishes everything else. Running AS210622 means our BGP config is the network: a typo in a filter doesn't 500 a webpage, it withdraws prefixes or leaks routes. And the standard workflow — SSH in, edit bird.conf, birdc configure, hope — has a failure mode where the mistake that takes you offline is the same one that severs the connection you'd fix it through.

The pieces of a safer workflow all exist: birdc configure check for syntax, configure undo for rollback, bgpq4 for prefix filters, looking glasses for verification. birdy's job is to assemble them into one deliberate loop: model → render → check → diff → apply → auto-revert if you don't confirm.

What It Does

birdy is a single Go binary backed by SQLite, running on the router itself under systemd or in a container. No agent, no controller, no cloud, no fleet.

Model. Peers carry roles — upstream, IX, customer, iBGP — and the role drives policy: origin tagging with large communities happens automatically, the way we described in our traffic engineering post. Composable import/export policy chains, prefix sets and AS sets (expandable from IRR via bgpq4, with auto-refresh), static routes, RPKI ROV, RTBH, BFD.

Render and apply. birdy renders the entire bird.conf from its database. Applying is a deliberate act in the UI: syntax-check, lint, review the diff, then apply with an armed auto-revert — if you don't confirm within the window (say, because the change cut off your own access), the previous config comes back on its own. The same idea that makes remote firewall edits survivable, applied to routing.

Observe. A live dashboard of every session read straight from BIRD's control socket, per-peer detail, an on-demand looking glass, a timeline of flaps and prefix-limit hits, and alerts to Slack, Discord, email, or a webhook. One router is managed locally; multiple birdy routers can be observed side by side, read-only, safely.

Zero configuration to start. It detects what the router can do — bgpq4, ping, traceroute — and enables what it finds. Installing it changes nothing; writing bird.conf only ever happens when you ask it to.

It Is Opinionated, On Purpose

birdy does not expose every knob BIRD has. It renders what we believe is current good practice, unconditionally:

• RFC 8212 default-deny on export — nothing is announced that policy doesn't explicitly allow
• Bogon prefix and bogon ASN filtering on ingress
• enforce-first-AS on eBGP, next-hop-self on iBGP
• RPKI-invalid drop when a validator is configured
• Large communities tagging every route's origin

And it will flat-out refuse to render a config it recognises as a route leak — transit routes exported to transit is not a warning, it's a refusal. For the constructs it doesn't model, a raw-config escape hatch exists, but the guardrails are the product.

Read This Before You Point It at Anything

Honesty section, because routing software deserves one:

• birdy is beta software. Expect bugs. It's a personal project released in the hope it's useful, and it has not yet had the years of hardening a piece of routing infrastructure deserves.
• It does not import your existing bird.conf. It renders the entire file from its own database — anything it doesn't know about (a protocol, a filter, a hand-tuned option) would be gone from the first config it writes. Use it on a new router, or on one whose config you're content to recreate inside birdy from scratch.
• One router, managed locally. There's no fleet orchestration and no plan for any. Multiple routers can be observed from one place; each is managed on its own box.

If those constraints fit your situation — a new edge router, a lab, a first ASN — it works the moment you install it.

How It Was Built

birdy was built with AI coding agents doing most of the actual typing, under human design, direction, and review — the same agentic development workflow we've written about. The opinions in the rendered config — the RFC 8212 stance, the leak refusal, what a "peer role" means — are human decisions from operating a real network; the agents turned them into working Go considerably faster than we would have alone. It's been a useful proof point that this workflow can produce real, shippable infrastructure tooling, not just demos.

Try It

Grab it from github.com/floreabogdan/birdy — packages, a Docker image, and a plain binary are on the releases page, and birdy init gets you to a login screen in about a minute. Issues and PRs welcome; the 0BSD license means you can do literally anything with it.

Lessons

1. The safe BGP workflow is an assembly problem — check, diff, apply, auto-revert all existed; they just weren't one loop.
2. Opinionated beats configurable for routing policy — a tool that refuses to render a route leak is worth ten that warn about one.
3. Roles beat raw config — "this peer is an upstream" generates more correct policy than any amount of copy-pasted filter code.
4. Say what your software won't do — no config import and no fleet management are one-line disclosures that save users a bad week.

If you'd rather have someone stand up your BGP edge with you — or you want to peer with AS210622 — reach us at peering@kicked.ro or through our network engineering services.