Basalt: one virtualization platform, from the edge to the enterprise

Built on KVM and Rust

Basalt is a Type 1, bare-metal virtualization platform built on KVM, the open-source hypervisor technology built directly into the Linux kernel, and implemented primarily in Rust, a memory-safe systems language. That combination gives Basalt a mature, widely deployed virtualization core with a control and security layer engineered from the ground up to eliminate entire categories of the memory-corruption vulnerabilities that have historically plagued privileged infrastructure software.

The idea behind Basalt is simple to state and hard for most platforms to deliver: one platform, one control plane, from the edge to the enterprise. The same hypervisor, the same virtual machine format, the same role-based access model, the same audit trail, and the same licensing framework extend from a single laptop to a two-node field kit to a regional data center to a globally distributed enterprise footprint. Nothing has to be re-architected, re-licensed, or re-learned as an organization grows.

Platform Overview

At its core, Basalt is an infrastructure control plane for compute, storage, and networking. It manages KVM-based virtual machines, clustered and replicated storage, software-defined networking, host lifecycle, workload placement, and high availability — all through a single management architecture rather than a patchwork of point tools bolted onto a hypervisor.

Every Basalt host runs one lightweight software agent. That agent enforces policy locally, keeps a full local copy of the state it's responsible for, and communicates with a central control plane using the same APIs, identity model, and audit framework regardless of whether that host is a single endpoint, a two-node edge cluster, or one node in a large regional resource pool. Administrators see one system, not a different console for every deployment size.

This architecture matters because most organizations don't have one kind of infrastructure problem — they have several, at different scales, with different constraints, and they've historically needed different products, different consoles, and different teams to manage each one. Basalt collapses that into a single platform that flexes to the environment instead of forcing every environment into the same shape.

Built for Disconnected and Constrained Environments

Most enterprise virtualization platforms assume a reliable, always-on connection between managed infrastructure and the systems that manage it. That assumption breaks down at the edge — on a laptop that goes offline for days, in a facility with intermittent bandwidth, or behind a firewall that was never designed to accept inbound management traffic. Basalt was built assuming the network will fail, because for a meaningful share of real deployments, that's the normal operating condition, not the exception.

Every Basalt agent keeps a complete local copy of the state it needs to keep running: its workloads, its network configuration, and its security policy. If a host loses its connection to the central control plane, nothing stops. Running virtual machines keep running. Locally enforced network and security policy stays enforced. If the host itself reboots while disconnected, it rebuilds its own configuration from that local state without waiting for a management system that may not be reachable.

What Basalt does deliberately restrict is new activation while disconnected and unauthenticated — a workload doesn't get to spin up on two separated halves of a partitioned environment at once. That distinction between continuing to run and quietly diverging is a safety boundary, not a limitation: it protects against split-brain conditions where two disconnected systems each believe they're authoritative.

When connectivity returns, the agent reauthenticates, reports what actually happened while it was offline, and reconciles against centrally defined policy — automatically, without manual re-enrollment or a rebuild. Only what changed gets resynchronized, which matters when bandwidth is thin.

Underpinning all of this is a deliberate architectural choice: Basalt agents call out to the control plane on their own schedule. The control plane never opens a connection into the infrastructure it manages. That means no managed host needs an open inbound firewall port or a listening management service exposed to the network — a materially smaller attack surface than platforms that require dialing in to every managed site. It also means a Basalt control plane can be hosted anywhere — on-premises, in a cloud region, or at a regional hub — and a single instance can manage a laptop, an edge cluster, and a data center simultaneously, without new management infrastructure standing up every time another site comes online.

Resilient by Design

Constrained sites don't get a pass on availability just because they're small. Basalt provides restart-class high availability that scales down to a minimal physical footprint without requiring an external storage array or a third witness node.

A representative compact configuration is a two-node cluster with synchronous storage replication between the nodes. If one node fails, Basalt detects the failure, establishes fencing to ensure the failed node is truly down before anything moves, and restarts the affected workloads on the surviving node. This is restart-class availability — a workload restarts elsewhere rather than continuing in lockstep — but it delivers meaningful resilience in a footprint that would otherwise require a dedicated storage array and a third arbitration node.

