Compared with what you run now#
Five pages, and a matrix. Each page states what Wheelhouse does, sourced from its own code; states what the alternative does only where that is a matter of public record; and says where the alternative is better.
That last rule is not modesty. A reader who catches one overstatement discards everything else on the site, and this product's whole argument is that it does not overstate.
The configuration model#
The difference that is not a feature comparison, because it goes all the way down.
| Wheelhouse | OPNsense | pfSense | OpenWrt | UniFi | |
|---|---|---|---|---|---|
| Base system | VyOS on Debian | FreeBSD | FreeBSD | Linux | Linux |
| Where the configuration lives | the VyOS configuration tree, archived per commit under /config/archive | config.xml | config.xml | UCI files under /etc/config | the controller's database |
| Applying a change | staged into one working set; the Commit Bar is the only thing that commits | page by page | page by page | staged in UCI, then Save & Apply | the controller provisions the device |
| Seeing the change as router commands, before it is applied | every editor renders its set and delete lines, and the working diff is those lines | not a command model | not a command model | LuCI lists the UCI changes | not checked |
| A change that cuts you off | commit-confirm: miss the confirmation and the router reboots into the previous configuration | not checked | not checked | LuCI's apply can revert when it cannot reach you again | not checked |
| Undoing last week's change | roll back to a numbered revision, after reading its diff | configuration history with revert | configuration history with revert | restore a backup you took | restore a controller backup |
| Six edits across four pages | one transaction | six applications | six applications | one Save & Apply | one provision |
Two rows deserve their caveat in the open.
OpenWrt is the closest thing here to Wheelhouse's model, and it got there first. UCI stages changes, LuCI shows them before Save & Apply, and an apply can revert itself if it cannot reach your browser again. If that model is what you want and you are running OpenWrt, you already have most of it.
OPNsense and pfSense both keep a configuration history you can revert to. The difference Wheelhouse claims is not history; it is the diff before the change and the confirmation window during it.
Feature coverage#
| Wheelhouse | OPNsense | pfSense | OpenWrt | UniFi | |
|---|---|---|---|---|---|
| Firewall engine | nftables, the base's | pf | pf | nftables (fw4) | not checked |
| Shaping | CAKE through qos policy cake — bandwidth, flow isolation and RTT, attached as egress on one interface | shaper pipes and queues, FQ-CoDel | limiters, FQ-CoDel | SQM with CAKE, both directions | "smart queues" |
| Routing protocols | FRR: BGP and OSPF, configured and shown | FRR plugin | FRR package | FRR or BIRD packages | not checked |
| VPN | WireGuard as native configuration, an IPsec site-to-site editor, OpenVPN read-only | WireGuard, IPsec, OpenVPN | WireGuard, IPsec, OpenVPN | WireGuard, OpenVPN, IPsec packages | WireGuard, OpenVPN, IPsec |
| Intrusion detection | Suricata as a service page, and an inline IPS through NFQUEUE that is entirely configuration | Suricata, detection and inline | Snort or Suricata packages | packages | built-in threat management |
| Add-ons | 38 catalogue entries — 36 containers and two feature modules; installing a container app declares it in the configuration tree, so it diffs and rolls back | plugin repository | package repository | package feeds, far larger than 38 | not checked |
| Accounts | local accounts with Argon2id and TOTP, three server-enforced roles, scoped API tokens, OIDC with group-to-role mapping | local, LDAP, RADIUS, TOTP | local, LDAP, RADIUS | LuCI login and a root shell | Ubiquiti account, roles |
| An API the interface itself uses | 108 routes, token-authenticated; no OpenAPI document | documented REST API | not checked | ubus over JSON-RPC | not checked |
| What it costs | subscription; reading is free forever; prices are not set | open source, with a business edition | free edition; Plus is licensed | open source | bought with the hardware |
Where Wheelhouse loses today#
Nine rows, none of them softened. If one of these is the reason you would buy a router platform, buy something else — and the status page is the longer version of this table.
| Wheelhouse does not have | What there is instead | Who does have it |
|---|---|---|
| Alerting or notification of any kind. Nothing on the box sends an e-mail, a webhook or a push, and nothing watches a threshold. | Prometheus metrics on /metrics — request counts and latency, router reachability, staged operations, sessions, per-interface throughput, drift — for an Alertmanager you already run. | OPNsense and pfSense both notify; UniFi alerts. |
| Packet capture from the interface. | POST /api/capture answers 501, and the Diagnostics page shows you the monitor traffic command to run on the console instead of reporting a capture that never started. | OPNsense and pfSense capture from the interface; on OpenWrt it is a tcpdump package. |
| A client or device inventory. No named client list, no per-client history, no device grouping. | The DHCP lease table, the ARP table (show arp, so IPv4) and LLDP neighbours — three tables, cross-linked to reservations, and none of them an inventory. | UniFi. This is what UniFi is for. |
| UPnP or NAT-PMP. | Nothing. The Companions page says the gap is open. No credible published miniupnpd image exists, and an unaudited personal build is not what runs as a privileged host-network daemon. | OPNsense (plugin), pfSense (built in), OpenWrt (miniupnpd), UniFi (a setting). |
| Wireless, in any form. | Nothing, deliberately. Wheelhouse manages the router; put an access point behind it. | OpenWrt and UniFi. |
| Long-term graphs and per-host history. | Live counters over a WebSocket, a server-sampled throughput series, conntrack top talkers, and NetFlow or IPFIX export so a collector you run keeps the history. | OPNsense and pfSense ship graphs; UniFi keeps history. |
| A large add-on ecosystem. | 38 catalogue entries: 36 containers and two feature modules. Good coverage of the common cases, nowhere near a package feed. | OpenWrt's feeds, OPNsense's plugins, pfSense's packages. |
IPv6 you can watch. It is configurable and not observable: no v6 route view, no v6 concept in the uplink model, and a v4-first Firewall page. (The installer does close both families — it writes a v6 ruleset beside the v4 one, and says so if the image has no firewall ipv6 node rather than committing a v4-only ruleset quietly.) | The configuration tree, and the console. | Everything else on this page. |
| Other people's mistakes, already made. The changelog's first release is 0.3.0, dated 2026-09-01; the current version is 0.5.1. There is no complete install to disk on physical hardware on record, no hardware compatibility list, no signed release, no public issue tracker, no published support address, no terms of service and no price. | A repository that says all of that out loud, and a status page that keeps saying it. | All four. |
What makes the wins real#
Four claims above are load bearing. Each is one file away from being checked.
Nothing applies itself. The staging area lives in the agent, not the browser, so two
operators, a script and the optional reconcile loop share one queue —
agent/staging.go. The Commit Bar is the only thing that
commits: ui/src/components/CommitBar.tsx.
Commit-confirm is the router's own mechanism. POST /api/commit with
confirm_minutes calls VyOS' /configure with a confirm_time, and the confirmation is
its op: "confirm" — agent/vyos.go,
agent/main.go. It is not a timer in a web page, so it survives the
agent crashing, the tab closing and the link dropping. Nothing in the browser is holding
it. How commit-confirm works.
The commands on screen are the commands that run. Both sides quote a value the same
way — the renderer in ui/src/lib/format.ts and the agent's
own cliWord in agent/staging.go — so a block you copy out of an editor pastes into a
configure session and does the same thing. The whole running configuration renders the
same way through GET /api/config/commands.
An install is a configuration diff. An app is a set container name … subtree, so
installing one is a diff you read, a commit you can confirm and a revision you can roll
back to, and stopping one stages disable rather than reaching for a control socket —
agent/apps.go, agent/catalog.json.
And underneath all four, the base: nftables, tc and CAKE, in-kernel WireGuard, Podman,
network namespaces, and FRR for BGP and OSPF. A FreeBSD appliance is structurally locked
out of that list. That is not a criticism of anyone's engineering; it is the kernel.
The five pages#
- Compared with OPNsense — the configuration model, the Linux side, and the maturity Wheelhouse does not have.
- Compared with pfSense — the same argument, plus what a subscription gates here and how to test that claim on your own box.
- Compared with OpenWrt — the closest configuration model of the four, and the honest split between a router platform and a firmware project.
- Compared with the VyOS CLI — nothing is taken away. This is the base; the question is only what is added.
- Compared with UniFi and RouterOS — depth of control with a real configuration model, against a controller that hides the model or an interface that assumes you already know it.
The summary, if you only read one paragraph#
If you value a mature product with a large community, years of hardware reports and a public issue tracker, stay where you are — Wheelhouse has none of those yet. If you value a configuration model you can diff, commit, confirm and roll back, an API the interface itself consumes, and Linux-side features a FreeBSD appliance cannot offer, then the trade is worth looking at, and the status page tells you exactly what you would be trading for.
What none of these pages will do#
- Claim a feature an alternative lacks without checking it. That is what not checked means in the tables above, and it appears in rows Wheelhouse would otherwise win.
- Quote a benchmark. There is no throughput, packet-rate, CPU or memory measurement for Wheelhouse on any hardware, so there is nothing honest to compare.
- Disparage VyOS. It is the base this product is built on, and the page about it says so in the first sentence.