Compared with what you run now#
Three tables and five pages. Each one says what Wheelhouse does, what the alternative does, and which of the two is better at it.
The trade, in 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, the trade is worth looking at — and the status page says what you would be trading for.
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 | in Advanced mode, every pending change as the set and delete lines that will run; without it, each change as a sentence | 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 restarts with its saved 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 | an upload and a download rate on each interface: CAKE through qos policy cake — bandwidth, flow isolation, RTT, ACK filtering, NAT-aware fairness — or policing for the download; no DOCSIS or ATM overhead compensation | 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 with a QR code per device, an IPsec site-to-site editor, an OpenVPN editor for servers, clients and site-to-site ends that hands out and revokes client files | WireGuard, IPsec, OpenVPN | WireGuard, IPsec, OpenVPN | WireGuard, OpenVPN, IPsec packages | WireGuard, OpenVPN, IPsec |
| UPnP and NAT-PMP | spoken by the agent itself — SSDP, the IGDv1 port-mapping actions consoles and torrent clients use, and NAT-PMP — with each mapping committed as a destination NAT rule plus a forward-filter accept in a reserved band; off by default, allow-listed by client subnet, every mapping a revision and an audit entry; no IPv6 pinholes and no PCP | plugin | built in | miniupnpd | a setting |
| 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 | 40 catalogue entries — 37 containers and three 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, TOTP with ten single-use recovery codes and an admin who can clear a lost second factor, 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 | 143 distinct routes, token-authenticated, described by an OpenAPI 3.1 document the agent generates from its own route table (GET /api/openapi.json) | documented REST API | not checked | ubus over JSON-RPC | not checked |
| What it costs | subscription by router count: $9/mo Homelab (1), $19/mo Lab (3), $79/mo Business (10, commercial use); no plan includes support | open source, with a business edition | free edition; Plus is licensed | open source | bought with the hardware |
Where Wheelhouse loses today
Eight rows. 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. Nothing on the box watches a threshold, and no alert leaves it: no e-mail, no webhook, no push. | Prometheus metrics on /metrics — request counts and latency, router reachability, staged operations, sessions, per-interface throughput, drift — for an Alertmanager you already run; and the audit log copied to a syslog collector as each entry is written, a failed or refused change arriving as a warning, so the collector you already run is what alerts on it. The one notification in the product is the System page saying that a newer release exists. | OPNsense and pfSense both notify; UniFi alerts. |
| A capture you can leave running and come back to. | Diagnostics → Capture runs a bounded tcpdump from the interface and downloads the pcap. The page keeps watching while the file exists and withdraws the download when the 15-minute retention deletes it, so what it offers is what is there. | 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. |
| Wireless, in any form. | Nothing, deliberately. Wheelhouse manages the router; put an access point behind it. | OpenWrt and UniFi. |
| Graphs beyond a month. | Live counters over a WebSocket, per-interface throughput kept on the router (24 hours of minutes, 31 days of hours) and, since this cycle, per-host history: 31 days of hourly points for up to 256 hosts and 24 hours of minutes for the day's top talkers, folded from the conntrack table with no router API call. Byte totals are floors and need nf_conntrack_acct switched on; with it off the archive keeps flow and peer counts. Nothing is kept beyond 31 days, and NetFlow or IPFIX export exists so a collector you run keeps the long history. | OPNsense and pfSense ship graphs; UniFi keeps history. |
| A large add-on ecosystem. | 40 catalogue entries: 37 containers and three feature modules. Good coverage of the common cases, nowhere near a package feed. | OpenWrt's feeds, OPNsense's plugins, pfSense's packages. |
IPv6 in the v4 pages. Network → IPv6 shows v6 addresses, the NDP table, the v6 forwarding table and the ip6 firewall counters. What it does not do is put v6 into the Routes page, the neighbour tables or the uplink model, which stay v4. (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.) | A page of its own, and the console. | Everything else on this page. |
| Other people's mistakes, already made. The first release is 0.3.0, dated 2026-09-01; the newest tag is 1.0.2, dated 2026-10-21. Nobody hits these bugs before you do: an unattended install did not work in 0.6.0, 0.6.1 or 0.6.2 — the installer applied the seed's configuration, reported that the router had refused it, and never wrote the disk — and the fix for that is in the tree rather than in a release. The image has only ever been installed on one physical machine, so there is no hardware compatibility list, and there is no signed release, no public issue tracker, no published support mailbox and no terms of service. The prices are set; what you would buy under them is not. | 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 carry the argument.
Nothing applies itself. The staging area lives in the agent rather than the browser, so two operators, a script and the optional reconcile loop share one queue. The Commit Bar is the only thing that commits.
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". It is not a timer in a web page, so it survives the agent crashing, the
tab closing and the link dropping. How commit-confirm works.
What you review is what runs. Each pending change is described from the operations the
agent will send, and Advanced mode shows those operations as commands. The browser and the
agent quote a value the same way, so a block copied out of the Commit Bar 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.
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 argument, one product at a time
OPNsense
The configuration model, the Linux side, and the maturity Wheelhouse does not have. Read the comparison
pfSense
The same argument, plus what a subscription gates here and how to test that claim on your own box. Read the comparison
OpenWrt
The closest configuration model of the four, and the split between a router platform and a firmware project. Read the comparison
The VyOS CLI
Nothing is taken away. This is the base; the question is only what is added. Read the comparison
UniFi and RouterOS
Depth of control with a real configuration model, against a controller that hides the model or an interface that assumes you know it. Read the comparison
The gaps, in full
The same losses as the third table above, at the length they deserve, and kept current. What is finished, and what is not
Put it on a box and compare it yourself
A licence key opens the release host, and every page of the manual is public. The comparison that settles it is the one you run.