Everything on this page is not built. Each row says what the product does today in its
place. There are no dates. What is finished is on What is finished, and what is
not, and what changed in each release is on Release history.
An nftables ruleset inspector — the real ruleset chain by chain, mapped back to the configuration objects that generated each rule
Firewall hit counters joined from firewall statistics, per rule. There is no per-object nftables view
Per-host traffic history, an embedded time-series database, long-term graphs
Live counters, a server-sampled throughput series, and conntrack top-talkers. Flow export exists so an external collector can keep the history
v6 in the v4 pages (Diagnostics, Interfaces) and the uplink model
The IPv6 page edits addressing, router advertisements and prefix delegation and shows addresses, neighbours, routes and ip6 counters, and Static routes shows both families; the neighbour tables and the uplink model are still v4-only
A tc and qdisc tree visualiser
The QoS page gives each interface, a VLAN included, an upload and a download rate: CAKE for upload, and CAKE or policing for download — a limiter on qos interface <if> ingress, or CAKE through an IFB — with bandwidth, flow isolation, RTT, ack-filter, flow-isolation-nat and no-split-gso for CAKE, and says whether the kernel is running what the configuration asks for. The agent reads tc qdisc show; it never programs tc. DOCSIS and ATM overhead compensation have no configuration node on this platform
Network namespace panels
Not built at all. A VRF page is built: VRFs are created, edited and deleted with their interfaces and static routes
Ring and queue statistics on the interface detail
The detail panel edits MTU, admin state, addresses and the nine offload flags, and shows the kernel's own offload state beside them. Ring sizes, queue counts, link speed and duplex are not surfaced
The pinned base has neither, so the agent answers UPnP and NAT-PMP itself and writes each mapping as a port forward and a firewall rule, from UPnP / NAT-PMP in the catalogue and the UPnP page. IPv6 pinholes are refused
A companion daemon for PXE architecture matching
The dnsmasq app. One boot file per scope is a platform gap in the base — Built on VyOS. Wildcard DNS records and a reservation's own DNS servers and router are on the DNS and DHCP pages
~~A site-to-site OpenVPN instance from the UI~~
Add instance builds a server, a client or one end of a site-to-site tunnel, certificates and all, from the router's own pki tree — or, for a site-to-site end, either a 2048-bit shared secret minted by the agent and returned in the plan or certificates with the tls role the router needs — and, when asked, the input firewall rule for the port the tunnel listens on. It configures one router, so the far end is a second visit. On the lab router a server, a client and a site-to-site end each committed and were edited, and a client connected to the server with the file the page made
~~A 1:1 NAT editor the Commit Bar commits~~
Since 0.9.1 a 1:1 mapping is a destination and source NAT rule pair, planned by the agent ahead of the rules that would take its traffic, and applied by the Commit Bar like any other change. The nat static node itself is still refused at every staging and configure route, because committing it through this base's HTTP API has been seen to stop the API process — Built on VyOS
Every entry carries a sequence number and the hash of the one before it, and a configured collector holds a copy as each entry is written. Nothing signs either, so a chain proves a break rather than preventing one — Reporting a vulnerability
A catalogue signing key
The agent already fetches a signed catalogue index, verifies a detached ed25519 signature against a key compiled into it, and refuses anything that does not verify. No signing key exists, so every agent still serves the catalogue compiled into it and a corrected entry still needs an agent release
The image installs to a disk and reboots into it on one physical machine, and in VMs. That is one board, not a compatibility list — What is finished, and what is not
A hardware compatibility list
None. The image's driver packages can be listed; that is not a compatibility claim
A VM image — qcow2 or OVA
None. Install from the ISO into a VM
An arm64 image
None. The arm64 .deb exists for running the agent off-router against an arm64 router
~~A factory reset~~
Built.System → Overview → Factory reset, or wheelhouse-rescue factory-reset at the console, deletes the accounts, tokens, second factors, audit log and histories, keeps the licence key, and can restore the image's default configuration too — Factory reset
Signed releases
The pipeline signs SHA256SUMS whenever a release key is configured, and publishes unsigned checksums with a warning when it is not. No key exists yet, so nothing published so far is signed
UI tests in a browser
CI runs the agent's test suite with the race detector, and the web UI's page tests beside its type check and build. Those render nearly every page in jsdom, which has no layout, focus order or live socket, so nothing automated opens a browser; the configuration tree, Reconcile, Support, About and Licence have no test at all
A licence agreement, terms of service, a support address, published beta terms
A router that installs its own updates. It reads the release channel and says a
newer version exists; installing one is add system image, typed to confirm and started
by a person. A box that upgrades itself reboots into a new kernel at a time nobody chose
— Upgrade the image.
Calling an app's own API on its behalf. An app's health probe is TCP plus an optional
HTTP path, never an app-specific API, and Wheelhouse holds no app's credentials. The one
thing that did move: a catalogue entry may declare a stats URL and a path to a single
number in the JSON it answers with, and the app's card shows that number with its age.
Container start and stop out of band. The platform offers no operational verb for
either, so both stay configuration: stopping an app stages disable and starting it
deletes that. An app is configuration, and configuration is what rolls back. Restarting
is the exception the platform does offer, and it is built — one restart container
command, audited, writing no revision.