Roadmap#
Two halves: what is finished, and then everything that is not, with what exists in each one's place today. There are no dates anywhere on this page.
What is already built#
The short version. The long version, with its caveats attached to each line, is the status page.
This describes the current code, which is the newest tagged release, 1.0.2. It stops
a health check that policy local-route keeps on its uplink from being reported as
missing its target routes. 1.0.1 kept per-host history for the devices on the router's own
networks ahead of internet hosts, brought a browser tab through an agent update instead of
blanking it, and carried dynamic DNS through an OPNsense import. 1.0.0 added UniFi OS
Server to the catalogue and made apps
on the app network reachable behind the installer's firewall. Earlier releases added the
audit chain and its export, recovery codes
and the administrator reset, the OpenAPI document, the release-channel check, the support
bundle, the rescue boot entry and a digest-pinned catalogue — and they carry the fix for
the unattended install, which
did not work in 0.6.0, 0.6.1 or 0.6.2 — the installer applied and saved the seed's configuration
to the live system, reported that as a refusal, and never wrote the disk. The
status page says what caused it.
| The configuration model | Changes waiting in one list of pending changes, each read as a sentence — or, in Advanced mode, as the set and delete commands themselves — one Commit Bar that is the only thing that applies them, VyOS' native commit-confirm as auto-revert, numbered revisions with a per-revision diff, and rollback. |
| Editing | A form for every setting a page shows, with each value checked under its field before anything is saved, and no page that hands a change to the console. Commands, configuration paths and the configuration tree appear only in Advanced mode, a preference of each account that is off by default. |
| The interface | 30 left-navigation entries in eight groups: dashboard, interfaces, static routes, BGP and OSPF, high availability, QoS, firewall, NAT, IDS, WireGuard, IPsec, OpenVPN, DHCP, DNS, apps, companions, sessions, diagnostics, logs, system, certificates, config tree, reconcile, fleet, support, about, users, API tokens, agent settings and licence. Three of them appear only once their feature is installed or licensed, and two, the config tree and reconcile, only in Advanced mode. |
| Multi-WAN | Uplinks through every mechanism the base offers, health-checked failover, load balancing, policy routing and per-uplink NAT, proven on a dual-WAN virtual machine built from the image. |
| Security | Suricata as a service page, and an inline IPS in the packet path through NFQUEUE that is entirely configuration, so it diffs, commits and rolls back. |
| Add-ons | A 40-entry catalogue — 37 container apps and three feature modules. Installing a container app declares it in the configuration tree; installed apps get a navigation entry, a health probe and integration offers on the pages they affect. |
| Accounts | Argon2id, TOTP with ten single-use recovery codes issued at enrolment, an administrator reset of another account's second factor, four server-enforced roles — viewer, approver, operator, admin — scoped API tokens, OIDC single sign-on with group-to-role mapping, and an attributed audit entry for every mutation. |
| The audit log | Every entry carries a sequence number and the hash of the entry before it, GET /api/audit/verify walks the chain and names the first entry that does not fit, GET /api/audit/export hands over a copy, and a syslog collector can be configured so entries leave the box as they are written. A chain proves a break; it does not prevent one, and root can still rewrite the file. |
| Automation | 134 distinct API routes, the set the interface itself is built on, described by an OpenAPI 3.1 document the agent generates from that same route table; plus a desired-state file behind one engine used by the interface, the API, plan and apply and an opt-in loop, and drift on an endpoint and three metrics. |
| Getting onto it | A dialog installer, an unattended seed on a stick or a URL, and an importer that turns an OPNsense config.xml into commands plus a report. |
| Getting back into it | A rescue entry in both of the install medium's bootloaders, landing on a console tool that resets a web UI password, clears a second factor, re-runs first boot, restores a configuration and says why the agent will not start — every action that changes something written into the audit log's chain. A factory reset, from that tool or from the System page. Plus a redacted support bundle from the Support page, the agent or the console, and a release-channel check that says when a newer version exists without installing it. |
Everything after this line is not that.
Before anything can be sold#
Not features. These have to exist before money changes hands.
| Not built | What there is today |
|---|---|
| A second machine | The image installs to a disk and reboots into itself, in VMs and on one physical machine — four installer bugs were found that way. No other board, appliance or network card has ever run it, so there is nothing that could be called a compatibility list |
| A release signing key | The pipeline signs SHA256SUMS the moment a key is configured. No key exists, the channel index reports signed: false, and a checksum proves the download survived the network and nothing more |
| A licence agreement and terms of service | A stopgap TERMS.txt that says in its own first paragraph that it has not been through legal review, so the image does not carry someone else's agreement instead |
| A published support address and a security disclosure address | Neither has been chosen. The forge is private, so there is no public tracker either, and a report has nowhere to go |
Closing the gap between what is claimed and what is true#
Each of these exists to make a sentence on this site fully true that is only nearly true today.
| Not built | What there is today |
|---|---|
| ~~Fleet staging and commit, routed to a named router~~ | Built. Each router has its own pending changes on the agent, reviewed and applied from the Fleet page, and a fleet commit can arm that router's own auto-revert window, confirmed on that router and no other. What is still missing is a change applied to several routers at once, and forms for a far router's settings. Every fleet write is recorded in the audit log |
| A signature over the audit log, or an append-only store the router cannot rewrite | Sequence numbers and a hash chain, verified by an endpoint, and — once a collector is configured, which it is not out of the box — a copy sent to it as each entry is written. That makes tampering visible; the off-box copy is best-effort, so an entry the collector cannot take is dropped and counted rather than queued, and none of it stops root on the router from rewriting the file it keeps |
| ~~A factory reset~~ | Built. System → Overview → Factory reset, or the console tool, deletes the accounts, tokens, second factors, audit log and histories, keeps the licence key, and can restore the image's default configuration. Before it, there was a rescue boot entry and a console tool that resets a password, clears a second factor, re-runs first boot and restores a configuration — but nothing that returns the box to a shipped state |
| An app catalogue actually served from a signed index | The agent fetches a signed catalogue index and verifies a detached ed25519 signature against a key compiled into it, refusing anything that does not verify. No signing key exists, so the embedded catalogue is what ships and a corrected entry still needs an agent release. Its 37 images are pinned by digest, which fixes the bytes but says nothing about who published them |
| ~~Tests on the interface, run in CI~~ | Built. CI runs the interface's page tests beside its type check and build, and the agent's more than a thousand test functions race-clean. What is still missing is a test in a browser — the page tests run in jsdom, which has no layout, focus order or live socket — and any test for the configuration tree, Reconcile, Support, About and Licence |
| A management listen address that survives an upgrade | The agent binds every interface, so the firewall is what keeps the management port off the WAN. The address is a flag in the systemd unit, and an image upgrade replaces the unit |
Platform gaps#
Places where the base cannot express something, and Wheelhouse would have to go beneath it to change that. They are part of choosing VyOS.
| Not built | What there is today |
|---|---|
| ~~UPnP or NAT-PMP~~ | Built. The base still has no service upnp configuration node and no miniupnpd package, and no credible published miniupnpd image exists, so the agent answers UPnP and NAT-PMP itself. Each mapping is a port forward and a firewall rule, applied like any other change, from Services → UPnP once UPnP / NAT-PMP is installed from Apps. It is off until an administrator turns it on, and IPv4 only: a request for an IPv6 pinhole is refused |
A tc and qdisc tree visualiser, and DOCSIS or ATM overhead compensation | The QoS page gives each interface, a VLAN included, an upload and a download rate: CAKE for upload, and CAKE or policing for download, 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. CAKE cannot attach to an interface's ingress on this platform, so a CAKE download goes through an IFB the agent chooses. Turning download shaping off leaves the IFB device idle for the next use rather than deleting it — deleting it is a commit this base has been seen to fault on — so nothing is handed to the console. DOCSIS and ATM overhead compensation have no configuration node on this platform at all — there is no docsis, overhead, mpu or atm leaf under qos policy cake |
| Wildcard DNS, per-host DHCP option overrides, and an architecture-conditional PXE boot file | The configuration tree cannot express any of the three. dnsmasq is in the catalogue as the workaround; an agent-managed companion is the intended answer |
Committing nat static through the router's HTTP API | Wheelhouse does not write nat static. Since 0.9.1 a 1:1 mapping is a destination and a source NAT rule that the agent plans and the Commit Bar applies like any other change, and a nat static rule made at the console is listed and left alone. Committing nat static through this build's HTTP API has been seen to stop the API process, while the CLI accepts it (seen 2026-09-02; not reproduced on 0.6.2, 2026-09-04). The agent refuses nat static at every staging and configure route, so nothing can reach that commit path by accident |
Features that would extend the product#
Roughly in the order they are wanted. Not a schedule, and not a queue anyone is working down.
| Not built | What there is today |
|---|---|
| An nftables inspector — the real ruleset, chain by chain, mapped back to the configuration objects that generated each rule | Per-rule hit counters joined from firewall statistics |
| Alerting: a threshold, a notification, an e-mail, a webhook | Prometheus metrics on /metrics for an Alertmanager you already run. Nothing on the box notifies anyone of anything |
| Per-host traffic history, and graphs beyond 31 days | Per-interface throughput for 24 hours at one-minute and 31 days at one-hour resolution on the router; live counters; conntrack top talkers; NetFlow or IPFIX export so a collector keeps per-host and longer history |
| IPv6 in the v4 pages, and in the uplink model | An IPv6 page shows v6 addresses with scope, the NDP table, the v6 forwarding table and the ip6 firewall counters. The Routes page still reads show ip route, the neighbour tables still read show arp, and the uplink model has no v6 concept |
| Network namespace panels, and ring, queue and link-speed controls | Reachable from the console; no page. A VRF page, which creates, edits and deletes VRFs with their interfaces and static routes, and the nine offload flags on the interface detail are built |
| ~~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 |
| Per-object permissions, and a hardware-key second factor | Four roles enforced on every route; TOTP, with recovery codes and an administrator reset |
| An upgrade the product performs | The router reads the release channel on a timer and says when a newer version exists and where on the System page to add it; Advanced mode adds the commands that install it. It installs nothing itself: an add system image upgrade is driven through the endpoint or the console, has been done end to end on a VM, and has never been done on a physical machine |
| A catalogue signing key | The agent fetches a signed catalogue index, verifies a detached ed25519 signature against a key compiled into it, and refuses anything that does not verify — with the reason on the Apps page. No signing key exists, so every agent serves the catalogue compiled into it and a corrected entry still needs an agent release |
Deliberately not planned#
Decisions rather than gaps, and unlikely to move.
- A wireless controller. Wheelhouse manages the router. Put an access point behind it.
- Switch management beyond LLDP telling you what you are plugged into.
- A cloud console or a remote-access relay. The management interface is on the router; reaching it from outside is your VPN's job.
- Calling an app's own API on its behalf — anything needing that app's credentials, or a client that models its endpoints. The boundary moved once and only this far: 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. Two entries declare one. The health probe is still TCP plus an optional HTTP path.
- Starting and stopping containers out of band. The platform offers no operational verb
for either, so both stay configuration: stopping an app stages
disableand starting it deletes that, because an app is configuration and configuration is what rolls back. Restarting is the exception the platform does offer — onerestart containercommand, audited, writing no revision — and it is built. - Consumer features. No mobile application, no parental-controls wizard, no household-router shape.
What changes the order#
The fastest way to move something up this list is to install the product on real hardware and report what breaks, which is what the closed beta is for. The first entry under Before anything can be sold is the one everything else waits behind.
Install it and tell us what broke
The image has run on one physical machine. The second one is worth more to this list than anything on it.
Read on#
- What is finished, and what is not — the other half of this page.
- The parity matrix — where those absences leave Wheelhouse against OPNsense, pfSense, OpenWrt and UniFi.
- Beta.