All posts · · 5 min read
Where to run a workload that has to be confidential
Nitro Enclaves, confidential VMs, dstack, chain-anchored — four places to put the part of your product the operator must not read, and how to pick one without a six-week spike.
You have decided that some part of your product must run where you, the operator, cannot read the data. A bank will not send the file otherwise; a hospital will not either; or you simply do not want to be the party holding a plaintext copy of what a competitor's customers do.
The decision after that is where the box lives. There are four practical answers, and they are not interchangeable. What follows is the short version of each, with the parts that actually decide the matter — not the marketing page.
AWS Nitro Enclaves§
A second, stripped VM carved out of an EC2 instance you already pay for. No persistent storage, no interactive access, and no network of its own: everything goes through a vsock channel on the parent instance, which you proxy. The image is an EIF, and nitro-cli build-enclave prints the measurement (PCR0) that your clients will pin.
- Verification is the easiest of the four. The document is signed by AWS's own attestation PKI, and a Synsema client verifies it against the root pinned inside the engine — full chain, COSE signature, failing closed at the first doubt.
- No sealed keys. Nitro does not derive a key from the measurement; the standard route is to release one from AWS KMS conditioned on the attestation document. Plan for that, it is real work.
- Pick it when your infrastructure is already on AWS, the counterparty is an enterprise that will accept "signed by AWS" as the root of trust, and the workload is request/response rather than a long-lived stateful service.
Confidential VMs: Intel TDX and AMD SEV-SNP§
Google Confidential Space, Azure confidential VMs, Constellation and Contrast, and the same silicon on other clouds. The unit is the whole VM: you run your container as you would anywhere, and the platform measures the image it booted.
- The smallest lift by far. Your usual deployment, your usual tooling. On Linux ≥ 6.7 the report comes from configfs-tsm with no vendor SDK in your image.
- Verification is the harder half. Today a client of these platforms verifies the quote with the vendor's collateral (Intel PCS, AMD KDS) or, on Confidential Space, checks the platform's signed token — which is ordinary JWT verification. Decide who does that before you promise it to anyone.
- Pick it when the workload is a normal service that has to stay up, keep state and scale, and when the counterparty is comfortable with the cloud provider as part of the trust story.
dstack (Phala)§
A guest agent inside a TDX VM that gives your container both the quote and keys derived from the app's identity. You mount its socket into the container and run compose as usual.
- Sealed state, without a KMS project.
attest_key("state")asks the agent for a key tied to this app; encrypt your database or your state file with it and a different build simply cannot read it. - The quote carries an event log, so a verifier can replay the measurement that covers your compose file — the deployment, not only the image.
- Pick it when you want confidential state with little ceremony, or when your users are already in that ecosystem.
Chain-anchored§
When the counterparty is not a company but a contract — settlement, a matching engine, a payout policy — the enclave's job is to produce a state the chain accepts. Synsema's guest adapters run with information-flow labels always on and the chain as the public sink, so what goes on-chain is exactly what the program declassified and nothing else.
- Pick it when the dispute you are designing against is "prove to everyone that the rule was followed", rather than "let one named counterparty check before sending a file".
The three questions that actually decide it§
1. Who must not read the data — and are they your host? If the answer includes the cloud provider, a whole-VM confidential VM on that same provider is a weaker story than an enclave with an independent attestation root. If it is your own staff and your own operators, any of the four works. 2. Who verifies, and will they really run the tooling? A confidential deployment nobody checks is an ordinary deployment with extra cost. If your counterparty's security team will run a verifier, pick the platform whose document they can check with the least effort. If they will not, buy nothing exotic: pick the one that is cheapest to operate and publish the checklist anyway. 3. Does the state have to survive a restart? Sealed keys are the dividing line. dstack derives them for you; Nitro sends you to KMS; on confidential VMs it depends on the product. Answer this before you write the schema, not after.
What to pin, and what not to§
One detail that costs teams a week: the image digest is not the measurement. A Docker/OCI digest pins what you deployed; PCR0 on Nitro, MRTD and RTMRs on TDX, measurement on SEV-SNP come from how the platform wrapped that image — the EIF build, dstack's OS image plus the compose hash, the image policy on Confidential Space. Take the expected value from the platform's own build step and publish that as what clients should expect. Pin both: the digest for your deploys, the measurement for your clients.
Where the Synsema Platform fits§
The enclave is the small part. Everything around it — the site, sign-up, the dashboard, the queue, the storage of ciphertext, billing, the cron jobs that reconcile — is ordinary software that must not be inside the box, and that part deploys here in one command with HTTPS, secrets and an audit trail. The next post is about that split, and about why making the enclave smaller is usually the highest-leverage decision in the whole design.
The engine-side details — the attest capability, the drivers, serve --attested, and the client's attestation_verify — are documented at synsema.dev.