Dstack - Decentralized Cloud TEEs

While AWS Nitro Enclaves provide a rigorous and secure cloud solution for practically any application, the root of trust in most of AWS’s systems are derived from the consumer’s trust in their systems and promises. Dstack presents an alternative to traditional cloud vendors with the major differentiator being, you don’t need to trust Dstack’s developers/maintainers and still get verifiably secure environment to run applications.

Dstack is a Zero Trust framework that turns heterogeneous, vendor TEEs into a portable, verifiable confidential container platform allowing users to deploy ordinary Docker apps into TEEs. It is designed specifically for Web3-style trust models, where:

• No single infrastructure provider should be a permanent trust anchor.

• Application code and lifecycle must be governed transparently and follow the principle of “Code is Law”.

• Users must be able to verify end-to-end what is running, where, and under whose control.

Where AWS Nitro Enclaves provides a strong TEE abstraction within a single cloud (Amazon EC2), Dstack focuses on decentralized trust: it layers blockchain governance, decentralized key management, and verifiable domain binding on top of VM-level TEEs such as Intel TDX and AMD SEV-SNP.

Differentiators of Dstack

• Portable Confidential Containers that enable seamless workload migration across heterogeneous TEE environments while maintaining security guarantees

• Decentralized Code Management that leverages smart contracts for transparent governance of TEE applications

• Verifiable Domain Management that ensures secure and verifiable application identity without centralized authorities.

The core technical innovation lies not in creating new TEE hardware, but in building a decentralized governance and a management layer on top of it. The trust establishment chain for Dstack can be summarised as:

• Measured boot → Attestation: a verifiable startup chain from hardware → Dstack-OS → your container images; measurements are compared to an expected policy (e.g., MR config / compose hash).

• Policy-gated secrets: the KMS releases keys only after successful attestation (prevents exfiltration by cloud admins/hypervisor).

• Verifiable identity & governance: optional on-chain records let anyone confirm the code/config tied to a domain or action; Ethereum can act as a public referee for scheduling/verification.

<aside> 💡

The Dstack project is open-sourced is under the Linux Foundation’s Confidential Computing Consortium umbrella.

</aside>

System Design of Dstack

Dstack is explicitly designed to satisfy four Zero Trust principles in a TEE context. A Zero Trust Architecture (ZTA) platform must satisfy four key principles:

• Code is Law

  • Application logic, once deployed, should not be changed arbitrarily.

  • Lifecycle actions (deploy, upgrade, retire) follow predefined governance rules.

• Censorship Resistance

  • No single vendor or hardware instance should be able to lock data or workloads in place.

  • Users must retain the ability to move workloads off compromised or censored infrastructure.

• Full Chain of Trust

  • Users should be able to verify: hardware, OS, application image, governance, key management, and network identity.

• Assume Breach

  • TEEs can and will be compromised.

  • The platform must support containment, recovery, and damage limitation (e.g., via key rotation and workload migration).

Nitro Enclaves focuses on strong isolation on a given EC2 host, with attestation and KMS policy integration. Dstack takes those VM-level TEE capabilities as a substrate and builds a multi-party, blockchain-governed trust layer above them, explicitly accounting for TEE vulnerabilities and vendor dependence.

Core Components

Dstack’s system architecture revolves around three main subsystems:

• Dstack-OS

  • A minimized OS image that runs inside the VM-level TEE.

  • Implements a secure boot chain from TEE hardware → Firmware → Kernel → root Filesystem → User containers.

  • Provides container runtime, encrypted storage, and integrity checking.

• Dstack-KMS

  • A blockchain-controlled key derivation and management service.

  • Generates a stable but portable “root key” per application, from which all other keys are derived.

  • Runs as a cluster of TEE-backed nodes governed by on-chain contracts.

• Dstack-Ingress and Dstack-Gateway

  • TEE-based reverse proxies / ingress components that supply Zero Trust TLS (ZT-TLS).

  • Bind domains and TLS certificates to specific, verified TEE workloads.

Architecture

The architecture of Dstack, including Dstack-OS and Dstack-KMS. Dstack-OS provides a hardware abstraction layer with a minimized operating system image, while Dstack-KMS replaces hardware-based data encryption keys with a blockchain-controlled key management service. It is tied together with a few other components to create a portable CVM platform.

• Dstack-vmm: A service running in a bare TDX host to manage CVMs

• Dstack-gateway: A reverse proxy to forward TLS connections to CVMs

