dstack turns a Docker Compose app into a verifiable Confidential VM deployment.

It is useful when a service must prove more than "it runs in a TEE." dstack binds the application config, guest OS image, KMS key release, and hardware evidence into one identity that users or auditors can verify.

docker-compose.yaml
  -> app-compose.json
  -> compose-hash
  -> RTMR3 measurement
  -> attestation quote
  -> KMS key release / verifier decision

The main use case is private AI inference: run an OpenAI-compatible endpoint in a TEE, keep prompts and credentials protected from operators, and give customers proof of the workload that handled their request.

Most confidential-computing tools solve one layer: VM isolation, attestation, secret release, or a fixed inference appliance. dstack connects those layers into an application stack.

Best fit: private inference endpoints, confidential AI agents, and verifiable backends where the proof must cover app config, keys, endpoint, and hardware.

Start with an OpenAI-compatible model server:

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

Production shape:

1. Pin container images by digest.
2. Generate app-compose.json; its compose-hash becomes the workload identity.
3. Put model credentials, API keys, TLS material, and signing keys behind KMS-gated release.
4. Run the service in a TDX CVM, with NVIDIA confidential GPU evidence when GPU inference is used.
5. Expose the endpoint through the gateway or your own TLS path.
6. Let customers verify quote signature, TCB status, OS image hash, RTMR3 replay, compose-hash, KMS binding, and GPU evidence.

This is the difference between a private endpoint and a response tied to a measured workload with app-bound keys.

flowchart TB
    Dev["Developer<br/>docker-compose.yaml"] --> Compose["app-compose.json<br/>compose-hash"]
    Compose --> VMM["dstack-vmm<br/>CVM lifecycle + resources"]

    subgraph Host["TDX host / cloud TEE node"]
        VMM
        subgraph CVM["App CVM"]
            Agent["dstack-guest-agent<br/>RTMR3 events + Docker startup"]
            App["App containers<br/>vLLM / agent / backend"]
            Socket["/var/run/dstack.sock"]
            Agent <--> Socket
            App <--> Socket
        end
    end

    VMM --> Agent
    Agent -->|"quote + app identity"| KMS["dstack-kms<br/>TEE key release"]
    KMS --> Auth["auth-simple / on-chain policy"]
    KMS -->|"app-bound keys"| Agent

    User["User / client"] --> Gateway["dstack-gateway<br/>TLS + routing"]
    Gateway -->|"RA-TLS / WireGuard"| Agent

    Agent --> Evidence["Evidence<br/>TDX quote + RTMR3 log<br/>OS image hash + GPU evidence"]
    Evidence --> Verifier["Verifier<br/>policy decision"]
    Verifier --> User

Source areas: vmm/, guest-agent/, kms/, gateway/, dstack-attest/, ra-tls/, verifier/, and sdk/.

• app-compose.json: normalized deployment config derived from Docker Compose.
• compose-hash: SHA256 of app-compose.json, measured into RTMR3.
• RTMR3 event log replay: verifier recomputes runtime measurements and compares them with the hardware-signed quote.
• KMS-gated key release: app-bound keys are derived only after quote and policy verification.
• RA-TLS: attestation material is embedded in X.509 extensions under the 1.3.6.1.4.1.62397.1.* OID arc.
• GPU confidential computing: supported NVIDIA H100, H200, and Blackwell deployments can include confidential GPU evidence.

Try a live private AI deployment at chat.redpill.ai and open the shield icon to inspect attestation evidence.

Applications talk to the guest agent over HTTP on /var/run/dstack.sock.

A relying party should be able to check:

• quote signature and TCB status;
• approved OS image hash and expected MRTD / RTMR0-2 measurements;
• RTMR3 replay, including compose-hash, app-id, instance-id, and key-provider binding;
• KMS identity and policy decision;
• NVIDIA confidential GPU evidence for GPU workloads.

Tools and docs:

• dstack verifier
• Verification Guide
• Attestation Verification Tutorial

dstack has been audited by zkSecurity.

Attestation proves which hardware and measured software produced the evidence. It does not prove application code is bug-free. For production, pin container images by digest, audit code that handles secrets, and define a policy for accepted OS images, compose hashes, KMS instances, and GPU evidence.

Security docs:

• Security Overview
• Security Model
• Security Best Practices
• CVM Boundaries

dstack powers confidential AI infrastructure for:

• OpenRouter
• NEAR AI

dstack is a Linux Foundation Confidential Computing Consortium open source project.

Telegram · GitHub Discussions · Examples

For enterprise support, book a call or email support@phala.network.

If you use dstack in your research, please cite:

@article{zhou2025dstack,
  title={Dstack: A Zero Trust Framework for Confidential Containers},
  author={Zhou, Shunfan and Wang, Kevin and Yin, Hang},
  journal={arXiv preprint arXiv:2509.11555},
  year={2025}
}

Apache 2.0