dstack: running containers in confidential VMs with verifiable attestation

The problem: trust does not scale, and trust cannot be checked

dstack is described as the open framework for confidential AI, for deploying AI applications with cryptographic privacy guarantees.

The argument in the README is short and direct. AI providers ask users to trust them with sensitive data, but trust does not scale, and trust cannot be verified. With dstack, your containers run inside confidential VMs on Intel TDX with native support for NVIDIA Confidential Computing on H100 and Blackwell hardware, and users can cryptographically verify exactly what is running.

That last clause is the whole point of the project, and it distinguishes it from a privacy policy. A policy is a promise; an attestation quote is a measurement. The promise of dstack is that a user does not have to take the operator's word for what code is executing, because the hardware produces a quote that anyone can check.

The platform table shows how widely the attestation story is expected to work. Bare metal TDX is available with TDX attestation, and bare metal AMD SEV-SNP has host support and requires an SNP-capable guest image with SEV-SNP attestation. Phala Cloud is available with TDX, GCP Confidential VMs are available with TDX plus TPM, and AWS Nitro Enclaves are available with NSM.

That list spans three different attestation mechanisms, which is the interesting part. TDX quotes, SEV-SNP attestation reports and the Nitro Security Module are different formats with different trust roots, and a framework that supports all three has to normalise them into one verification story.

The project is Apache-2.0 licensed, written in Rust, the default branch is next, the homepage is dstack.org, and the last push was on 2026-10-22. The releases include dstack v0.6.1 on 2026-10-13, v0.5.12 also on 2026-10-13, and a Verifier release v0.6.1. The original contributors are named as Hang Yin, Kevin Wang and Andrew Miller.

Zero friction onboarding, and what Docker Compose native actually means

The features are grouped into three headings, and the first is about how little you have to change.

Docker Compose native is the headline. You bring your docker-compose.yaml as-is, with no SDK and no code changes. The example in the README is exactly a Compose file:

# docker-compose.yaml
services:
  vllm:
    image: vllm/vllm-openai:latest
    runtime: nvidia
    command: --model Qwen/Qwen2.5-7B-Instruct
    ports:
      - "8000:8000"

There is no confidential-specific API in that file, which is the point. The security comes from where the container runs, not from how the workload is described, so an existing Compose file keeps working.

Encrypted by default is the other part of that group. Network traffic and disk storage are encrypted out of the box.

The second group is hardware-rooted security. Private by hardware means the data is encrypted in memory and inaccessible even to the host. Reproducible OS means deterministic builds, so anyone can verify the OS image hash. Workload identity means every app gets an attested identity that users can verify cryptographically. And confidential GPUs gives native support for NVIDIA Confidential Computing on H100 and Blackwell.

The third group is trustless operations, and it is the part that says the most about the threat model. Isolated keys are per-app keys derived in the TEE, which survive hardware failure and are never exposed to operators. Code governance means updates follow predefined rules such as multi-party approval, so operators cannot swap code or access secrets.

That last one is a design choice worth sitting with. Most confidential computing stacks protect the guest from the host, which is the harder problem. dstack additionally protects the guest from a dishonest operator, which is a different and arguably rarer threat. The price is that the operator genuinely cannot see your data or your keys, which means no convenient debugging and no backdoor access.

Four components, and why the KMS runs in its own enclave

The architecture section names four core components, and the division is the interesting part of the design.

The Guest Agent runs inside each confidential VM. It generates TDX attestation quotes so users can verify exactly what is running, it provisions per-app cryptographic keys from the KMS, it encrypts local storage, and apps interact with it over a Unix socket at /var/run/dstack.sock.

The KMS runs in its own TEE, and its responsibilities are the security core. It verifies TDX quotes before releasing keys, it enforces authorization policies defined in on-chain smart contracts so operators cannot bypass those checks, and it derives deterministic keys bound to each app's attested identity.

Separating the KMS from the guest is what makes the operator exclusion work. A key is released only when the quote from the guest verifies and the on-chain policy permits it, and the operator is in the middle of neither. The determinism matters too, because a key bound to an attested identity means the same app, attested the same way, derives the same key, and a different build does not.

The Gateway terminates TLS at the edge and provisions ACME certificates automatically, routes traffic to the confidential VMs, and all internal communication uses RA-TLS for mutual attestation.

