Introducing Basalt

This first post lays out why Basalt exists: to make infrastructure smaller, more explicit, and ready for operators and automation to share the same source of truth.

Why rebuild infrastructure

Enterprise infrastructure has spent more than a decade living inside choices made for another era. VMware made virtualization operationally accessible, and OpenStack proved that open infrastructure could be assembled from shared services. Both changed the industry. But the platforms that grew from that period also accumulated layers of assumptions: long-lived controllers, plugin surfaces designed before supply-chain pressure was constant, and management planes that often require a second platform just to operate the first one.

Basalt started with a different question: what should hyperconverged infrastructure look like if it were built today, with modern primitives as the default rather than the retrofit? That question led us away from cloning an existing stack and toward a smaller, more explicit management plane. The goal is not novelty for its own sake. The goal is to reduce the number of moving parts an operator must trust, patch, and reason about during an incident.

The Rust decision

The Rust decision followed from that goal. It was not an aesthetic preference or a recruiting slogan. Rust gives us memory safety without a garbage collector, predictable resource behavior for long-running infrastructure processes, and static binaries that are easier to ship into constrained or regulated environments. Cryptography and compliance matter too: using aws-lc-rs gives Basalt a path to FIPS 140-3 aligned primitives without wrapping critical code in a separate language boundary.

Three components, one database

That philosophy shows up in the control plane shape. Basalt is three components: the gateway, the agent, and the image-service. The gateway owns the API surface and orchestration contract. The agent runs on infrastructure nodes and applies work locally. The image-service handles image ingestion, preparation, and distribution. One Postgres database stores the management state. That is the management plane. There is no hidden constellation of controllers required before an operator can understand what is happening. For a deeper breakdown, see how the three-component model works.

Intelligence-native direction

This smaller shape is what lets us take the next step: infrastructure that can be reasoned about by software, not just clicked through by humans. The Model Context Protocol integration is part of that direction. Instead of treating AI as a chatbot pasted on top of dashboards, Basalt exposes capabilities with explicit context, constraints, and authorization boundaries. Agents can inspect available actions, understand operational state, and propose or execute changes according to policy.

That is what we mean by intelligence-native infrastructure. The platform still has to be boring where it counts: deterministic operations, auditable state changes, and clear failure modes. But the interface to that platform can become more capable. Basalt is being built so operators, automation, and AI systems all work from the same source of truth. Learn more about the intelligence-native direction.