Note: This article is adapted from the official Phala Network post: “dstack: One Confidential Compute Framework Across AWS, Google Cloud, and Phala” — published April 23, 2026. see it here: https://phala.com/posts/dstack-one-confidential-compute-framework-aws-google-cloud-phala
If you have ever tried shipping something on confidential compute infrastructure, you know the setup tax is real. Choosing AWS Nitro Enclaves or Google Cloud Confidential VMs is not just a hosting decision. It pulls in a whole chain of choices about how you package your workload, how your application proves its identity, and how it gets access to secrets at runtime. Every platform does this differently, and if you ever need to move between them, you are essentially starting from scratch.
That is the specific problem dstack is solving. It is an open framework from Phala.com that lets you write one workload definition, in standard Docker Compose format, and deploy it across AWS, Google Cloud, or Phala own infrastructure without rebuilding your trust model each time. On Google Cloud your workload runs inside a Confidential VM. On AWS it gets packaged into an enclave image. Either way, the environment is hardware-secured, the cloud provider cannot read your memory, and a compromised host machine cannot reach inside what is running. That baseline protection holds regardless of which backend you are on, and your application does not have to be written differently for each one.
The Verification Step Most Systems Skip
Here is where dstack separates itself from tools that just wrap cloud deployment in a nicer interface.
When your workload boots, it does not automatically get access to secrets just because it is running in a secure environment. Before anything sensitive is released, the workload has to prove exactly what code is running inside it. That proof is a cryptographic measurement, a fingerprint of the workload at that exact moment, and it gets sent to dstack’s key management component for verification. If the measurement matches what was previously authorized, keys get released. If the code has been changed in any way, the measurement is different and nothing gets released. No exceptions.
Your application talks to dstack through a consistent local interface regardless of which backend is underneath. On Google Cloud a component called the Guest Agent handles the verification work. On AWS a smaller utility called dstack-util does the same job inside the enclave. The backend differs because the platforms differ, but the interface your application sees and the logic your trust model follows stays the same across both. That is the design choice that makes dstack genuinely portable rather than just multi-cloud in name.
What Phala.com Brings to the Table Beyond the Cloud Providers
Hardware-secured environments are something AWS and Google both offer. What Phala adds through dstack is a policy layer that sits above all of it.
Rather than keeping authorization decisions buried inside your infrastructure config, dstack lets you register approved workload measurements on-chain. That means any change to what your system trusts is recorded, visible, and traceable by anyone who needs to verify it. Governance over your trust model gets lifted out of the infrastructure layer entirely, which is meaningful when you are running sensitive workloads across multiple teams or need to demonstrate compliance to someone outside your organization. And because that policy layer is not tied to any single cloud backend, it works consistently whether you are on AWS, Google Cloud, or Phala’s own network.
This matters most for AI infrastructure. Model weights, inference inputs, API credentials, proprietary business logic running inside a model server. These assets need protection while the application is actively using them, not just while they are sitting in a database. Most encryption handles the storage problem. dstack handles the runtime problem, and it does it in a way that does not chain you to one cloud provider’s implementation of secure compute.
The dstack repository is public and worth exploring if you are building anything in this space. Phala has put real work into making confidential compute portable in a way that holds up past the demo stage, and the GitHub documentation walks through both the Google Cloud and AWS deployment paths in practical detail.
Interested in building with dstack? Visit the official https://phala.com/ site and explore the dstack GitHub repository to dig into the code and deployment guides.
Top comments (0)