Wheelhouse docs

What is finished, and what is not#

Wheelhouse is a working router platform with real gaps, and this page is the list of both. It exists because the alternative — finding out after you have moved a network onto it — is worse for you and worse for us. Everything below is either a claim with the file that proves it, or a gap with the file that admits it. It is kept in step with the repository's own status section in README.md and with the status page on the product site; when one changes, the others change with it.

Built, and exercised#

What that means concretely
The agentA Go binary fronting the VyOS API: staging, native commit-confirm, revision rollback, an attributed audit log, parsed operational state (counters, conntrack, routes, leases, certificates, logs) and a live telemetry WebSocket. Accounts with Argon2id and TOTP, sessions with CSRF, three roles, scoped API tokens, OIDC as a relying party, Prometheus metrics, TLS, and the UI embedded in it
The web UIA React single-page application: a page per left-nav entry across eight groups, every editor rendering the set and delete lines it will run, one Commit Bar, live state beside configured intent with drift flagged, a command palette over pages and configuration objects, dark and light
The app store38 catalogue entries: 36 containers declared in the router's configuration tree, plus two built-in feature modules. An install is a reviewable diff and a rollback target
Migration and unattended installAn OPNsense config.xml becomes VyOS commands plus a report of what could not come across; --check-against compares a running router with the configuration it should have. The installer finds a seed and installs with nobody at the keyboard
Multi-WANUplinks through every VyOS mechanism, health-checked failover, load balancing, policy routing and per-uplink NAT — proven on a dual-WAN VM built from the ISO
Inline IPSSuricata in the packet path through NFQUEUE, entirely in the configuration tree, so it diffs, commits and rolls back. Fail-open twice over
The image pipelineEvery tag builds the .deb and the ISO, inspects the image before publishing it, and publishes both with one checksum file, a corresponding-source record and an update channel index

Two of those numbers can be re-derived rather than believed:

bash
grep -h '^func Test' agent/*_test.go | wc -l    # over 200 Go test functions
cd agent && go test -race ./...                 # they run race-clean in CI
ls ui/src/pages/*.tsx | wc -l                   # a page per nav entry

What has actually been run#

The verification inventory, from the repository's own history — docs/hardware.md.

Status
Booting the live image in a VMYes, repeatedly
Installing to a disk in a VM and rebooting into itYes. Verified for 0.4.5 by keyboard, and again for 0.5.0 unattended from a seed carrying a real router's 214-command configuration — it came back up with the LAN address, 20 DHCP reservations, the port forwards, Kea, CAKE and the agent running
Refusing to reinstall over itself with the seed medium still plugged inYes, on the same VM
Booting the live image on physical hardwareYes. It is where three installer bugs were found and fixed between 0.4.1 and 0.4.5
A complete install to disk on physical hardware, then a reboot into itNot recorded. Every end-to-end verification in the repository names a VM
An add system image upgrade of a Wheelhouse boxNot recorded, on hardware or in a VM
Any measurement of CPU, memory or throughputNone. The performance budget in the systemd unit is a target, not a measurement

If you are evaluating this, install it in a VM first. That is the path with the most evidence behind it, and it exercises the same installer, the same units and the same first-boot sequence as the metal.

Not finished, and worth knowing before you buy#

  • No bare-metal install has been done, as above. There is also no VM image — no qcow2, no OVA — and images are amd64 UEFI only. The arm64 .deb exists for running the agent off-router against an arm64 router; there is no arm64 image.
  • The end-user terms are a placeholder, marked as one in their own first paragraph. Nothing should be sold until real terms replace them — The Wheelhouse licence.
  • IPv6 is configurable but not observable. There is no v6 route view and the uplink model has no v6 concept; the Firewall page is v4-first.
  • The audit log cannot leave the box and is not tamper-evident. It is complete — every mutating route records who did what from where, fleet writes included (agent/main.go, handleFleetConfigure) — but there is no syslog or SIEM export, and nothing signs it. Root on the box can rewrite it invisibly.
  • App images float. All 36 container entries use :latest, so what installs today is not what installed last month. Digest pinning is tooled and not applied.
  • There is no support bundle. Diagnostics are four manual API calls — Support.
  • Releases are not signed. The pipeline signs checksums the moment a key exists; no key does. A checksum proves the download survived the network, not who built it.
  • There are no UI tests. The agent has over two hundred test functions and CI runs them race-clean; ui/ has none, and CI only typechecks and builds it. Testing is not uniform and should not be described as though it were.
  • Packet capture is not implemented. POST /api/capture answers 501 and hands back the monitor traffic command to run by hand, rather than reporting a capture that never started.
  • UPnP has no answer. No credible published miniupnpd image exists, so the gap stays open and the page says so.

Shipped, but narrower than the name suggests#

The features below exist. Each is smaller than a reader might assume from its name, so the boundary is stated here rather than discovered later.

The nameWhat is actually there
CAKE shapingThe QoS editor stages qos policy cake with bandwidth, flow isolation and RTT, attached as egress on one interface, and shows the qdisc the kernel installed beside it. No ingress or IFB pipeline, no ack-filter, no DOCSIS overhead compensation, and no direct tc programming — ui/src/pages/Qos.tsx
1:1 NATThe nat static table reads rules made elsewhere; the editor is switched off, because committing those lines through this base's HTTP API stops the API process. The CLI accepts the same lines — Built on VyOS
Uplink health monitoringHealth is VyOS' own verdict — is the failover route in the forwarding table, and what does show wan-load-balance say. The agent probes nothing itself, and there is no per-target latency or loss history
FleetA JSON file of routers, concurrent health, per-router configuration and version reads, and a configure endpoint. Per-router staging and commit are not routed through it
Role-based accessThree roles — viewer, operator, admin — enforced server-side on every route. Per-object permissions do not exist, and neither does a hardware-key second factor
Two-factorTOTP only. No recovery codes, and no admin reset of another account's second factor. Losing the device means console access and a hand-edited state.json
The desired-state fileIt mirrors the VyOS configuration tree. The schema sketched in PLAN.md §6 is not what shipped; document and use the tree-shaped file
Conntrack byte countersThey need nf_conntrack_acct enabled on the router. Without it they are absent

Commercially, what is not ready#

PricesNot set. Both monthly figures in PRICING.md are <TODO: owner>
A licence agreement and terms of serviceDo not exist — The Wheelhouse licence
A support address, an issue tracker, a chat channelNone are public, and the source forge is private — Support
A security reporting addressNot published — Reporting a vulnerability
A release signing keyNone has been generated
The betaClosed and invite-only while the ISO gets its first bare-metal runs
The publisherNo company, team or location is established anywhere in the tree: <TODO: owner>

What this page is for#

Every release is driven in a browser against a live replica router before it is tagged. That is a real bar, and it is not the same bar as a hardware compatibility programme, a signed supply chain or a support contract. Read this page as the difference between the two, then decide.

See also#

Checked against#

README.md · PLAN.md · docs/hardware.md · docs/security.md · docs/apps.md · docs/multi-wan.md · PRICING.md · SUPPORT.md · agent/main.go · ui/src/pages/Qos.tsx

Updated 2026-09-02 status honesty roadmap