Reference stays attached to code
Generated references stay tied to code, registries and RFC evidence.
Generated references stay tied to code, registries and RFC evidence.
Standards closure was the plan for the week. The build and test tooling took it instead: the Makefile and…
Every gated MUST-level requirement links to source text, status, and test evidence.
Every homepage number links to the page where you can inspect the test layer, transcript, peer list, RFC gate, or generated source evidence behind it.
Ze is a network operating system, and more: a routing daemon, appliance runtime, lab router, and protocol engine that brings policy data, generated references, APIs, MCP tools, and product evidence into one operator workflow.
Start here for the selling points: powerful CLI, operator protocols, in-engine IRR filtering, PeeringDB data, looking glass APIs, one YANG model, and when to choose another NOS instead.
The core holds the supervisor, message bus, config provider, and plugin manager. BGP and interface management register into it.
The shipped daemon speaks BGP, manages Linux interfaces, programs the FIB, and serves its configuration through SSH and the web UI.
Plugins can be compiled Go modules or external
processes. Compiled modules load their YANG into the
daemon validator; external plugins can expose their
model through ze schema.
The same binary and configuration support each path, from a netlab topology or BGP interop lab to spare hardware.
The netlab integration brings up a three-node Ze topology under containerlab. The BGP interop lab also runs Ze beside FRR, BIRD, and GoBGP and checks routes through each peer's own CLI.
Ze runs on any existing Linux distro, managed by systemd or your chosen process manager. This is the easiest route when Ze has to fit into infrastructure you already run.
A bootable gokrazy image for appliance hardware: read-only root filesystem, no shell, no package manager, and automatic process supervision.
Read the generated references before you run Ze.
Ze is an open-source configuration and protocol engine. The network operating system built on it speaks BGP, manages Linux interfaces, programs the FIB, and serves the same YANG-modeled configuration through SSH, web, API, and MCP.
The BGP lab, ExaBGP migration, and appliance install are good starting points.
# build from source $ git clone https://github.com/ze-software/ze.git $ cd ze && make build # set up credentials and configure $ bin/ze init $ bin/ze config import router.conf # start $ bin/ze start # from another terminal $ bin/ze cli -c "show bgp peer list" $ bin/ze cli -c "monitor event"
A lab peer, a migrated ExaBGP config, or a looking-glass instance can produce useful reports from people who know routing operations.
Ze is early enough that routing feedback can still change the system. These cards give each reader a low-risk starting point.
IXP operators can run the route-server lab first and compare policy behaviour before touching members.
Network builders can bring up two BGP peers, inspect routes, and check whether Ze's operator tools fit their workflow.
ExaBGP users can try the migrator against an existing config and see which process scripts still translate cleanly.
People with spare x86 hardware can boot the appliance image and test the same configuration model without a general-purpose shell.
Operators who need read-only BGP visibility can publish a looking glass and inspect routes without giving shell access.
Protocol implementers can run Docker interop scenarios against FRR, BIRD, and GoBGP, then turn a failure into a test case.
MCP exposes Ze commands and structured output to AI tools without a separate command set.
Weekly updates come from git history and Discord's
ze-news. They stay specific and technical.
Week of 2026-08-24
Week of 2026-08-17
Week of 2026-08-10
Start where a mistake cannot affect a live network.