Wheelhouse

Compared with the VyOS CLI#

This is the one comparison where the alternative is not a competitor. Wheelhouse is built on VyOS. The CLI you are comparing against is running on the same box, unchanged, and everything below is about what sits beside it.

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.

A working diff 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 shows it as commands.

Accounts. The CLI gives you system login users on the router. The agent gives you its own accounts with Argon2id and TOTP, three 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. That is usually the difference between "I run this" and "my team runs this".

A fleet view. A JSON file of routers, concurrent health, per-router configuration and version reads. Per-router staging and commit are not routed yet: a fleet write is a direct configure on the named router, outside the working set and the Commit Bar, recorded in the audit log.

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.

What the interface still cannot do#

Being honest about this is the point of the page, since you already have the tool that can.

  • Wireless. interfaces wireless is configurable from the CLI and has no page.
  • One-to-one NAT. The editor is switched off, because committing nat static through this build's HTTP API stops the API process. The CLI accepts the same lines, so the console is the way to write those rules; the table reads them back.
  • Creating an OpenVPN instance. It needs a generate pki flow that is not built.
  • Namespaces, VRFs and ethtool controls. Not built.
  • Packet capture. POST /api/capture answers 501 and hands you monitor traffic.
  • Anything IPv6 in the operational views. Configurable, not observable.

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>.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#

Updated 2026-09-02

Edit this page