A Focused Platform Design

One source of truth

The central management plane serves the portal and API, authenticates users and automation, coordinates operations, and owns the shared data store. Basalt does not split infrastructure truth across separate stores for scheduling, virtual machines, networks, and workflows. Tenants, projects, hosts, virtual machines, networks, storage pools, software references, migrations, audit events, and long-running tasks all use the same source of truth.

This is an operational constraint chosen on purpose. Many infrastructure failures begin as disagreement between services: scheduling says a virtual machine moved, networking retains an old connection, storage reports an unfinished attachment, and the interface shows whichever answer arrived last. Basalt reduces that risk by recording state changes durably in one place and having host operations work back toward that recorded intent.

Long-running work still exists. Creating a virtual machine, importing software, or migrating a workload cannot be completed as one immediate data update. Basalt records these operations as durable tasks with progress that operators can inspect, retry, and audit. Task state remains alongside the resources being changed rather than living in a separate workflow system with another version of the truth.

Hosts converge on intended state

Each host runs lightweight Basalt software with the local privileges needed to manage virtualization, networking, storage, and the runtime facts only that machine can observe. It does not depend on a fragile sequence of commands that must all finish in the expected order.

Instead, the control plane sends a description of what should exist. The host compares that intent with local reality and applies the changes needed to close the gap. It can restart a stopped virtual machine, recreate a missing network connection, or continue toward the intended result after a host restart. Recovery uses the same durable intent as normal operation instead of relying on an in-memory procedure that may have been interrupted.

This approach optimizes for real operating conditions: hosts reboot, local commands fail, storage becomes temporarily unavailable, and network state drifts. Basalt repeatedly observes, compares, and converges until reality matches intent. The recovery mechanism is the normal mechanism, not a separate disaster path.

Migration recovery is a concrete example. Moving a live workload touches two hosts, virtualization state, storage assumptions, and control-plane records. After a timeout, Basalt can compare durable migration state with what both hosts actually report, detect that progress stopped, and recover toward the intended outcome. Operators do not have to inspect several service logs and decide which partial result should win.

Software delivery has its own boundary

Software images behave differently from ordinary control-plane records. They are large, transferred in chunks, retried across unreliable networks, and often moved between machines that should not receive broad access to management data. Basalt therefore gives transfers a narrowly scoped path with its own storage and authorization.

Large uploads can resume after an interruption instead of restarting from byte zero. Single-use, signed tokens authorize a specific transfer without granting general access. Completion notices are recorded durably and retried with increasing delays, so a temporary control-plane outage does not strand an otherwise successful upload.

This boundary exists because the failure profile is different. Large transfers need resumability, narrow token scope, and durable local storage. Control-plane requests need tenant context, permission checks, audit events, and consistent records. Host operations need local privileges to manage virtualization state. Keeping those concerns separate protects their security boundaries without splitting the platform into a web of independently coordinated services.

Why not split everything apart?

Independently deployed services are useful when separate teams own unrelated areas with very different demand. They are less useful for an infrastructure control plane where most operations are coordinated state changes over the same resources.

Creating a virtual machine involves identity, quota, project membership, software metadata, network selection, storage placement, task progress, audit logging, and host capabilities. Splitting every concern into a separately deployed service either duplicates records or adds a chain of calls to each operation. The platform then has to manage partial failures, repeated requests, version drift, and debugging across many traces. The user asked for a virtual machine; the operator inherits a coordination problem.

Basalt keeps the unavoidable boundaries and removes optional ones. The central management plane can make placement decisions with a complete view of inventory and intended outcomes. Hosts report what they can run and apply those decisions locally. The software-delivery path moves large files without gaining broad control-plane access.

The operational result is a small, stable surface to deploy, monitor, secure, and upgrade. There is one shared data store to back up and one schema to update. Failure domains remain explicit: central management and data, local host operations, and large-file transfer. Operators can reason about the system without first drawing a large service map.

This does not make the underlying work simple. Basalt still manages virtualization lifecycle, network and storage state, live migration, tenant isolation, permissions, software movement, durable tasks, and auditability. The design choice is to place that complexity behind stable responsibilities instead of scattering it across many internal APIs.

A control plane should be predictable when nothing is wrong and understandable when something is. Basalt's focused design is built around that requirement.