As requirements grow, the same platform grows with them. Small two-node deployments can scale into larger clusters with distributed, software-defined storage that pools capacity and resilience across many nodes rather than pairs. Organizations aren't forced to choose a storage architecture up front and live with it forever — Basalt supports multiple storage backends, so a constrained site can run a compact configuration today and expand into distributed storage later without changing platforms.

The throughline across every scale is the same reconciliation architecture: failure detection, controlled recovery, and desired-state reconciliation apply whether a site has two nodes or two hundred.

Enterprise-Grade at Scale

At the data-center and regional-hub scale, the challenge shifts from "does this survive disconnection" to "does this let us actually consolidate." Server sprawl — dozens or hundreds of underutilized machines, each running a handful of workloads because nobody trusted density — is expensive to power, cool, patch, and secure. Basalt is built to make consolidation safe.

Basalt combines compute, storage, and networking on the same physical infrastructure in a hyperconverged architecture, so additional capacity means adding nodes to a shared resource pool rather than standing up separate storage and compute silos that each need their own management, patching, and accreditation.

An intelligent scheduler evaluates capacity, CPU and memory headroom, and workload distribution to decide where new work should land, rather than leaving administrators to place every virtual machine by hand. The same engine plans host evacuations — bin-packing running workloads onto available capacity when a machine needs to be emptied for maintenance — and can recommend rebalancing as the cluster's workload distribution shifts over time.

Live migration moves a running virtual machine to another host without dropping it, after checking that the destination has the processor features, capacity, and storage path to receive it safely. Hosts drain automatically ahead of scheduled maintenance, so planned downtime doesn't mean planned outages for the workloads that host was running.

For unplanned failures, Basalt layers failure detection, fencing, and admission control to determine when it's actually safe to restart a workload elsewhere — and it quarantines a host that comes back online until its state has been reconciled, so a returning node can't cause a duplicate activation or a storage conflict. This is restart-class high availability: workloads recover automatically, but Basalt is direct about the fact that this is not lockstep fault tolerance or a substitute for backup and disaster recovery — those are different problems with different tools.

The result is that dense, consolidated infrastructure can be operated with the same confidence as the sprawling estate it's replacing, without needing a bigger team to babysit it.

Global Control, Regional Independence

Enterprises with infrastructure in many locations run into a scaling problem that has nothing to do with compute capacity: how do you get consolidated visibility across every site without making every site dependent on a central system that might go down or become unreachable?

Basalt answers this by separating enterprise coordination from regional execution. A single Global Controller maintains a registry of every managed region and routes authorized administrative requests to the right place using scoped, short-lived credentials. Each region, meanwhile, keeps its own full set of virtualization, storage, networking, security, and high-availability capabilities and runs them independently — locally, without needing to reach the Global Controller to keep operating.

Adding a new region is primarily a registration and coordination step, not a re-platforming project. It joins the same enterprise management architecture while retaining its own local execution, security enforcement, and administration. This separates two scaling problems that tend to get conflated: growing the capacity of a given site is a matter of adding compute and storage to that region's resource pool, while growing geographic footprint is a matter of adding more independently operable regions to the Global Controller. Neither one stretches a single failure domain across the whole organization.

If a region loses its connection to the Global Controller, its workloads keep running and its administrators can keep managing it locally. The Global Controller continues managing every region it can still reach and explicitly flags the ones it can't — so a connectivity problem shows up as a clearly labeled gap in visibility, not a silent blind spot or a false "everything is fine." When the connection comes back, that region rejoins the consolidated view automatically.

The practical outcome is one place to see the whole footprint — inventory, workload status, and audit history across every connected site — without making that single pane of glass a single point of operational failure.

Security and Governance Built In

Security in Basalt isn't a separately licensed module layered on top of the platform — it's part of how the platform is built.

Access is controlled and role-based. Basalt separates administrative and operational responsibilities through role-based access control, so the same person who makes a change isn't also the only one who can review it. Administrative duties are split across defined roles, which keeps day-to-day operations and sensitive actions appropriately separated.

Every consequential action is logged. Platform-changing activity — who did what, to which resource, from where, and when — is written to a permanent, structured audit record. That level of detail is what lets a security team reconstruct exactly what happened during an incident, or demonstrate operational discipline during a review, without relying on a paper trail maintained outside the system.

Communications are encrypted and cryptography is FIPS-enabled. Basalt uses signed credentials for authentication and agent identity, encrypts communications between agents and the control plane, and incorporates FIPS-enabled cryptographic capabilities as part of its security architecture.

