dstack: One Confidential Compute Framework Across AWS, Google Cloud, and Phala

If you are building with confidential compute today, the first practical question is straightforward:

Which platform should you use?

• AWS Nitro Enclaves for stricter enclave isolation?
• Google Cloud Confidential VMs for a more VM-like operating model?
• Phala’s TEE stack for a more portable, policy-aware trust model?

That is a real architecture decision. But the more important problem is what happens after you make it.

Historically, choosing a confidential-compute platform also meant choosing a different deployment model, a different attestation flow, a different secret-delivery path, and often a different application integration strategy.

That is exactly the fragmentation dstack is trying to remove. Its role is simple to describe, but technically important:

• define workloads once
• translate them into the right TEE runtime for each platform
• expose a consistent attestation and key-delivery interface to applications
• keep policy centered on measured identity instead of cloud-specific machinery

That is what makes dstack interesting.

The problem dstack actually solves

Most confidential-compute systems stop at infrastructure enablement.

They give you a TEE-capable environment, but they still leave the application team to solve several hard problems themselves:

• How is the workload packaged for the target TEE?
• How does the workload prove its identity?
• How does it obtain secrets safely?
• How do you express which measurements are authorized?
• How much application code must change across AWS, GCP, and other TEE backends?

dstack turns those into a framework problem instead of a per-platform integration problem.

At a high level, dstack provides three layers of unification:

1. A unified deployment model
2. A unified trust and key-delivery model
3. A unified application-facing interface

Those three layers are what matter more than any single cloud integration.

1. Unified deployment: one workload model, multiple TEE targets

One of the strongest ideas in dstack-cloud — as shown in the architecture overview — is that the developer should not have to manually design a completely different packaging flow for each confidential-compute backend.

Instead, dstack lets developers define workloads using familiar Docker Compose-style deployment manifests. The dstack tooling then translates that higher-level definition into the correct platform-specific artifact, following the model described in the dstack-cloud overview.

That means:

• on Google Cloud, the workload is deployed into a Confidential VM environment
• on AWS, the same logical workload is packaged into an EIF (Enclave Image File) for Nitro Enclaves

This is more significant than it sounds.

Without this abstraction, the application team is forced to reason directly in terms of cloud-specific TEE packaging:

• VM images and guest setup on one platform
• enclave image construction and launch tooling on another

With dstack, the developer works from a more stable workload definition, and the platform adapter handles the last-mile transformation.

That is the first big simplification: dstack separates application intent from TEE packaging details.

2. Unified trust model: attestation, measurement, and key release

The second layer is the real core of dstack.

No matter which backend is used, dstack keeps the same trust logic:

1. the workload must produce valid remote attestation
2. the workload is identified by a measurement-derived identity
3. keys are released only after verification
4. authorization can be made explicit through policy and on-chain registration

This matters because it moves confidential compute away from a vague notion of “trusted hardware” and toward a much more precise model:

• not just where the workload runs
• but what exact measured workload is running
• and whether that workload is authorized to receive secrets

That is the right abstraction for production systems.

3. Unified app interface: applications talk to dstack, not cloud internals

The third layer is what makes the system usable for developers.

This architecture notes show that user application containers interact with the dstack runtime through a consistent local interface, rather than by speaking directly to each cloud’s attestation mechanism.

In practice, that means the workload talks through the dstack interface — typically exposed over a Unix socket such as `/var/run/dstack.sock` — while the platform-specific runtime helper handles the underlying attestation and key retrieval path.

That helper differs by backend:

• on Google Cloud, the helper is the Guest Agent
• on AWS Nitro, the helper is `dstack-util`

The application-facing contract stays much more stable than the infrastructure beneath it.

That is the second big simplification: developers integrate once with the dstack model, while dstack handles the backend-specific attestation path.

What dstack looks like on Google Cloud

On Google Cloud, dstack runs on Confidential VMs.

This is the more VM-oriented deployment path. The runtime includes:

