Your infrastructure starts here.

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.

Built on QEMU / KVMCloud HypervisorOpenZFSWireGuardLeilFSPrometheusUbuntuRocky LinuxGo

Fourteen screens. Every destructive choice stays visible.

Captured from the installer itself in preview mode. Pick a screen to see it.

Nothing is erased by accident

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.

HosterOS installer — Disks 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.

Someone already made the boring decisions.

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.

Hypervisors

QEMU / KVM10.2.2

Versioned QEMU builds ship with each image; migration preflight enforces identical versions and a common CPU model.

Cloud Hypervisorv51.1

The microVM path for container-shaped workloads — Docker and Podman guests that boot in seconds and cost far less than a full VM.

Storage

OpenZFSon root

The whole OS sits on ZFS. Snapshots, rollback and replication are properties of the install, not something added later.

LeilFSv5.7.1

Distributed storage across the cluster, compiled in and staged. Its chunk dataset is created with recordsize=1M.

Observability

Prometheuspre-staged

Installed and configured, left stopped until the node has a role. No scrape config to write by hand.

Scaphandrepre-staged

Host-side power metrics attributed to QEMU and Cloud Hypervisor processes; automatically skipped on virtualized hosts where RAPL is unavailable.

smartctl exporterpre-staged

Exports disk-health metrics for dashboards and alerts, so a failing NVMe surfaces as a signal rather than a kernel log nobody reads.

Network & edge

Caddyv2.11.2

A custom xcaddy build carrying the Cloudflare DNS module, so ACME DNS-01 works on a private network with no inbound port.

WireGuardkernel

Runtime support for the cluster mesh, with nftables and netplan for host firewalling and addressing.

Kea DHCPv4

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.

Ubuntu or Rocky. Your call.

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.

the installer resolves Ubuntu 26.04 LTSresolute Rocky Linux 1010
Network stack netplan · systemd-networkd NetworkManager
SSH unit ssh sshd
Time sync chrony chronyd
DHCP unit kea-dhcp4-server kea-dhcp4
Scheduler cron crond
Firmware UEFI or legacy BIOS UEFI only
Default mirror archive.ubuntu.com dl.rockylinux.org
Identical on both QEMU / KVMCloud HypervisorOpenZFSLeilFSPrometheusWireGuard

Choosing 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.

You never have to stand in the datacentre.

The installer is a terminal application on purpose. Anything that can reach the machine on a network can drive it.

shipping

Install over SSH

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.

from your workstation
$ 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.                                │
planned — not yet shipping

Seed a whole rack from one file

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.

planned interface
$ ./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.

Tuned for the workload it was built to run.

The datasets a hypervisor needs are not the datasets a file server needs. HosterOS creates them with the right properties on the way in.

$ zfs list -o name,recordsize,compression,logbias,quota -r rpool set by the installerleft at default
rpool 128K lz4 latency none # set once at the pool — everything below inherits it
├─rpool/hoster 64K lz4 latency none # matched to guest I/O, not the 128K default — VMs and microVMs share the layout
└─rpool/leilfs 1M lz4 throughput 20% # chunk storage, shaped for streaming — capped so the cluster cannot eat the root pool
zfs_arc_max — sized to the machine at install the ceiling
64 GiB 6.4 GiB 57.6 GiB
128 GiB 12.8 GiB 115.2 GiB
512 GiB 51.2 GiB 460.8 GiB
# one tenth of RAM, never below 1500 MiB — written to /etc/modprobe.d/hosteros-zfs.conf
$ lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS swap
sda 1.8T
├─sda1 512M vfat /boot/efi
├─sda2 10G swap [SWAP]
├─sda3 3G zfs_member
└─sda4 1.8T zfs_member
sdb 1.8T
├─sdb1 512M vfat
├─sdb2 10G swap [SWAP]
├─sdb3 3G zfs_member
└─sdb4 1.8T zfs_member
# 10 GiB on every disk with discard on — two disks, two independent swap areas

Run Hoster on your hardware. Start with one server.