• Dstack-kms: A KMS server to generate keys for CVMs

• Dstack-guest-agent: A service running in CVM to serve containers' key derivation and attestation requests

• meta-Dstack: A Yocto meta layer to build CVM guest images

Portable Confidential Containers

Traditional TEE deployments, including VM-level approaches, typically derive data sealing keys from hardware-bound root keys, unique per TEE instance. Encrypted data is bound to a single hardware platform (or even to a single machine) under the assumption TEEs are “secure enough” to be permanent trust anchors. This however raises two fundamental obstacles for a ZTA platform:

• Hardware-bound keys means that data encrypted by one TEE cannot be decrypted by another (even if they are running the same application code). This has largely been circumvented by deploying only stateless applications to TEE-VMs but this limits their utility.

• Fragmentation of platforms means that developers have to maintain several types of attestation artifacts across platforms, each requiring additional developer time and resources to verify functional equivalence of all runtime instances of their applications.

Dstack introduces two complementary services, Dstack-KMS and Dstack-OS to address these problems.

Dstack-KMS

Dstack-KMS is a key derivation service that replaces hardware-bound sealing with a blockchain-governed, TEE-backed key service:

• For each application, it derives a Root Key from the application’s code and configuration.

• From that Root Key, it derives the keys used for encryption, signing, and TLS.

• It is explicitly designed under the assumption that TEE instances can be compromised; integrity is anchored in on-chain governance plus MPC, not in any individual TEE instance.

Architecture

The architecture of Dstack-KMS combines on-chain governance through smart contracts with an off-chain P2P network of secret derivation service nodes. This design ensures both verifiability and resilience against compromise. It has:

• On-Chain Component (KmsAuth Smart Contract):

  • Serves as the root of trust and authoritative registry for the entire system.

  • Stores the cryptographic digests (hashes) of the approved Dstack-KMS executable binaries and maintains a registry of authorized TEE applications and their governance contracts (AppAuth).

  • Governs the lifecycle of the root key (e.g., initiating key rotation).

• Off-Chain Component (P2P Network of Service Nodes):

  • The actual key derivation service runs as a peer-to-peer network of nodes, each within its own TEE instance.

  • The TEE's role here is not to be inherently trusted, but to provide a verifiable execution environment for the Dstack-KMS code. The code's measurement is verified against the digest stored in the KmsAuth contract.

Unlike Nitro Enclaves, where confidential workloads typically rely on a cloud provider’s KMS tied to that provider’s attestation and infrastructure, Dstack-KMS is provider-agnostic and controlled by smart contracts rather than a cloud operator. TEE attestation is used only to check that each node runs the approved KMS code; it is NOT treated as an infallible trust anchor.

Key Generation and MPC

Dstack-KMS offers two models for generating and managing the root key (in contrast with Nitro Enclaves’ model, where AWS KMS is the single logical key service and trust in key custody is concentrated in the cloud provider). The two models are:

1. Simple Duplication: The first node generates a cryptographically secure root key and, after verifying their attestation reports, shares it with other nodes. This provides high availability (any single node can serve the key) but is vulnerable to a single node compromise.

2. MPC-Based Key Generation (Threshold Scheme): Uses Shamir's Secret Sharing to split the root key into shares distributed across multiple nodes. The key can only be reconstructed when a threshold number of nodes collaborate. This protects against the compromise of individual nodes (up to the threshold limit).

Key Derivation

From the root key, application-specific keys are derived using a Key Derivation Function (KDF like HKDF), using the application's unique identifier (a hash of its code and configuration) as a parameter. This creates:

• Application CA Key: For signing certificates.

• Disk Encryption Key: For encrypting application data volumes.

• Environment Encryption Key: For securing environment variables.

• ECDSA Key: For providing a consistent application identity for signing. This ensures that the same application, regardless of which TEE hardware it runs on, gets the same set of cryptographic keys, enabling data portability across platforms.

With Nitro Enclaves, TEE identity and KMS authorization are bound to the AWS Nitro attestation pipeline and to AWS-managed KMS keys. Dstack externalizes this function into a blockchain-governed, vendor-neutral KMS layer.

Key Rotation

• Root Key Share Rotation: In the MPC model, individual key shares can be updated without changing the actual root key. This is a proactive security measure.

• Full Root Key Rotation: Used when a key compromise is suspected. A new root key is generated. A controlled handover period allows applications to access both the old and new keys, so they can re-encrypt their data with the new key before the old one is destroyed. This provides forward and backward secrecy.

