Wheelhouse

Compared with OpenWrt#

Of the four alternatives on this site, OpenWrt is the one whose configuration model most resembles this one, and the one where the argument for switching is weakest. This page says so first, because a reader who runs OpenWrt on an x86 box will work it out in ten minutes anyway.

Where OpenWrt is ahead#

  • Hardware. It runs on hundreds of devices across several architectures, with a device database people actually maintain. Wheelhouse is amd64 UEFI only, has no compatibility list, and no complete install to disk on physical hardware is on record.
  • Wireless. It is one of the reasons OpenWrt exists. Wheelhouse has no wireless of any kind and no plan for it.
  • Shaping. SQM with CAKE in both directions, including the ingress pipeline through an IFB device, and the knobs that matter on a cable line. The Wheelhouse QoS editor stages qos policy cake with bandwidth, flow isolation and RTT, attached as egress on one interface, and that is the whole of it — ui/src/pages/Qos.tsx. On a shaped cable connection, OpenWrt does the better job today.
  • Packages. Feeds with thousands of packages, against a 38-entry catalogue.
  • It is free, and it is open source. Wheelhouse is a paid, proprietary agent and interface on a GPL base. If free matters more than everything below, this comparison is already over, and that is a reasonable place to land.
  • A public bug tracker, a forum and a decade of releases. Wheelhouse's forge is private and its changelog starts on 2026-09-01.

Where the two agree#

More than you might expect, and it is worth naming because it narrows the argument.

Both stage changes before applying them. UCI collects edits and LuCI shows them before Save & Apply; Wheelhouse collects them in the agent and the Commit Bar shows them as set lines. Both can put the configuration back if an apply cuts the operator off — LuCI's apply can revert when it cannot reach your browser again, and Wheelhouse arms VyOS' commit-confirm.

Both are Linux, so both get nftables, tc and CAKE, in-kernel WireGuard and the rest of the kernel's network stack. Both have a machine interface: ubus over JSON-RPC there, a documented HTTP API here.

Anyone claiming OpenWrt has no configuration model has not used it.

Where they differ#

The configuration is a typed tree, not files. VyOS validates at commit: a set the router will not accept is refused with the router's own message, before anything changes, and the agent shows you that message rather than a generic failure. UCI is text files that services read; validity is whatever the service that reads them decides at start-up.

History is numbered, not something you remembered to take. Every commit archives a revision under /config/archive. The interface lists them, diffs any one of them against what is running, and rolls back to it — agent/main.go handleHistoryDiff and handleRollback. On OpenWrt, configuration history is the backups you took.

The rollback timer belongs to the operating system. LuCI's revert-on-apply is the web interface's mechanism, keyed on your browser reconnecting. VyOS' commit-confirm is the config backend's: the router reboots into the previous configuration if no confirmation arrives, whoever was or was not watching. It is the same mechanism a CLI operator uses, driven from a button.

Routing protocols are configured and shown, not installed. FRR is in the base with BGP and OSPF pages beside the rest of the interface.

Accounts. OpenWrt's web interface signs you in as root. Wheelhouse has its own accounts with Argon2id and TOTP, three roles enforced server-side 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, as which role — agent/auth.go, agent/oidc.go, agent/store.go. For one person and one router that is overhead. For a team, it is usually the requirement that decides the purchase.

Somebody to invoice. There is an intended support tier and no published address yet, which is a gap this site states rather than hides — Support.

The narrow case for paying#

State it narrowly, because it is narrow.

You are running x86 hardware, not a consumer access point. More than one person touches the router, and you need to know which one changed the NAT rule. You want the change reviewed as commands before it lands and archived as a revision afterwards. You want BGP or OSPF without assembling it. You would rather buy support than read a forum thread at 02:00.

If most of those are true, this is a defensible purchase. If you are one engineer with one box and a wireless card in it, OpenWrt is the better answer and this page is not going to pretend otherwise.

Read on#

Updated 2026-09-02

Edit this page