Rust hypervisor management plane
Architecture
Basalt is a three-component HCI control plane: gateway, agent, image-service, and one Postgres database. The platform is built around manifest-driven reconciliation so hosts converge on desired state after reboots, partial failures, and ordinary drift.
The Three-Component Model
Basalt’s entire management plane is three static Rust binaries plus Postgres. There is no separate controller for compute, network, storage, image import, task scheduling, or API mediation.
Gateway
The gateway exposes the REST API on :9443 and :9444, persists
state in Postgres, projects host manifests, owns the task queue, and includes the MCP
server. It is the transactional brain of the platform, not a thin proxy to a second control
system.
Agent
The agent is a per-host worker that polls the gateway, receives the desired-state manifest for that host, and reconciles libvirt, OVS, Ceph, and DRBD locally. It turns centralized intent into host-local convergence.
Image Service
The image-service is the blob store for installation media and platform artifacts. It supports chunked-resume uploads, HMAC-scoped transfer tokens, and a durable callback spool so image workflows survive transient gateway outages.
Single Data Store
Basalt uses one Postgres instance as the system of record. It is not etcd + MySQL + Redis + a message queue; it is roughly 100 tables operating inside one consistent transactional model.
Row-Level Security is applied at every business table, which means tenant boundaries are part of the database engine rather than an application-side convention. That same Postgres model backs tasks, manifests, permissions, leases, inventory, and audit-relevant state.
The security implications of this choice are covered in how Postgres Row-Level Security enforces tenant isolation.
Manifest-Driven Reconciliation
The gateway continuously computes per-host desired state. Eligibility predicates decide which virtual machines, networks, volumes, cluster services, and leases are projected into each host’s manifest.
Converge, do not script
Agents poll for their manifests, compare desired state with local libvirt, OVS, Ceph, and DRBD reality, then converge the host. Reboots and gateway interruptions do not require an imperative playbook to be replayed; the next manifest poll re-establishes the contract.
This same reconciliation loop drives VM lifecycle management through the agent, OVS-native SDN without a separate controller, and Ceph orchestration through the same control plane.
Operational Footprint
A conventional VMware-style stack often means vCenter + ESXi + NSX-T + vSAN + vRealize + Aria, each with separate lifecycle, data stores, and operational assumptions. Basalt’s footprint is three static Rust binaries and one Postgres.
The gateway is designed for an approximately 512MB memory footprint, with the agent doing host-local work and the image-service owning durable blob movement. The result is a compact management plane for hyperconverged infrastructure rather than an enterprise suite assembled from many independently operated products.