This design directly serves Assume Breach, even if a TEE or node is compromised at some point, blast radius and exposure time are limited, and workloads can be moved to new TEEs without losing confidentiality.

Dstack-OS

Dstack-OS is a minimal, purpose-built operating system image that boots inside the TEE (e.g., an Intel TDX Trusted Domain or an AMD SEV Secure VM). Its purpose is to provide a consistent, verifiable environment across different TEE implementations. Where Nitro Enclaves reuse Amazon’s Nitro Hypervisor and EC2 images with enclave-specific restrictions, Dstack-OS is built to tightly control the content and behavior of the TEE-resident environment. It provides a Hardware Abstraction Layer with a minimized operating system image that eliminates differences in underlying TEE hardware while reducing the attack surface. The HAL provides a consistent, secure runtime environment across diverse TEE implementations, supporting both portability and reliability.

Secure & Verifiable Boot Chain

The boot process is a critical chain of measurements, where each component measures the next before executing it, with all measurements included in the final TEE attestation quote.

1. Hypervisor/TDX Module: Loads the OVMF (Open Virtual Machine Firmware) and records its hash.

2. OVMF Firmware: Configures the VM and loads the Linux kernel, recording its hash.

3. Linux Kernel: Loads an initial RAM disk (initrd) which is a minimal in-memory filesystem with tools and disk-encryption libraries.

4. Root Filesystem (RootFs): A read-only filesystem containing the core Dstack-OS utilities and the container runtime. It is responsible for:

   • Interfacing with Dstack-KMS to fetch application keys.

   • Using LUKS (Linux Unified Key Setup) to decrypt the application's data volume.

   • Using dm-verity to verify the integrity of the application container image.

   • Starting the application container and configuring network ingress.

Minimalist Design & Reproducible Builds

Built from scratch using only essential components (e.g., busybox), it minimizes the attack surface. The entire system is open-source and built using reproducible builds, meaning anyone can compile the source and obtain a bit-for-bit identical binary, which can then be verified against the hash in the KmsAuth contract. This is conceptually similar to Nitro Enclaves’ “no-storage, no-network” TEE VM model, but:

• Dstack-OS explicitly standardizes the TEE runtime across hardware vendors.

• Encryption keys originate from Dstack-KMS rather than hardware-bound keys or cloud KMS alone.

Anti-Rollback Mechanisms

To prevent an adversary from reverting an application to a previous state to exploit old vulnerabilities, Dstack-OS supports the use of monotonic counters. The application can increment a counter with each data update, and this value is incorporated into the encrypted data. Upon restoring a backup, the application can verify the counter value to ensure it's not rolling back to an older, vulnerable state.

Decentralized Code Management

Dstack’s decentralized code management framework bridges these two worlds by placing TEE application governance under smart contract control, creating a transparent and auditable system for application deployment and updates that aligns with Web3 principles of Code is Law.

TEE hardware ensures that some specific binary runs as measured, but it does not enforce:

• Who is allowed to change that binary.

• Whether an upgrade is legitimate or malicious.

• Whether governance rules were followed.

In Nitro Enclaves, this is left to user processes and KMS policies: AWS provides attestation and KMS controls, but it does not enforce DAO-style governance for code changes.

Dstack fills this gap by making on-chain governance contracts the root of control over which code is allowed to receive secrets.

Technical Solution: Two-Tier Governance Smart Contracts

The system uses a modular smart contract architecture:

• KmsAuth Contract (Global Authority)

  • The top-level contract that controls the Dstack-KMS service.

  • Maintains a whitelist of authorized applications.

  • Ultimately controls an application's lifecycle by dictating whether Dstack-KMS is allowed to provide secrets to a TEE instance running that application.

• AppAuth Contract (Per-Application Authority)

  • A dedicated contract deployed for each TEE application.

  • Contains application-specific governance rules:

    • Authorized Code Hashes: The list of cryptographic digests of container images that are permitted to run.

    • Authorized TEE Identities: Which TEE instances (identified by their attestation measurements) are allowed to run the application.

    • Upgrade Logic: The rules for approving new code versions (e.g., multi-signature requirements, DAO voting mechanisms).

Enforcement Mechanism: The Cryptographic Gatekeeper

The governance is enforced not by the TEE itself, but by the Dstack-KMS. The process for a code upgrade is as follows:

1. A developer submits the hash of a new container image to the AppAuth contract.

