aleph-vm 2.0: verifiable compute, a new engine, and production SEV-SNP

We are releasing aleph-vm 2.0, the largest release in the project’s history: a full architectural split of the node software, a new Rust virtual machine supervisor, first-class AMD SEV-SNP confidential computing, and an entirely new workload class, V-PROGRAM: programs whose exact code and runtime are cryptographically measured, remotely attested, and verifiable by anyone before a single byte is trusted.

aleph-vm is the software that powers Compute Resource Nodes (CRNs) on Aleph Cloud. If you run a CRN, 2.0 changes how your node is built from the inside out while keeping your workloads running through the upgrade. If you deploy on Aleph Cloud, 2.0 gives you something no mainstream cloud offers: compute you can verify instead of trust.

V-PROGRAMs: never trust a computer blindly again

V-PROGRAMs, short for Verifiable Programs, are the main feature of 2.0.

A V-PROGRAM runs inside an AMD SEV-SNP guest whose entire boot chain (firmware, kernel, init, runtime) is a reproducible, measured image. Your code ships as a separate integrity-protected volume (dm-verity), and its root hash is baked into the measured boot command line. The result is a single cryptographic measurement that pins down everything the VM will execute, published in the V-PROGRAM message itself.

Clients verify the integrity of the program using RA-TLS (Remote Attestation TLS), meaning the connection is certified to be bound to a live SEV-SNP VM attested by the AMD hardware root of trust. The aleph CLI verifies the full chain (AMD certificate chain and revocation status, report freshness, key binding, measurement match, and a network-wide TCB firmware floor) before it shows you a byte of response. If the node operator swapped the code, patched the runtime or downgraded the firmware, verification fails.

Two runtime flavors ship in 2.0:

• aleph.exec/1: run a single binary or service directly. Build your workload volume with the bundled tooling, publish, done.
• aleph.compose/1: run a full docker-compose application inside the measured guest. Point aleph vprogram create --compose at your compose file, and the images and configuration become part of the measured workload.

$ aleph vprogram create --compose docker-compose.yml
$ aleph vprogram call <item-hash> /health
# response delivered only after the attestation report verifies

A new engine: the split architecture and the Rust supervisor

Under the hood, 2.0 rebuilds most of what makes a CRN tick. aleph-vm is now two cooperating services with a strict contract between them:

• The Aleph agent (Python) faces the network: it processes Aleph messages, authenticates allocations, exposes the operator HTTP API, and decides what should run.
• The supervisor (a new daemon written in Rust) owns the machines: QEMU and Firecracker lifecycles, systemd units, tap devices and nftables, per-VM DHCP (including the SEV-SNP guests), NUMA placement, etc.

The two services communicate over a Unix socket via gRPC. This boundary separates concerns (Aleph-specific bits live in the agent; the supervisor focuses on the VM lifecycle and only that). This enables the following features:

• Fault isolation: a crash in message processing can no longer take a hypervisor down with it, and a VM that fails to launch produces a typed, specific error instead of a stack trace.
• alephctl: a new debug CLI that talks directly to the supervisor socket, giving operators a real diagnostic surface (VM lists, unit states, logs) independent of the HTTP API.
• Simplified testing and performance work: now that the supervisor lives in isolation, improving it is easier than ever.

Other features

Multi-disk volume pools

aleph-vm can now handle multiple NVMe drives / SSDs as VM storage. Operators can configure this feature by configuring multiple volume pools in their .env files.

Huge page support

aleph-vm can now allocate large memory pages (so-called “huge” pages) to VMs. This improves the performance of VMs with high memory pressure.

NUMA placement

aleph-vm can now handle machines with multiple processor sockets. VMs are pinned to a specific set of CPUs depending on availability and device requirements.

Security

Allocation authentication now runs exclusively on EIP-191 signatures from authorized scheduler keys, with replay protection; the legacy pre-shared-token path is gone.

Note that the VM connector Docker service is now marked as deprecated and is set for removal in aleph-vm 2.1. Users requiring this feature should move on to verifiable programs and use any Aleph SDK from within the program.

For node operators

The 2.0 .deb ships both services and migrates your node automatically. Key points:

• Running VMs are adopted when the new supervisor starts.
• Configuration stays in /etc/aleph-vm/supervisor.env; existing settings carry over.
• Confidential computing on SEV-SNP requires an SNP-capable host (AMD EPYC Milan or newer) with current firmware; snphost ok should pass before enabling it. The attestation flow depends on outbound access to AMD’s key distribution service (kdsintf.amd.com).
• The usual information about the release can be found in the release notes.

Compatibility notes

• Messages using the new measurement schema (per-platform register maps) require an up-to-date Core Channel Node (pyaleph 0.11.0) and aleph CLI (0.17); older CCNs will reject V-PROGRAM messages.
• The different SDKs support V-PROGRAM messages:
  • Rust: aleph-sdk >= 0.17.0
  • Python: aleph-sdk-python >= 2.4.0
  • TypeScript: aleph-sdk-ts >= 1.10.0

Try it

• Deploy a V-PROGRAM
• Configure multi-disk volume pools
• Enable huge page support
• Full changelog

aleph-vm 2.0 is the result of many months of work toward a simple idea: on a decentralized cloud, “trust me” isn’t good enough. Now you don’t have to.