Hardware#

There is no certified compatibility list, and this site will not invent one. A hardware statement nobody has tested is worse than none.

What has actually been run#

The honest inventory, from the repository's own record.

	Status
Booting the live image in a VM	Yes, repeatedly
Installing to a disk in a VM and rebooting into it	Yes. Keyboard-driven for 0.4.5, and unattended for 0.5.0 from a seed carrying a real router's 214-command configuration
Refusing to reinstall over itself when the seed medium is left plugged in	Yes, on the same VM
Booting the live image on physical hardware	Yes. It is where three installer bugs were found and fixed between 0.4.1 and 0.4.5
A complete install to disk on physical hardware, followed by a reboot into the installed system	Not recorded. Every end-to-end verification names a VM
An `add system image` upgrade of a Wheelhouse box	Not recorded, on hardware or in a VM
Any measurement of CPU, memory or throughput on real hardware	None

If you are evaluating this, install it in a VM first. That path has the evidence behind it, and it exercises the same installer, the same units and the same first-boot sequence as the metal.

Sizing#

Reasoned from what the software does, not measured on a bench. A starting point.

	Minimum	Comfortable
CPU	any 64-bit x86 with two cores	four cores; an Intel N100-class SoC is the shape this is designed around
RAM	2 GB	4 GB, or 8 GB if you run containers from the app store
Disk	16 GB	32 GB or more
Network ports	2	2 or more

Where those come from:

Disk. The image is about 595 MB, and the platform keeps the previous image beside the new one after an upgrade, so two are usually on disk. Add the configuration archive, container images if you install apps, and the journal. 16 GB is tight but workable; 8 GB will install and then run out.
RAM. Each password check allocates 64 MiB for Argon2id for about 60 ms, so simultaneous logins are the memory spike. Then the base itself, Podman, and whatever containers you install.
CPU. Argon2id is the only deliberately expensive thing the agent does. Routing performance is the kernel's, and nothing Wheelhouse adds changes it.

Network interfaces#

The image carries the stock VyOS kernel plus vyos-linux-firmware and the platform's out-of-tree driver packages. From a shipped image's own package manifest:

Package	Covers
`vyos-intel-i40e`, `vyos-intel-iavf`	Intel X710/XL710/X722 and their virtual functions
`vyos-intel-ice`	Intel E810
`vyos-intel-ixgbe`, `vyos-intel-ixgbevf`	Intel 82598/82599/X520/X540/X550 and virtual functions
`vyos-intel-qat`	Intel QuickAssist crypto acceleration
`vyos-drivers-realtek-r8152`	Realtek USB Ethernet adapters (RTL8152/8153/8156)
`vyos-linux-firmware`	non-free firmware the kernel loads at probe time
`amd64-microcode`, `intel-microcode`	CPU microcode, applied at boot

Everything else is whatever the stock kernel has in tree. In practice that is the usual Linux server-NIC coverage — Intel igb, igc, e1000e, Realtek r8169, Broadcom, Mellanox — but that is inference, not a test result. Nobody here has verified any specific card.

The way to find out for a box you are considering is to boot the live image on it and look, before installing anything:

ip -br link
show interfaces

If your ports appear with a MAC address, the driver loaded. If they do not, no configuration will help, and there is no mechanism in this project to add a driver or a firmware blob to the image.

Storage, boot and console#

Storage. The installer offers every block device reported as a disk that is not the medium you booted from, with its size and model. NVMe, SATA and USB disks all appear.

You can install onto a USB stick. Do not: the configuration archive, the journal and the agent's state file are written continuously, and flash without wear levelling will die.

RAID-1 is offered by the platform's own image installer, and Wheelhouse's driver answers no to every RAID question. If you want a mirror, install from the console with install image by hand.

Secure Boot. Untested; assume you have to turn it off. The image contains Debian's shim-signed and grub-efi-amd64-signed, but the build passes no signing key, no key material for signing a kernel exists in this project, and the branding step deliberately removes the upstream vendor's own machine-owner certificates rather than enrolling another company's trust anchor on your box. So the chain Secure Boot needs is not one this project completes, and nobody has reported the result either way.

Console. Video and serial both work. The installer detects console=ttyS on the kernel command line and makes the serial console the default on the installed system, so a headless box stays reachable the way you installed it. On a live boot the installer takes the first video console only; a serial console keeps its login prompt and the banner there tells you how to start the installer. Everything is drawn in 80 columns.

Wireless is not surfaced. Configurable from the console; no page in the interface, no question in the installer. A router product is expected to be wired.

Two things to know before buying an appliance#

A four- or six-port box installs with one LAN port configured. The installer asks for one WAN and one LAN; the rest come up unconfigured, and there is no bridge, VLAN or LAG option in the installer. Add them afterwards from the interface or the console.
The installer's WAN is DHCP or a static address. No PPPoE and no VLAN tag on the WAN. Much DSL and a lot of FTTH needs one of those; skip the WAN question and configure it afterwards from the interface, which does model PPPoE.

If you install on hardware#

The useful things to record are the board or appliance model, the NIC controllers (lspci -nn | grep -i net), whether Secure Boot had to be turned off, and whether every port appeared. That is exactly the information this page is missing, and it is what turns "should work" into a list.

Where to send it is not published yet: <TODO: owner>. The beta exists for precisely this.

Read on#

Download — the image and how to verify it.
The wiki: requirements and installing in a VM.