2. The contract's governance rules are executed (e.g., collecting multi-signatures from key stakeholders).

3. Once approved, the AppAuth contract updates its authorized code hash list.

4. The KmsAuth contract, which monitors all AppAuth contracts, is updated.

5. Dstack-KMS nodes, synced with KmsAuth, now recognize the new code hash as authorized.

6. When a TEE instance requests the application keys, it provides its attestation quote. Dstack-KMS verifies that the quote contains an authorized code hash from the AppAuth contract.

7. Only upon successful verification does Dstack-KMS release the encryption keys to the TEE instance. Without these keys, the application cannot decrypt its data and is effectively neutered.

This creates a powerful cryptographic enforcement mechanism: even if a developer has administrative access to the cloud infrastructure, they cannot force a malicious update because the updated, unauthorized code will be unable to acquire the keys needed to function.

Verifiable Domain Management

Applications typically rely on HTTPS/TLS and browser indicators to decide whether a service is “legitimate,” but:

• A standard certificate says nothing about which code or which TEE environment holds the private key.

• A malicious operator or CA could issue certificates to unauthorized endpoints.

ZT-TLS aims to make “this domain → this TEE application under this governance” cryptographically verifiable. In contrast to Nitro Enclaves where TLS termination and domain control are typically handled via standard load balancers and certificate services (e.g., ACM), Dstack adds an explicit TEE + on-chain governance binding for the TLS layer so that browser-trusted identity is coupled to TEE identity and on-chain governance.

Zero-Trust TLS Protocol (ZT-TLS)

ZT-TLS creates a cryptographic binding between a domain name and a specific TEE application.

• TEE-Generated Certificates: The Dstack-Gateway or an application using Dstack-Ingress generates its own TLS certificate internally, using its application-specific ECDSA key derived from Dstack-KMS. The private key never leaves the TEE.