• a full confidential VM environment
• direct networking
• persistent storage support
• a Guest Agent responsible for the TEE control-plane logic

The Guest Agent handles tasks such as:

• collecting attestation evidence
• establishing the secure channel to KMS
• retrieving keys after verification
• coordinating storage-related encryption flows
• exposing dstack services to the application runtime

This makes the GCP path a good fit when you want confidential compute in a runtime that still looks operationally like a server.

It is especially practical for:

• long-running services
• applications that expect normal networking
• workloads with richer storage needs
• teams that want lower operational friction

The important point is that dstack does not merely “run on GCP.” It uses the GCP runtime as one backend for a broader trust framework. The operational flow in the GCP deployment guide makes that explicit: dstack still owns the workload packaging, attestation path, and key-delivery model.

What dstack looks like on AWS Nitro

On AWS, dstack targets Nitro Enclaves, which are much more constrained than confidential VMs.

The runtime assumptions change materially:

• no direct network access
• no persistent storage
• communication through a VSOCK proxy on the host
• enclave packaging via EIF
• a smaller control-plane helper inside the enclave

This is where `dstack-util` comes in.

Rather than running a full Guest Agent inside the enclave, dstack packages dstack-util alongside the application. Its job is to perform the minimal but critical control-plane operations needed inside Nitro:

• obtain the NSM Attestation Document
• present that attestation to dstack-kms
• receive the released key once verification succeeds
• hand that key to the application runtime

This is a more enclave-native architecture than the GCP path. It places more responsibility on the application for how secrets are consumed, but it also maps much more cleanly onto Nitro’s security model.

Again, the important point is not just that dstack “supports AWS.”

It is that dstack preserves the same higher-level trust contract while adapting to a very different runtime shape. The Nitro concept doc and the AWS deployment guide show how that abstraction is implemented in practice.

Guest Agent and dstack-util are two implementations of the same idea

A useful way to understand dstack is to see the Guest Agent and `dstack-util` not as unrelated components, but as two backend-specific implementations of the same control-plane role.

That role is:

• collect attestation evidence from the underlying TEE
• send it to the verification and key-delivery path
• expose the verified secrets to the application through the dstack runtime model

The implementation differs because the underlying platforms differ.

On GCP

The Guest Agent can do more because it runs in a full confidential VM with broader system capabilities.

On Nitro

dstack-util is intentionally narrower because Nitro Enclaves are intentionally narrower.

This is exactly what a good framework should do: keep the contract stable while allowing the implementation to vary with the runtime.

dstack-kms is the enforcement point

The most important security component in this design is dstack-kms. In production, that can be self-hosted — for example by running dstack-kms on GCP — while keeping the same attestation and authorization model for workloads.

This is where dstack moves from “TEE integration” to an actual secret-distribution framework.

In the dstack model, a workload does not receive sensitive material simply because it booted in a confidential environment. It receives secrets only after a verification flow succeeds.

The sequence is conceptually the same across backends:

1. workload boots inside the target TEE
2. runtime helper collects attestation evidence
3. attestation is sent to dstack-kms
4. KMS verifies the evidence and the workload identity
5. only then are keys released

That gives dstack a much stronger security posture than host-identity-based secret delivery.

It means secrets are bound to cryptographically verified workload identity, not just to infrastructure metadata.

Measurement is the real identity primitive

A key design choice in dstack is that measurement, not machine identity, is the real basis for trust.

That principle survives across both backends.

On Google Cloud

The attestation path is based on:

• Intel TDX Quote
• Google vTPM Quote

These are bound together to provide a stronger picture of confidential execution and boot integrity.

On AWS Nitro

The attestation path is based on the NSM Attestation Document and enclave measurements. DeepWiki notes that the relevant PCR values are combined into an `OS_IMAGE_HASH`, which acts as the identity of the enclave image.

This is an important point.

dstack is not modeling trust as:

