Compared with the VyOS CLI#

Nothing is taken away#

The console is still there. configure, set, compare, commit, commit-confirm, rollback, show configuration commands — all of it works exactly as it did, and Wheelhouse does not object to you using it.

Wheelhouse drives the router through VyOS' own documented HTTP API, as a separate program. It stores its own state under /config/wheelhouse and touches nothing else. If you make a change from the console, the interface reads it back the way it reads everything else; if you remove the agent, you have a VyOS router.

What is added#

A picture of the box. Live per-interface throughput from differenced counters, session counts, memory and disk, per-rule firewall hit counters, conntrack top talkers, the journal with a live tail, LLDP and the ARP table, certificate expiry dates.

Every object two interactions away. ⌘K indexes pages and configuration objects read from the running configuration — a firewall rule, a DHCP reservation, a WireGuard peer, an interface, a route — so you go to the thing rather than remembering where its screen is.

Pending changes you can hand to someone else. The staging area lives in the agent, so two people, a script and the optional reconcile loop share one queue, and the Commit Bar lists it one sentence per change for whoever reviews it.

Your own language, one switch away. Advanced mode, a preference of each account, puts the router's language back beside the words: the part of the tree each page edits, the commands each editor will add, the pending changes as set and delete lines, the router's own diff of every revision, and the configuration tree and reconcile pages. It changes what is shown, not what anyone may do.

Accounts. The CLI gives you system login users on the router. The agent gives you its own accounts with Argon2id and TOTP, four roles enforced on every route, API tokens with expiries, OIDC single sign-on with group-to-role mapping, and an audit entry naming who changed what from where. Two-factor comes with ten single-use recovery codes issued at enrolment, and an administrator can clear another account's second factor when the phone and the codes are both gone. That is usually the difference between "I run this" and "my team runs this".

A record of the changes that can leave the router. Each audit entry carries a sequence number and the hash of the one before it, GET /api/audit/verify names the first entry that does not fit, and configuring a syslog collector copies each entry to it as it is written. Root on the box can still re-chain the file, so the copy that proves anything is the one already off the router — and no collector is configured until you configure one.

A fleet view. A JSON file of routers, concurrent health, per-router configuration and version reads, and a per-router working set: stage, review, un-stage, discard and commit against one router's own queue on the agent. A fleet commit can arm that router's own commit-confirm and is confirmed on that router, so it has a timed rollback window of its own. All of it is audited with the router id.

A way to describe the router as a file. A desired-state document that mirrors the configuration tree, one engine behind the interface, the API, plan / apply and an opt-in loop, and drift on an endpoint and in three metrics.

A way back into the interface, and one file to send when you ask for help. The install medium carries a Rescue an installed Wheelhouse system boot entry, and wheelhouse-rescue at the console 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 written into the audit log. It does not recover the router's own console password; that is the base system's account and the base system's procedure. wheelhouse-support collects one redacted archive of what a diagnosis needs, rather than a list of commands to paste by hand.

A router that says when it is out of date. It reads the release channel once a day and the System page reports a newer version when there is one. It installs nothing, and the toggle on that page stops it asking.

What the interface still cannot do#

You already have the tool that can.

• Wireless. interfaces wireless is configurable from the CLI and has no page.
• Namespaces, and ring, queue and link-speed controls. Not built. The nine offload flags are on the interface detail. VRFs have a page that creates, edits and deletes them with their interfaces and static routes; a VRF's own BGP and OSPF are console work.
• IPv6 in the v4 pages. The IPv6 page shows v6 addresses, neighbours, routes and ip6 counters; the Routes page, the neighbour tables and the uplink model are still v4.

For every one of those the answer is the console, and the interface says so on the page rather than hiding the gap.

On the relationship#

Wheelhouse is a commercial product built on VyOS, which is GPL-licensed, and on Debian. The kernel, nftables, FRR, Kea, pdns-recursor, strongSwan, OpenVPN, Suricata and Podman are all upstream and unmodified. Wheelhouse adds the agent, the web interface, the installer and the packaging.

Images are self-built from vyos-build and rebranded per upstream's trademark policy, attribution intact. Every release carries a SOURCES-<version>-amd64.txt naming the exact vyos-build commit and every installed package, and the changes made to VyOS' build tooling are published because that tooling is GPL.

There is no partnership, endorsement, certification or affiliation between this project and the VyOS project, and none is implied. The VyOS trademark is not ours.

Read on#

• What you actually get — where the base ends and Wheelhouse begins.
• About — the attribution, and where the corresponding source is.
• The wiki: built on VyOS and the VyOS command reference.
• The parity matrix — what the interface adds, next to what it still lacks.