The interface
A tour of what each Control Center page shows and when you would reach for it — and what the equivalent looks like on the CLI, because everything here is available both ways.
Control Center is a web interface over the same agents the CLI talks to. It is not a
wrapper that hides what is underneath, and it is not the privileged path — everything
here has a hoster command behind it, and neither one is second-class.
This page is a tour: what each surface shows, and when it beats typing.
If you have not stood one up yet, start with Deploying Control Center.
Dashboard
The whole estate on one screen: totals across the fleet — hosts, allocated vCPU, memory, pool capacity and snapshot space — over tables listing every host, VM, microVM and backup. A problems view collects everything currently wrong.
This is the page you leave open. It answers “is anything on fire” and “is there room for this” without a query.
Take a screenshot of the Control Center dashboard with several hosts connected, showing the fleet totals, the capacity bars and at least one warning so the problems view is visible.
On the CLI: hoster host info, hoster cluster get hosts, hoster cluster get vms.
Hosts
Fleet state, then one machine in detail: hardware, storage pools, network addresses, running guests, and the actions available on that host. Per-host CPU, RAM, power draw, pool usage and uptime, with platform and pending-reboot state.
Where the dashboard tells you something is wrong, this is where you find out which machine and why.
Take a screenshot of the host detail page for a single node — hardware, pools, addresses and its guest list together, which is the densest and most characteristic view in the product.
On the CLI: hoster host info, hoster host resources, hoster host zfs,
hoster host metrics.
Machines
VMs and microVMs share one operating model: list, inspect, power, snapshot, clone, replicate and monitor, without learning a second interface. Guest configuration is Cloud-Init; placement and power controls are here.
The parity is the point — a microVM is a workload decision, not a separate product with its own page.
Take a screenshot of the machines list showing VMs and microVMs together, with their host, vCPU, memory and state columns.
On the CLI: hoster vm list|info|start|stop, hoster microvm list|status|start|stop
— see Your first VM and
MicroVMs.
Snapshots
Local and remote ZFS snapshots presented as one history, with size, parentage, retention, replication state and restore actions kept together. Clone or roll back from here.
Reading a retention ladder is much easier here than on a terminal: the shape of “fifteen frequent, twenty-four hourly, seven daily” is visual.
Take a screenshot of the snapshots page for one guest, showing several retention types together with their sizes and ages.
On the CLI: hoster vm snapshot list|create, hoster vm clone — and
Snapshots, replication and the scheduler for
putting them on a timer.
Scheduler
Snapshot, replication, disaster-recovery and template jobs per host. Every job uses ordinary cron syntax and shows its next run and its last result.
This is the page that turns “I think backups are running” into “backups ran at 14:00 and took nine seconds”.
Take a screenshot of the scheduler page with snapshot and replication jobs listed, their cron schedules, next run times and last results.
On the CLI: hoster scheduler schedule|jobs|stats, and hoster scheduler debug run
to fire one immediately.
Cluster
Membership, leader state, leases, shared secrets and metadata master failover — without hiding the distributed-system boundaries. Quorum is shown as quorum, not as a green tick.
Take a screenshot of the cluster page showing member hosts, their roles, term and state on a healthy three-node cluster.
On the CLI: hoster cluster status, hoster cluster get nodes|latency — see
Clustering.
Monitoring
Prometheus data rendered where operators use it: resource charts, selectable time ranges, query resolution, and links back to the affected host or guest. The collection is autodiscovered — creating, moving or removing a guest updates the scrape configuration without anyone editing it.
Take a screenshot of the monitoring page with a few hours of host and guest metrics and the range selector visible.
On the CLI: hoster host metrics, hoster vm metrics.
WebProxy
Published services and their routes, in one place, rather than distributed across host configuration files.
Take a screenshot of the WebProxy page listing published routes.
Audit log
Every state-changing action, login and denied authorisation attempt, with user, resource, response status and source address. Filterable by user, action and group.
This is the reason a shared interface exists at all. A terminal has no audit log and no roles: if someone needs to restart a machine without also being able to destroy a pool, that distinction has to live somewhere, and this is where.
Take a screenshot of the audit log showing a mix of actions — a successful state change, a login, and a denied attempt.
Why both paths exist
The CLI is the one that works when the interface does not: on the console of a machine whose network is broken, over SSH from a phone, inside a script. Control Center is the one that answers questions across many machines at once, and the one you can give to someone without giving them root.
Neither is a fallback for the other. Control Center being down does not stop a node running its guests — see Why Hoster.
Next
- Deploying Control Center — standing it up and enrolling nodes.
- Clustering — what the cluster page is showing you.
Something unclear on this page?
Ask about this specific page and we will come back to you. Your question arrives with a link to it, so you do not have to describe where you were.