dstack’s core mechanism is not merely run code in a TEE; it is a multi-layer framework that packages confidential-VM orchestration, workload attestation, per-app key derivation, gateway/domain exposure, and optional governance into one deployable control plane.
The whitepaper’s most useful analytical move is the split between portable confidential containers, decentralized code management, and verifiable domain management. Those three layers explain where dstack is trying to go beyond ordinary confidential-VM hosting.
The overview docs make the key-independence claim concrete: tappd talks to a decentralized KMS that derives deterministic keys independently of any single TEE instance, which means migration and portability are first-class design goals rather than an afterthought.
The GitHub README is especially useful because it makes the operator/control surfaces explicit: guest agent, KMS, gateway, and VMM each own different trust boundaries, and the project explicitly contrasts itself with raw AWS / Azure / GCP confidential-computing primitives that leave attestation, key management, and orchestration to the developer.
dstack’s security story is broader than enclave attestation alone. The docs repeatedly tie trust to reproducible guest images, application identity, RA-TLS, gateway-managed exposure, and governance over code changes.
Specific source signals worth retaining
overview: best concise source for the CVM / dstack / tappd / decentralized-KMS split, plus the claim that workload identity binds image hash, startup args, and environment.
getting-started: best source for the operational component map (dstack-vmm, dstack-gateway, dstack-kms, dstack-guest-agent, meta-dstack) and for understanding how Docker-native deployment is preserved.
whitepaper: best source for the project’s stronger analytical framing as a Zero Trust platform, especially the portable confidential-container, decentralized code-management, and verifiable domain-management claims.
GitHub README: best source for how the team wants dstack compared against cloud-provider TEEs, SGX-style porting models, and confidential-GPU deployment.
Why this entry belongs in the corpus
It gives the corpus a clean confidential-computing infrastructure baseline beneath more application-specific crypto × AI products.
It is a strong comparison point for projects that claim to decentralize AI or private compute while quietly centralizing deployment, key release, domain control, or upgrade authority.
The durable insight is that TEE systems should be compared not only on hardware trust assumptions but also on who controls orchestration, identity, certificates, key derivation, migration, and lifecycle governance.