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.

How to get the image The parity matrix

Where OpenWrt is ahead#

  • Hardware. It runs on hundreds of devices across several architectures, with a device database people actually maintain. Wheelhouse is amd64 only (UEFI or legacy BIOS), has no compatibility list, and has only ever been installed on one physical machine.
  • 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, and the knobs that matter on a cable line. Wheelhouse does both directions too — an upload and a download rate on each interface, the download shaped with CAKE or policed — but not the cable knobs: this base has no docsis, overhead, mpu or atm leaf under qos policy cake at all, so DOCSIS framing compensation cannot be configured from the UI or the console. On a shaped cable connection, OpenWrt still does the better job.
  • Packages. Feeds with thousands of packages, against a 40-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, which 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 lists them as sentences, or as set lines in Advanced mode. 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. 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 restarts with its saved 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, four 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. For one person and one router that is overhead. For a team, it is often the requirement that decides the purchase.

Somebody to invoice. There is an intended support tier and no published address yet — 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.

Read on#

Worth twenty minutes in a VM

If the staged-diff model is what you already like about UCI, this is the same idea with a transaction and a confirm window around it.

How to get the image How it works