dstack

  • Name: dstack
  • URL: https://docs.phala.com/dstack/overview
  • Category: confidential-compute application framework / TEE container orchestration / zero-trust AI and agent infrastructure
  • Summary: dstack is best understood not as just another confidential-AI cloud or generic TEE hosting layer, but as a control plane for turning confidential VMs into portable, attestable application infrastructure. Its analytical value comes from the way it separates workload attestation, per-app key derivation, confidential-VM orchestration, TLS/domain ingress, and optional onchain code-governance policy into distinct layers. That makes it a useful comparison point for crypto × AI execution stacks, TEE-based agent systems, and any project whose decentralization story depends less on the TEE primitive itself than on who controls deployment, upgrades, keys, domains, and verifier tooling.
  • What it does:
    • Lets developers deploy ordinary Docker / Docker Compose applications into Intel TDX-based confidential VMs, with optional NVIDIA Confidential Computing support for GPU workloads
    • Exports remote-attestation reports that bind workload identity to runtime details such as image hashes and startup configuration
    • Uses a TEE-backed guest agent plus a separate key-management layer to derive per-application keys and protect secrets and encrypted storage
    • Provides gateway and ingress components for HTTPS exposure, RA-TLS, and domain routing to confidential workloads
    • Positions managed Phala Cloud as the hosted version of the same underlying dstack deployment model
  • Key claims:
    • The most important design move is that dstack turns confidential computing into a full-stack application-control plane rather than leaving developers with raw cloud TEE primitives. The docs and whitepaper separate CVM orchestration, attestation, KMS, gateway/domain management, and governance instead of flattening them into one generic confidential AI label.
    • The portable confidential-container idea is analytically important. dstack explicitly tries to break the usual seal-to-one-machine model by using a separate KMS and reproducible guest environment, so application keys and state can survive hardware migration instead of being trapped inside one vendor-specific TEE instance.
    • The gateway and verifiable-domain layer are a real control surface, not a deployment footnote. dstack treats HTTPS exposure, certificate handling, and remote-attested service identity as part of the trust model rather than as ordinary DevOps around a TEE.
    • The GitHub and whitepaper materials make clear that governance around updates matters as much as enclave integrity. dstack frames code lifecycle management — including upgrades and authorization checks — as something that can be constrained by predefined rules and smart-contract policy, which is more useful than treating attestation as the whole security story.
    • dstack also provides a useful lower-level comparison against projects like Ritual. It does not primarily sell a blockchain execution marketplace; instead it packages TEE workload deployment, attestation, key derivation, and optional governance into reusable infrastructure that other crypto × AI systems could sit on top of.
    • This entry belongs in the corpus because it makes confidential compute legible as an application-governance and trust-distribution problem, not just a hardware feature.
  • Whitepaper: dstack maintains a detailed whitepaper and open-source technical documentation; see ../whitepapers/dstack-primary-sources-2026-05-11.md.
  • Sources:

Internal linkages