Why Hoster

Most virtualisation platforms ask you to assemble them. You pick a hypervisor, bolt on storage, wire up networking, add a scheduler for backups, add monitoring, add a DNS story, and then keep all of it in step as the estate grows. Hoster ships that whole path as one system, with defaults that are meant to be left alone — and it does it without putting a control plane in the data path.

Deployment speed is the feature

A new VM is a ZFS clone of a template dataset, not a copy. Nothing is streamed, nothing is unpacked, and the time to deploy does not grow with disk size:

hoster vm deploy --os-template ubuntu2404 --name grafanaStaging

That returns in sub-second time, and starting the machine afterwards is a matter of milliseconds. This is the difference that changes how you work. When a VM costs a second, you stop treating machines as pets you keep alive and start treating them as something you re-create on demand — for a test, for a branch, for a customer.

Templates are ordinary ZFS datasets named template-<name> holding a raw disk0.img, so making your own is a zfs create and a file copy. Anything after template- becomes the name you pass to --os-template — see Building your own template.

ZFS is a first-class citizen, not a storage option

Every guest lives on its own ZFS dataset. That is not an implementation detail — it is what the rest of the platform is built out of:

• Snapshots are instant and cost only the blocks that changed, so scheduled snapshots every hour are unremarkable rather than an operational event.
• Cloning is what makes deployment sub-second.
• Replication uses incremental zfs send, so sending a machine to another host moves the delta rather than the disk.
• Integrity is checksummed end to end, which is the reason a snapshot you took three months ago is worth having.

The installer treats it as a first-class citizen too: you choose the pool topology and the ARC limit before the system is written, rather than retrofitting a pool onto a running box. See HosterOS installation.

MicroVMs for container workloads

Containers share a kernel. That is fine until it is not — and “not” usually means a tenant boundary, an untrusted image, or a compliance question you would rather answer with a hard edge than with a namespace.

Hoster runs Docker and Podman workloads inside microVMs on Cloud Hypervisor: a real virtual machine with its own kernel, booting in a fraction of the time a full QEMU guest takes. You get container ergonomics — a compose.yaml, a /data share — with virtual-machine isolation underneath.

Classic QEMU guests and microVMs are managed the same way, through the same CLI and the same UI. Choosing between them is a workload decision, not a second platform to learn.

Shared-nothing: every host runs its own stack

This is the architectural decision everything else follows from.

Each server runs an agent (hoster_agent) that owns the machines on that server: it manages guests, takes snapshots, runs replication, and exposes a local API and a CLI. It does not ask permission from anything. There is no central scheduler handing out work, and no shared database that has to be reachable for your VMs to keep running.

The practical consequences:

• The control plane is not in the data path. If Control Center is switched off, unreachable, or being upgraded, every host carries on exactly as before.
• A failed host is a failed host, not a degraded cluster. Its neighbours do not slow down or lose quorum over it.
• You can start with one machine and add the rest later, because a single host was never a special case — it is the normal case with a cluster of one.

When you do form a cluster, the hosts coordinate through rqlite for shared state, and each host dials out to Control Center over mutual TLS rather than being dialled into. Commands travel back down the connection the host already opened, so nothing has to reach into a host’s network to manage it.

An interface built for operators

Control Center is a web UI over the same agents the CLI talks to. It is optional, and it is not a wrapper that hides what is underneath — it shows fleet state, per-host detail, guest lifecycle, snapshot history with retention, the scheduler, cluster membership, monitoring and an audit log, at the level of detail an operator actually needs to answer a question.

Everything it does is available from hoster on the host. Neither one is the second-class path.

It runs as a microVM on a node you already have — see Deploying Control Center, and The interface for what each page shows.

The scheduler does the boring part

Snapshots that only run when someone remembers are not backups. Every agent embeds a scheduler that runs on ordinary cron syntax and exposes each job’s next run and last result:

• snapshot jobs, with retention
• replication to another host, incremental
• disaster-recovery sync
• template distribution — in a cluster, image templates fan out to every node hourly, so a node is never missing the template you are about to deploy from

A new node ships with none of these configured, deliberately: see Snapshots, replication and the scheduler for the schedule to give it.

All-in-one, and still modular

The things you would otherwise integrate yourself are included, and they are aware of each other:

Modular in the sense that matters: each piece is a component you can run, replace or leave switched off. Clustering is optional. Control Center is optional. The mesh only exists if you have more than one host. Nothing is load-bearing for a single server except the agent itself.

What fits where

A single host is not a trial mode. It is the same software, doing the same things, without the parts that only mean something once there is a second machine.

Next

Quick start walks the whole path — hardware to first VM — at a bird’s-eye level, and explains where Control Center and clustering earn their place.