• Certificate Authority Authorization (CAA): DNS CAA records are configured for the domain to specify that only certificates from a specific issuing authority (that verifies TEE attestation) are valid. This prevents a malicious actor from going to a different Certificate Authority (like Let's Encrypt) to get a fraudulent certificate for the same domain.

• Certificate Transparency (CT) Monitoring: All publicly trusted certificate issuances are logged in public CT logs. Dstack monitors these logs for any certificates issued for its domains without proper authorization, providing a tamper-evident audit trail and enabling rapid detection of domain hijacking or mis-issuance.

Implementation Components

• Dstack-Gateway: A pre-built, managed reverse proxy running in a TEE. Applications can register with it via an API. The Gateway verifies the application's attestation and then assigns it a subdomain (e.g., app1.Dstack.com). It handles all TLS termination and certificate management automatically. The user's browser trusts the connection because it trusts the Gateway's certificate, which is itself verifiably tied to a TEE.

• Dstack-Ingress: A library and service for applications that require custom domains. It provides the tools for the application to manage its own TLS certificates following the ZT-TLS protocol, offering more flexibility at the cost of slightly more integration effort.

Verifying Dstack Applications

Threat Model

The trust model assumes correctness of the Dstack components (Dstack-OS, Dstack-KMS, Dstack-Gateway, governance contracts) as open-source, reviewed, and verified artifacts. Dstack explicitly treats:

• Developers and administrators as potential adversaries.

• TEE hardware as fallible, not as a perfect trust anchor.

• Network and DNS as potentially compromised.

Reproducibility and In-Confidential-Container (In-CC) Build

A central challenge for any TEE platform is:

Attestation proves which binary is running, but not that the binary was built from the reviewed source.

Dstack addresses this by open-sourcing components and documenting configurations, using reproducible builds where feasible (e.g., Dstack-OS) and introducing In-CC Build in which:

• Build pipelines run inside a verified Dstack-OS environment.

• Source code is fetched, compiled, and packaged into containers entirely within the TEE.

• The resulting artifact’s measurement is then used for attestation and registered on-chain.

This bridges the gap between source and binary with a verifiable environment, reducing supply-chain attack surface.

The Verification Chain in Practice

The entire system's trust is anchored in the KmsAuth smart contract. A user's verification of an application follows this chain:

1. Root of Trust: The publicly known KmsAuth contract address.

2. Verify Dstack-KMS: Check that the off-chain KMS nodes are running code whose hash matches the one registered in KmsAuth, verified via their TEE attestation quotes.

3. Verify Dstack-Gateway: The KMS nodes verify the Gateway's attestation quote. The Gateway, once verified, gets its application keys and certificate from the KMS.

4. Verify User Application: The user application is deployed. Its hash is registered in its AppAuth contract. The KMS nodes verify its attestation quote against this hash before providing it with keys. The application also registers with the Gateway.

5. User Access: The user connects to https://app1.Dstack.com. The Gateway forwards the request to the verified application. The user's browser sees a valid TLS certificate. The user can, if they wish, request the application's TEE quote, which can include a public key or other data as proof of its genuine execution environment.

Component	Source	Build Method	Registry	Verification
dstack-OS	Open	Reproducible	KmsAuth	OS Digest
dstack-KMS	Open	In-CO	KmsAuth	Image Hash, Root PubKey
dstack-Gateway	Open	CC	AppAuth	Image Hash

Security Architecture Overview

Handling TEE Vulnerabilities & Detection Limitations

Dstack acknowledges the reality of TEE vulnerabilities (side-channels, microarchitectural attacks, etc.) and mitigates them by:

• Multi-layered defense system by using TEEs which provide isolation and attestation, Dstack-KMS, governed by on-chain contracts and MPC (reducing reliance on any single TEE) and ZT-TLS and verifiable domains protect network identity.

• Key rotation and migration where applications can be moved from vulnerable TEEs to patched ones. Meanwhile allowing applications to rotate root keys limits long-term damage in case of an incident.

Nitro Enclaves also benefit from patched hardware and new instance types, but key management and attestation remain under a single cloud provider’s operational domain. Dstack explicitly models vendor independence & cross-TEE portability as part of its security strategy.

Dstack design recognizes that detecting low-level TEE exploitation is extremely difficult and practical detection strategies (statistical anomaly detection, honeypots, cross-validation) are still an open research area. As such, the primary Dstack defenses are architectural, in that it:

• Assumes compromise is possible.

• Maked it cheap to rotate keys, redeploy workloads, and restore data on new TEEs under the same governance.

• Keeps the trust surface minimal, transparent, and auditable.

Trust Model Comparison: Dstack vs AWS Nitro Enclaves

When contrasted with AWS Nitro Enclaves, Dstack shifts the trust model from “trust the cloud provider and its TEE implementation” to “trust a verifiable combination of open-source code, blockchain governance, and distributed KMS,” while still leveraging the performance and isolation benefits of VM-level TEEs.

For cloud TEEs, Dstack’s architecture demonstrates how to move from trusted infrastructure to verifiable, decentralized infrastructure, aligning confidential computing with the stricter security and governance expectations of Web3 and other Zero Trust environments.

Aspect	AWS Nitro Enclaves	Dstack
Root of Trust	Rooted in the AWS Nitro System (Nitro Security Chip, Nitro Hypervisor).Attestation is signed by AWS-managed Nitro attestation keys.AWS KMS trusts these attestations to enforce key policies.	Rooted in blockchain governance contracts (KmsAuth, AppAuth) plus open-source code and MPC-backed KMS.TEEs are used to measure and attest code, but are not treated as unbreakable.KMS nodes and gateway/app TEEs are all verified against on-chain digests.
Key Management & Data Portability	Primary key service is AWS KMS, which:- Ingests Nitro attestation documents.- Uses PCR values/measurements and IAM conditions to gate access.Data encryption and KMS integration are tied to AWS infrastructure and Nitro attestation.	Key service is Dstack-KMS, controlled by smart contracts, implemented as a TEE-backed P2P network.Root keys and derived keys are portable across TEEs and hardware vendors, enabling:- Migration away from vulnerable hardware.- Movement across infrastructures.MPC and key rotation are built-in to limit damage from breach.
Code Governance & Lifecycle	Enforces that a particular measured image is running, but:- Does not define how code is approved or upgraded.- Governance and review are external processes (CI/CD, manual review).“Code is Law” is implemented by the user, not by the platform.	Code lifecycle is governed by on-chain AppAuth contracts.Only TEEs running code whose digests are authorized by governance can receive secrets from Dstack-KMS.Multi-sig or DAO-style governance can be enforced by contract for every upgrade.Unauthorized images may run, but cannot access application secrets, which effectively strips them of power.
Domain & Client Trust	Applications typically integrate with existing load balancers and TLS termination using traditional certificates.There is no built-in linkage from domain name → TEE measurement → governance; users rely on standard PKI.	Introduces Zero Trust TLS:- TLS private keys generated in TEE, from Dstack-KMS secrets.- Domain binding enforced via DNS CAA and monitored via CT logs.Clients (or auditors) can establish that an HTTPS endpoint is controlled by a specific, governed TEE application.
Failure Modes & Recovery	If hardware or software vulnerabilities are discovered, users must:- Rotate instance types.- Rebuild enclave images.- Rely on AWS processes for KMS and attestation updates.Data and keys remain under AWS control.	Allows:- Migration of applications and data across TEEs and vendors using portable Root Keys.- Rapid key rotation and share rotation.- Governance-controlled upgrades of Dstack-KMS itself.Failure is assumed; mechanisms exist explicitly to minimize and contain its impact.

General Comparison between AWS and Dstack

Attribute	Dstack (Phala Cloud / self-host)	AWS (platform-wide)	AWS Nitro Enclaves (specific)
Description	Zero-trust framework + runtime to run Docker apps in TEEs; includes Dstack-OS, Dstack-KMS, Dstack-Gateway (ZT-HTTPS).	Cloud platform featuring Nitro System, EC2 “Confidential” (SEV-SNP/TDX when available), and Nitro Enclaves.	Highly isolated enclave VMs carved from an EC2 parent (no network/storage/user access).
Attestation & KMS	Measured boot of container images & config; KMS releases secrets only if policy matches attestation.	Depends on service; EC2 SEV-SNP exposes an attestation report for instances.	Enclave generates a Nitro attestation doc verified by AWS KMS to release keys; tight KMS/ACM integrations.
Networking	Normal networking with ZT-HTTPS: TLS terminates inside the TEE; verifiable service identity.	Standard cloud networking services.	No external networking in enclave; traffic proxied from parent via vsock; ACM for Nitro Enclaves can provision certs for TLS inside enclave.
Storage	App-level choice (e.g., remote DB, object stores) with secrets gated by attestation; runs in CVMs/TEE VMs.	Full suite (EBS, S3, etc.).	No persistent storage in enclave; everything ephemeral/in-memory; rely on parent/remote stores via proxy.
Portability / lock-in	Designed for Portable Confidential Containers across TDX/SEV-SNP and clouds; minimizes vendor lock-in.	AWS-centric; portability is your responsibility.	AWS-only (enclave tied to an EC2 parent).
Dev workflow	Bring a docker-compose.yml; Dstack handles attestation, secret release, TLS, and exposure.	Standard AWS tooling; for SEV-SNP you pick supported instance families.	Build an EIF (enclave image file) from your Docker image, allocate vCPU/RAM from parent, wire vsock/KMS.
Governance / identity	Optional decentralized code/domain management (on-chain) for verifiable ownership and anti-censorship.	Centralized IAM/KMS/ACM.	Centralized IAM/KMS/ACM.
Typical sweet spot	Run full web services (APIs, web apps) inside TEEs with public endpoints and verifiable identity.	Broad IaaS/PaaS.	Protect high-sensitivity functions (key mgmt, signing, PII transforms) in an isolated coprocessor-like enclave.
Costs	(Framework open-source; managed Phala Cloud pricing not covered here.)	EC2 SEV-SNP adds ~10% to instance price (service-level uplift).	No extra charge beyond EC2 & used AWS services; you reserve some parent resources for the enclave.

Compared to AWS Nitro and Nitro Enclaves, Dstack pushes the trust boundary further away from any single cloud provider by using TEEs as one component in a broader, blockchain-governed, multi-party architecture. It gives you portable confidential containers, decentralized key management, and Zero Trust TLS, so neither a cloud operator nor a compromised TEE instance can unilaterally control your data or code. That makes Dstack compelling for Web3-style applications, multi-cloud or jurisdictionally sensitive workloads, and situations where governance transparency and cryptographic portability matter more than scale, performance or compliance.

However, this same design means Dstack is not always the best fit. If you need strong, contractually backed SLAs, a globally operated support organization, or alignment with a wide catalogue of named compliance programs and certifications, running on AWS Nitro Enclaves inside standard EC2 may be more appropriate. Likewise, organizations that prioritize operational simplicity, deep integration with managed services for complex workloads and applications, or traditional enterprise procurement may prefer AWS as the primary trust anchor, using Nitro Enclaves to harden specific workloads rather than adopting Dstack’s fully trust-minimized stack.

Ultimately, when it comes to cloud-services there is no one-size-fits all solution. The onus is on the consumer to evaluate pros and cons of any service in context of THEIR application and use-case.