Roadmap#
This page has two halves. The first is short and says what is finished, so that the second half cannot be mistaken for a description of the product. The second is everything that is not built.
What is already built#
The short version. The long version, with its caveats attached to each line, is the status page.
| The configuration model | Staged changes in one working set, a diff rendered as the set and delete commands themselves, one Commit Bar that is the only thing that commits, VyOS' native commit-confirm, numbered revisions with a per-revision diff, and rollback. |
| The interface | 29 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, about, users, API tokens, agent settings and licence. Three of them appear only once their feature is installed or licensed. |
| 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 38-entry catalogue — 36 container apps and two 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, three server-enforced roles, scoped API tokens, OIDC single sign-on with group-to-role mapping, and an attributed audit entry for every mutation. |
| Automation | 108 API routes, the set the interface itself is built on, 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. |
Everything after this line is not that.
Before anything can be sold#
Not features. The things that have to exist before money changes hands, which is why they come first.
| Not built | What there is today |
|---|---|
| A complete install to disk on physical hardware, followed by a reboot into the installed system, recorded | The live image boots on hardware, and installs to disk in a virtual machine are verified for 0.4.5 and 0.5.0. Every end-to-end record names a VM |
| 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. The forge is private, so there is no public tracker either. <TODO: owner> |
| Two prices | The licence mechanism is built, tested and gated in the code. Both monthly figures are unset |
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 | A fleet write is a direct configure on that router: no working set, no Commit Bar, no commit-confirm. It is recorded in the audit log |
| Shipping the audit log off the box, and making it tamper-evident | An append-only file of JSON lines, complete and attributed, with no hash chain, no sequence numbering and no syslog or SIEM export. Root on the router can rewrite it invisibly |
| Recovery codes, and an administrator reset for another account's second factor | Neither. A lost phone means console access and a hand-edited state.json |
| A factory reset and a rescue boot entry | Neither. Recovery from a failed upgrade is the documented order plus a console shell |
| Digest-pinned app images | All 36 container entries use floating :latest tags, so what installs today is not what installed last month. Pinning is tooled and not applied |
| An OpenAPI document | The endpoint table in the operator reference is the contract |
| Tests on the interface | The agent has 226 test functions run race-clean in CI — count them with grep -h '^func Test' agent/*_test.go \| wc -l. ui/ has none; CI typechecks and builds it |
| 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. These are stated as facts with their verification dates, not as complaints: they are the bill for choosing VyOS.
| Not built | What there is today |
|---|---|
| UPnP or NAT-PMP | Nothing. The gap stays open until an agent-managed companion daemon exists: no credible published miniupnpd image exists, and an unaudited personal build is not what should run as a privileged host-network daemon. The Companions page says so |
The full CAKE knob set in both directions — an ingress pipeline through IFB, ack-filter, DOCSIS overhead compensation, NAT-aware flow isolation | The QoS editor stages bandwidth, flow isolation and RTT, attached as egress on one interface, beside the qdisc the kernel installed |
| 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 |
| A one-to-one NAT editor | The nat static table reads rules made from the console. The editor is switched off with the reason on the page: committing those lines through this build's HTTP API stops the API process, while the CLI accepts them. Verified 2026-09-02 |
Features that would extend the product#
Roughly in the order they are wanted, which is 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 |
Packet capture that runs, with a filter and a downloadable .pcap | POST /api/capture answers 501 and returns the monitor traffic command; the Diagnostics page shows you that command rather than reporting a capture that never started |
| 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 long-term graphs | Live counters, a server-sampled throughput series, conntrack top talkers, and NetFlow or IPFIX export so a collector keeps the history |
| IPv6 operational views | IPv6 is configurable and not observable: no v6 route view, no v6 concept in the uplink model, a v4-first firewall page |
| Network namespace and VRF panels, and ethtool or offload controls | Reachable from the console; no page |
| An OpenVPN instance editor | The page lists instances with per-mode status and can disable or delete them. Creating one waits on a generate pki flow |
| WireGuard handshake and transfer counters | Tunnels, peers and configuration. Those counters need wg show exposed by the agent |
| Git-backed configuration export | Numbered revisions, a per-revision diff, a two-step restore and a configuration download |
| Per-object permissions, and a hardware-key second factor | Three roles enforced on every route; TOTP |
| An in-product update notification | Nothing on the router reads the channel index. It exists for a person or a script |
| A catalogue fetched from a signed index | The catalogue is embedded in the agent binary, so a corrected entry needs an agent release |
Deliberately not planned#
Saying no is part of a roadmap. These are decisions, and they are 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.
- Per-app dashboard widgets, which would mean calling each app's own API — exactly the knowledge the health probe deliberately declines to claim.
- Starting and stopping containers out of band. There is no control socket. Stopping an
app stages
disable, starting it deletes that, and a restart is a two-commit bounce, because an app is configuration and configuration is what rolls back. - Consumer features. No mobile application, no parental-controls wizard, no household-router shape.
What changes the order#
Not a survey. 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.
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.