A router GUI that shows its work#

A router operating system for engineers who want a web interface and refuse to give up the configuration model. VyOS underneath. Every form renders the exact commands it will run, nothing applies itself, and a commit can arm the router's own auto-rollback.

Download an image Read the documentation

Fill in a form, read the commands#

This is the New port forward panel with 443 published to a server at 10.0.10.20, and also allow it through the firewall left ticked. It renders this before anything is staged, with a copy button:

set nat destination rule 100 inbound-interface name eth0
set nat destination rule 100 protocol tcp
set nat destination rule 100 destination port 443
set nat destination rule 100 translation address 10.0.10.20
set nat destination rule 100 description 'web server'
set firewall ipv4 forward filter rule 100 action accept
set firewall ipv4 forward filter rule 100 inbound-interface name eth0
set firewall ipv4 forward filter rule 100 destination address 10.0.10.20
set firewall ipv4 forward filter rule 100 description 'allow web server'

Nine lines from one form. The four firewall lines are the accept rule that a destination-NAT rule needs and that people forget; the panel offers it, shows it, and lets you untick it. The quotes around 'web server' are there because a value with a space is one argument only once it is quoted — the same spelling VyOS' own tab-completion produces, so the block pastes into a configure session and does the same thing.

That is the whole thesis. The GUI is not a layer over the configuration model; it is a way of writing in it, out loud.

Nothing on any page applies itself#

Staged changes accumulate in one place. The Commit Bar is the only thing in Wheelhouse that commits, and it shows you the working set as the commands themselves before it does:

Working diff — 9 changes      touches firewall / NAT / addressing — commit-confirm recommended

 + set nat destination rule 100 inbound-interface name eth0
 + set nat destination rule 100 protocol tcp
 + set nat destination rule 100 destination port 443
 + set nat destination rule 100 translation address 10.0.10.20
 + set nat destination rule 100 description 'web server'
 + set firewall ipv4 forward filter rule 100 action accept
 + set firewall ipv4 forward filter rule 100 inbound-interface name eth0
 + set firewall ipv4 forward filter rule 100 destination address 10.0.10.20
 + set firewall ipv4 forward filter rule 100 description 'allow web server'

COPY INTO A CONFIGURE SESSION                        [ Copy ]

 ●  9 staged        [ Hide diff ]  [ Commit-confirm (2m) ]  [ Commit ]  [ Discard ]

Each line has an × that removes that one operation. A delete renders with a − and in the danger colour. Paths that can cut you off — firewall, nat, system login, anything touching an address or the default route — are highlighted, and when the working set contains one, the plain Commit button is styled as destructive.

Commit-confirm is the router's, not a timer in a web page#

Press Commit-confirm (2m) and the agent calls VyOS' /configure with a confirm_time. If nobody confirms inside the window, the router reboots into the previous configuration. That is the operating system's own mechanism, the one the CLI uses; it survives the agent crashing, the browser closing and the link going down, because none of those are what is holding the timer.

While the window is open the Commit Bar becomes the countdown and says why:

Commit-confirm armed — 1:47 remaining

If you can still read this page, the change worked. Confirm to keep it — otherwise the
router reboots into the previous config.

              [ Confirm & keep changes ]   [ Dismiss ]

A commit that locks you out is the oldest failure in this job. This is the only honest fix for it, and it is a property of the platform rather than a feature of the interface. How commit-confirm works.

Why this rather than OPNsense#

• The configuration model. VyOS stages, diffs, commits, confirms and archives every revision. OPNsense applies changes as you make them, with no first-class diff. That difference is not a UI decision; it goes all the way down.
• Linux, not FreeBSD. nftables, tc and CAKE, in-kernel WireGuard, network namespaces, Podman containers as configuration objects, FRR for BGP and OSPF.
• Single sign-on with roles and an attributed audit log. OIDC with group-to-role mapping, three server-enforced roles, and an audit entry naming who changed what from where. Neither OPNsense nor pfSense has that at any price.
• Where OPNsense is ahead. It is mature, it has years of hardware reports from real users, a public issue tracker and a large plugin ecosystem. Wheelhouse has none of that yet, and says so in public.

The full comparison

What is actually built#

Counts from README.md, agent/catalog.json and ui/src/components/nav.ts; each is a grep away from being re-checked.

What it costs#

A subscription unlocks configuration changes on a router. Reading is free, forever: an unlicensed agent still signs you in and shows every page, counter, log and audit entry. It refuses only to change anything.

What a licence gates

No third parties, here or on the router#

This website loads nothing from anywhere else. No analytics, no tag manager, no hosted font, no embedded video, no cookie banner — because there are no cookies to consent to. The router is the same shape: one licence-refresh request a day carrying four fields, and a page that lists them.

Where to go next#

• Why Wheelhouse — the trade-off everything else asks you to make.
• How it works — click, commands, diff, commit, in four steps.
• Features — ten pages, each with the code behind it.
• Compared with what you run now — OPNsense, pfSense, the VyOS CLI, UniFi and RouterOS.
• Download — where the image is and how to check what you got.
• The documentation — every screen, every flag, every file.

Everything else on this site#

What you actually get · Pricing · Hardware · What is finished, and what is not · Roadmap · Security · Privacy · Support · Beta · Questions · About · Legal