The VMM runs on bare metal TDX hosts. It parses docker-compose files directly with no app changes needed, boots the confidential VMs from a reproducible OS image, and allocates CPU, memory and confidential GPU resources.

The division of the VMM is what makes the Compose-native claim work. Nothing in the user's file changes; the VMM reads it and turns it into confidential VM allocations, and the Gateway puts the TLS in front of the result.

Reproducible guest OS builds, and the repository layout

The repository layout is described with a short block that reads like an ownership map:

dstack/  Core services, Rust crates, host and guest runtime code
sdk/     Stable public SDK paths
os/      Guest-OS payload, image contract, and build backends
docs/    User and operator documentation
tools/   Standalone development and security tools

The os/ directory is the part with the interesting policy in it. The default and recommended OS backend is mkosi under os/mkosi/, and the Yocto backend under os/yocto/ is deprecated and kept only to rebuild existing images, with the instruction not to use it for new work. Shared rootfs payload and release assembly stay outside the backends so they are not duplicated, and there is an os/README.md covering the arrangement.

The scripts follow the same boundaries. Component-specific helpers stay beside their component under dstack/, files installed into every guest live in os/common/rootfs/, backend-neutral image tooling lives in os/image/, mkosi-only helpers live in os/mkosi/scripts/, and repository-wide standalone utilities live in tools/.

That is a lot of care for a directory structure, and the reason is the reproducibility claim. A deterministic build means anyone can verify the OS image hash, and you cannot have that if the payload is assembled differently depending on which backend you use. Keeping the shared payload outside the backends is what makes the hash comparable.

The Makefile makes the same split operational. The targets separate the Rust workspace from the OS build: core, core-check and core-test for the workspace, sdk-test for the public SDK, and os, os-image and os-repro-check for the guest OS. The help output describes os-image as building one production guest image with mkosi in the pinned container, and os-repro-check as building twice with mkosi and comparing outputs byte for byte. The deprecated Yocto targets are listed separately with a note not to use them for new work.

The core targets are thin wrappers over cargo, for example cargo build with the manifest path pointing at dstack/Cargo.toml, and the test target runs a script rather than a cargo subcommand, which suggests the tests need more than a unit test run. The Makefile also carries an explicit list of the eight Yocto dependency submodules it would initialise, all of which the mkosi path avoids entirely.

Security documentation, the audit, and how to report a problem

The security section is organised so that a deployer and a reviewer can find what they need quickly, and it is worth following the structure because it tells you what the project considers settled and what it does not.

The security overview is the entry point for users, operators, researchers and AI agents. The security model document is the threat model, the trust boundaries and a verification checklist. The public security reports file gives the public status for security reports and related hardening work, which is unusual to see in the open and suggests the project publishes its findings rather than only fixing them quietly.

Security best practices covers production settings and hardening guidance. The audit is a third-party audit PDF by zkSecurity, hosted in the repository. Vulnerabilities are reported through the private reporting path described in SECURITY.md, using GitHub's private security reporting, and the README asks explicitly that exploitable vulnerabilities are not disclosed in public issues.

The repository root backs this up with the expected files: SECURITY.md, CODE_OF_CONDUCT.md, CONTRIBUTING.md, CHANGELOG.md, a REUSE.toml for licence tracking, a LICENSES/ directory, a Makefile, a rust-toolchain.toml, and a technical charter PDF dated 2025-10-17, which is the kind of document that records the project's design intent at a point in time. There is also a CLAUDE.md and a .claude directory, a .cursorrules file and a .agent/ directory, which are the conventions for coding agents to work in the tree.

The top level also carries test-suites/, examples/ with a hello-nginx directory, and a prek.toml. The examples directory being separate from the core suggests the framework is validated by running things in it rather than only by unit tests.

Editorial conclusion

Adopt dstack if you are deploying an AI service where users will not send sensitive data to a provider they cannot check, and you have TDX hardware or a managed confidential platform to run it on. Do not adopt it as a general container runtime, because every image has to be a reproducible guest OS build and the deployment assumes a confidential VM host. Before you plan a deployment, read the security model document and the third-party audit, decide which attestation you will verify against, and note that the AMD SEV-SNP path needs a guest image that includes digest.txt, while development without TEE hardware is done with the no-TEE mode and swtpm.

Frequently asked questions

Official sources

1. Dstack-TEE/dstack on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases