Why Wheelhouse#
You already run a firewall. It works. This page is about the specific thing that annoys you about it, and whether the annoyance is fixable or structural.
The three deals on offer#
A GUI appliance with a weak configuration model. OPNsense, pfSense. Everything has a form, and the forms are good. But a change is applied when you press Save, one page at a time. There is no staged diff of what you are about to do, no single transaction covering six edits across four pages, and no mechanism that puts the box back if the change was the one that cut you off. The backup is an XML file; comparing two of them is your problem.
A strong configuration model with no GUI. The VyOS CLI, and the same family of ideas
in JunOS. set, compare, commit, commit-confirm, rollback — a real transaction
with a real diff. It is the right model and it has no dashboard, no live counter beside
the rule, no view of twelve routers at once, and no way to hand a junior a read-only
login.
An enterprise box. It has both, and it also has per-seat pricing, a support contract to open a case against, and a stack you are not allowed to look inside. When it does something surprising you file a ticket rather than read a file.
What is actually structural#
The interesting question is which of those limits is a decision and which is a foundation.
The GUI appliance's missing diff is a foundation. Its configuration is a document that gets translated into daemon configuration when you save; there is nowhere for a transaction to live. You cannot add commit-confirm to it as a feature, because there is nothing to roll back to that the box itself understands.
The CLI's missing dashboard is a decision. The model underneath is already transactional, already versioned, already scriptable over an HTTP API. Nothing about it forbids a web interface. Nobody had built one that respected it.
That asymmetry is the entire product. Wheelhouse takes the platform that already has the hard part and builds the missing half on top, without hiding the half that was already there.
What "without hiding it" means concretely#
Four rules, and every page in the interface follows all four. They are written down in
the product's own developer documentation, not just here
(docs/ui.md):
- Nothing applies itself. Editors stage; only the Commit Bar commits. Every editor
renders the exact
setanddeletecommands it will run, with a copy button, before anything is staged. - State and intent are visually distinct. Configured values are plain fields; live values carry a pulse dot or a counter column. Where the two disagree the page shows a drift badge naming the disagreement — an interface the kernel reports but the configuration does not declare, a qdisc that is not the policy's, a static route declared but absent from the forwarding table.
- Empty states teach. A blank page names the concepts behind it and lists the commands that would populate it, instead of saying "no data".
- Side panels, not modals. Editing an object keeps its table readable behind the panel.
Rule 1 is the marquee one and rule 2 is the one you will end up depending on. A GUI that shows you what you configured and calls it the truth is how you spend an hour debugging a daemon that is running yesterday's file.
Who this is for#
| You are | Today | What changes |
|---|---|---|
| A homelab or prosumer engineer | OPNsense or pfSense | Linux features that FreeBSD cannot offer — nftables, tc and CAKE, in-kernel WireGuard, containers — plus a configuration you can diff and an API that was not an afterthought |
| A VyOS CLI operator | Terminal, the JSON API, git | The same set / commit / confirm model you already think in, with dashboards, live counters, a fleet view and an audit trail on top. The GUI cannot lie to you, because it shows you the commands |
| A MikroTik power user | Winbox | Comparable density of control, a modern interface, and a Linux underneath you can inspect |
| A small MSP or network team | UniFi (too shallow) or an enterprise box (too expensive) | Multi-site status, configuration as data, real routing protocols, single sign-on with roles and an attributed audit trail, without per-seat pricing |
From README.md and PLAN.md §2.
Who this is not for#
Stated plainly, because the fastest way to lose an engineer's trust is to sell them something that was never going to fit.
- Consumer households. There is no app, no parental-controls wizard and no intent to build them.
- CGNAT-scale ISP gear. Wrong shape entirely.
- Anyone wanting UniFi's wireless controller. Wheelhouse manages the router. Access points go behind it and are managed by whatever manages them today.
- Anyone who needs a compatibility list today. There is no tested-hardware list, and this site will not invent one.
The honest state of it#
This is a young product. The argument above is about a design that is built and running; it is not an argument about a mature one. Before you take any of it seriously, read what is finished and what is not — the same list the repository keeps, in public, including the parts that would put you off.
Next#
- How it works — the four steps, with the commands.
- Compared with OPNsense — the specific differences, and where OPNsense is ahead.
- Compared with the VyOS CLI — what you keep, and what is added.