Boot the live ISO and walk through one guided installer. HosterOS installs Ubuntu or Rocky Linux on ZFS, configures storage and networking, and lays down the versioned QEMU and Cloud Hypervisor stack for first boot.
╔══════════════════════════════════ Topologies ══════════════════════════════════╗ ║Selected Topology Usable Protection ║ ║( ) STRIPE 3.49 TiB None ║ ║(•) MIRROR 1.75 TiB 1 disk ║ ║ ║ ║ ║ ║ ║
Captured from the installer itself in preview mode. Pick a screen to see it.
Every disk is listed by its most stable path — by-id first, then by-path, then the raw node — so a reboot that renames /dev/nvme0n1 cannot repoint the install. Only the disks marked ✓ are touched, and the header keeps a running count of what that means in capacity.
Choose stripe, mirror, or RAIDZ1/2/3 as the selected disk count allows. Usable capacity and failure tolerance update before anything is written. The pool is created with compression=lz4 and the OS is installed onto it — ZFS on root from the first boot.
Selecting a GPU pulls in every function of that physical device, because leaving one on a host driver makes the whole group non-viable. The right pane shows the detected CPU vendor and the exact kernel arguments it will add; the devices are bound to vfio-pci during early boot and written into the initramfs.
Hostname, firmware mode, the disks that will be erased with their stable identifiers, swap and ARC sizing, the target rootfs archive with its checksum, and every address — on one scrolling summary with the action bar pinned in place.
Nothing is written until you type the hostname back. It is the only screen in the installer that asks you to prove you meant it, and it names every disk it is about to erase while you do.
Staged progress with the current step, elapsed time, and the live execution log. Every command is written to a log file you can open from the installer itself, so a failed run leaves evidence rather than a blank screen.

Every value shown is sample data — the installer has a preview mode that disables host discovery so the interface can be demonstrated without touching hardware. Dry-run mode discovers the real machine and executes no installation commands, leaving target disks unchanged.
A general-purpose distribution hands you a kernel and wishes you luck. HosterOS assembles the virtualization, storage, networking, and host services into one tested image.
Versioned QEMU builds ship with each image; migration preflight enforces identical versions and a common CPU model.
The microVM path for container-shaped workloads — Docker and Podman guests that boot in seconds and cost far less than a full VM.
The whole OS sits on ZFS. Snapshots, rollback and replication are properties of the install, not something added later.
Distributed storage across the cluster, compiled in and staged. Its chunk dataset is created with recordsize=1M.
Installed and configured, left stopped until the node has a role. No scrape config to write by hand.
Host-side power metrics attributed to QEMU and Cloud Hypervisor processes; automatically skipped on virtualized hosts where RAPL is unavailable.
Exports disk-health metrics for dashboards and alerts, so a failing NVMe surfaces as a signal rather than a kernel log nobody reads.
A custom xcaddy build carrying the Cloudflare DNS module, so ACME DNS-01 works on a private network with no inbound port.
Runtime support for the cluster mesh, with nftables and netplan for host firewalling and addressing.
Address handout for the internal VM bridge, configured during install rather than bolted on.
Plus the unglamorous half: chrony, tuned, restic, smartmontools, nftables, netplan, ansible-core, btop and the ZFS initramfs and ZED units — installed, with host configuration prepared where applicable, so the first boot is a working host rather than a starting point.
The hypervisor stack is identical either way. Pick the distribution your team already knows how to operate at three in the morning — the installer absorbs the difference.
netplan · systemd-networkd NetworkManagerssh sshdchrony chronydkea-dhcp4-server kea-dhcp4cron crondUEFI or legacy BIOS UEFI onlyarchive.ubuntu.com dl.rockylinux.orgChoosing a distribution changes which service names and network backend the installer writes — not what you end up running. One caveat worth knowing up front: Rocky is installed UEFI-only, while Ubuntu will also take a legacy BIOS boot.
The installer is a terminal application on purpose. Anything that can reach the machine on a network can drive it.
The live ISO brings up networking, generates a one-time root credential, and starts SSH before it draws the first screen. The welcome screen prints the username, the password, and the exact ssh command for every address it found.
Log in from your laptop and run the installer there — no crash cart, no KVM window, no IPMI java applet. The credential lives in tmpfs and dies with the reboot, so there is nothing to clean up afterwards.
$ ssh root@192.0.2.20 HosterOS live environment — credential expires on reboot $ cd /opt/hosteros-installer && ./HosterOS ┌─ HosterOS Installer Step 1/14 Welcome ─┐ │ You can run this installer remotely │ │ over SSH. │
Fourteen screens are fine once. On the twentieth identical node they are a chore, and a chore is where mistakes come from.
The planned pre-seed takes the same answers as a JSON file: boot the ISO, log in over SSH, hand the installer a seed, and let it run unattended. Same validation, same review, same log — just nobody typing.
$ ./HosterOS --json-seed rack-a-node.json validating seed ... ✓ 14 answers resolved · no prompts installing edge-lon-07 ...
To be clear about what exists today: remote install over SSH ships and is on the welcome screen of every live boot. The JSON seed is on the roadmap and the flag shown above is illustrative — if you are planning a fleet rollout around it, talk to us first.
The datasets a hypervisor needs are not the datasets a file server needs. HosterOS creates them with the right properties on the way in.
Tell us about your fleet and we will come back to you.