Network policy is enforced beneath the workload, not inside it. Basalt's firewall runs inside the virtualization layer itself, applying per-workload security policy before a virtual machine ever sends its first packet — rather than depending on a setting inside the guest operating system that a user or an attacker could disable. That policy travels with the workload and doesn't depend on reaching the management plane to stay in force.

The platform is built with hardened security baselines in mind. Basalt's underlying host layer is designed to be hardenable and aligned with recognized security configuration baselines, and its architecture is built around the kinds of control mapping, audit evidence, and session-management discipline that formal security authorization processes require. Organizations pursuing a formal accreditation or authorization for their environment can use this alignment as a foundation for that process — Basalt is built to support that work, though the relevant authorizing body remains responsible for granting any formal authorization.

Software supply chain transparency is standard, not exceptional. Every Basalt release is accompanied by a software bill of materials — a complete, machine-readable inventory of the components that make up the product — generated using standard, industry-recognized tooling. Dependencies are vetted and locked into a controlled build process ahead of time, which also means Basalt can be built without an internet connection, an important property for organizations that need to validate and deploy software in air-gapped or tightly controlled environments. This is paired with an ongoing program to track the origin and maintenance of the platform's lowest-level components, consistent with recognized supply-chain risk management practices.

Basalt's foundation in a memory-safe language reinforces all of this. Because Rust structurally rules out entire categories of memory-corruption bugs — the kind of vulnerability class responsible for a large share of serious hypervisor security disclosures industry-wide — that protection exists by construction, not because of a policy someone has to remember to enforce.

We're precise about what this means and doesn't mean. Alignment with a hardened security baseline is not the same as a completed, published implementation guide for this specific product. A platform built with strong cryptographic and audit foundations is not the same as an active authorization to operate on a specific network. Basalt is designed to make those processes achievable — and we work directly with customers and their security teams to support the evidence and control mapping those processes require — but the relevant government or enterprise authorizing authority is always the one that grants them. The full posture is documented on the Security & Trust page.

Open, Flexible Adoption

Replacing a virtualization platform across an entire organization at once is rarely realistic, and treating it as a prerequisite for improvement stalls projects before they start. Basalt is built to be adopted incrementally, alongside whatever an organization is already running.

Basalt uses an open, KVM-based virtual machine format rather than a proprietary one. A workload built and tested on a Basalt-managed laptop uses the same format as a workload running in a Basalt-managed data center — no conversion step, no re-testing, and no rebuild required when it moves between environments. And because KVM is an open standard that no single vendor controls, workloads running on Basalt aren't locked into Basalt specifically; they remain portable to other KVM-based platforms an organization might choose later.

That same openness extends to how Basalt fits alongside existing infrastructure. Basalt and an organization's incumbent virtualization platform can run side by side, region by region or site by site, so a transition — where one is wanted — can happen in controlled waves rather than a single high-risk cutover. Each wave can be evaluated, piloted, and accepted on its own before the next one begins, and an organization can choose to introduce Basalt only where it makes sense operationally or economically, while incumbent infrastructure continues to run everywhere else.

Licensing follows the same philosophy. Rather than charging based on how many processors, cores, or sockets a deployment happens to run — a model that can quietly penalize an organization for consolidating servers onto fewer, more capable machines — Basalt's licensing is scoped to the deployment itself. That means adding capacity, replacing aging hardware with denser systems, or expanding a storage cluster doesn't automatically trigger a licensing increase for doing the efficient thing.

Taken together, this means adopting Basalt is a decision an organization can make in stages, at its own pace, without a forced all-or-nothing migration and without new infrastructure costs working against the very consolidation and modernization goals that motivated the change in the first place. The licensing and adoption page covers the commercial model in detail.

The Platform, End to End

Basalt is one answer to a problem that's usually solved with several different products stitched together: a hypervisor for the data center, a separate tool for the edge, a separate story for endpoints, and a separate console to tie it all together at the enterprise level. By building disconnected operation, resilient clustering, enterprise-scale orchestration, global visibility, and security governance into a single control plane from the start, Basalt lets IT and security teams manage a genuinely diverse infrastructure footprint as one coherent system — not a collection of exceptions.

That's the core proposition: whether the workload in question is running on a single laptop or across a distributed enterprise footprint, it's running on the same platform, governed by the same policy, and visible through the same audit trail.