• “this workload runs in AWS”
• “this workload runs in a TEE”
• “this instance belongs to the right account”

It is modeling trust as:

• this exact measured workload proved its identity

That is the right security boundary for AI systems, model-serving systems, and any environment where secret release must be tied to code integrity.

Local keys and KMS mode

dstack supports more than one operating mode for secret handling.

Local Key Provider

In local mode, the workload manages keys within its own trusted boundary.

This is useful for:

• development
• simpler single-instance deployments
• scenarios where centralized secret coordination is unnecessary

KMS Mode

In KMS mode, dstack-kms becomes the central gatekeeper for secret release.

This is the production-oriented model, and it is the more important one for understanding dstack’s architecture.

KMS mode is the right choice when you need:

• centralized policy
• shared secrets across workloads
• multi-node coordination
• explicit authorization controls
• stronger auditability around who can receive what key material

This is also the mode that makes dstack most portable across different TEE backends. Once the workload identity can be verified, the secret-distribution model stays consistent. The GCP KMS deployment guide is a good reference for how the control plane can be deployed independently from the application workload.

On-chain authorization is where Phala becomes strategically important

This is where the Phala side of the story matters.

dstack does not have to stop at remote attestation and key verification. It can also incorporate on-chain authorization through contracts such as `DstackApp` and `DstackKms`.

That creates an additional policy layer:

• approved workload measurements can be registered on-chain
• authorization changes become auditable
• governance can be separated from ad hoc infrastructure trust
• the same policy model can span multiple TEE backends

This is strategically significant because it pushes dstack beyond “confidential cloud deployment” and toward verifiable confidential-compute policy infrastructure. That broader architecture is easiest to see by reading the main dstack-cloud repository together with the Nitro support work.

Many systems can attest a workload. Fewer systems make authorization explicit, auditable, and portable.

That is where dstack aligns naturally with Phala’s broader trust model.

So when should you use AWS, GCP, or Phala via dstack?

This comparison still matters, but it should be read through the dstack lens.

Choose Google Cloud Confidential VMs when you want:

• a more familiar VM-style environment
• direct networking
• persistent disk
• smoother operations
• stronger compatibility with existing server workloads

Choose AWS Nitro Enclaves when you want:

• enclave-native isolation
• a smaller trusted runtime surface
• more explicit control over secret use inside the application
• AWS-native deployment for highly sensitive workloads

Choose dstack as the framework when you want:

• the same trust model across both
• a stable application-facing interface
• a common key-delivery and attestation flow
• the option to anchor authorization in Phala’s policy model

That is the key point: dstack is not just another target in the comparison. It is the layer that makes the comparison less painful.

Why this matters for AI workloads

This architecture is particularly relevant for AI systems because the most sensitive assets are often runtime assets:

• model weights
• prompts and policies
• inference inputs
• API keys
• proprietary business logic
• downstream signing or execution credentials

Those assets need more than encrypted storage. They need controlled runtime exposure.

dstack’s model is well suited to that requirement because it combines:

• measured execution
• attestation-backed identity
• secret release after verification
• portable policy across different TEE backends

That is a much stronger foundation for confidential AI than a cloud-specific enclave integration by itself.

Closing

The interesting question is not just which confidential-compute platform is best in the abstract.

The better question is:

How do you avoid rebuilding your trust model every time you switch runtimes?

That is the problem dstack solves.

AWS Nitro Enclaves, Google Cloud Confidential VMs, and Phala’s TEE model all have different strengths. The execution environments differ. The networking assumptions differ. The storage assumptions differ. The developer ergonomics differ.

But if developers can:

• define workloads once
• integrate once with the dstack runtime model
• verify workloads through attestation
• release secrets through the same KMS-centered logic
• express authorization through a portable policy layer

then confidential compute starts to look less like a fragmented collection of cloud features and more like a real application framework.

That is the real significance of dstack.

Not just another backend.

A unifying confidential-compute layer across AWS, Google Cloud, and Phala.