Secure Enclaves for Developers: Deploy Docker Containers in Hardware Isolation
A practical guide to running Docker containers inside secure enclaves. Learn how to deploy, attest, and manage workloads in AWS Nitro Enclaves without rewriting your application — using the Treza SDK, CLI, or REST API.

Secure enclaves used to be something only hardware engineers and security researchers worked with. You needed deep knowledge of Intel SGX programming models, custom build toolchains, and weeks of integration work to get a basic workload running.
That's changed. With AWS Nitro Enclaves and platforms like Treza, you can deploy a standard Docker container into a hardware-isolated secure enclave in minutes. No code changes. No custom SDKs. If your app runs in Docker, it runs in a secure enclave.
This guide walks through the practical details: what secure enclaves give you, how to deploy workloads, how attestation works, and the patterns that matter for production.
What Is a Secure Enclave?
A secure enclave is a hardware-isolated execution environment where the CPU enforces that no external software — including the operating system and hypervisor — can access the enclave's memory or modify its code while it's running.
The key properties:
- Encrypted memory — Enclave RAM is hardware-encrypted. Root access on the host machine cannot read it.
- No SSH, no exec — There is no interactive access to a secure enclave. Communication happens only through a constrained channel.
- No persistent storage — When the enclave terminates, all data in memory is gone. No disk forensics.
- Attestation — The hardware produces a signed document proving exactly what code is running. Remote parties can verify this without trusting the operator.
These aren't software promises — they're enforced by the CPU silicon.
Why Developers Should Care
If you're running any of these workloads, a secure enclave fundamentally changes your security posture:
Private key management — Generate and use signing keys inside the enclave. The keys never exist in host memory. Even if the host machine is compromised, the keys are inaccessible.
API secret protection — Your app connects to third-party APIs with tokens and credentials. In a standard container, anyone with host access can extract them from process memory or environment variables. In an enclave, they're hardware-encrypted.
Confidential data processing — Process medical records, financial data, or PII in a provably secure environment. Attestation gives regulators cryptographic evidence that data was handled correctly.
AI agent runtime — Autonomous agents that hold wallet keys, sign transactions, or process sensitive prompts. The enclave prevents the infrastructure operator from accessing agent secrets or interfering with execution.
Multi-tenant isolation — Run untrusted or third-party code without risk of cross-tenant data leakage, even on shared hardware.
Getting Started with Treza
Treza provides three ways to deploy secure enclaves: the SDK, the CLI, and the REST API. All three abstract the underlying AWS Nitro Enclave infrastructure so you don't need to manage EC2 instances, build enclave images, or configure vsock channels.
Option 1: SDK (TypeScript)
import { TrezaClient } from '@treza/sdk';
const treza = new TrezaClient({
baseUrl: 'https://app.trezalabs.com',
});
const enclave = await treza.createEnclave({
name: 'my-api-server',
description: 'Production API running in hardware isolation',
region: 'us-east-1',
walletAddress: '0xYourWallet...',
providerId: 'aws-nitro',
providerConfig: {
dockerImage: 'myorg/api-server:v2.1.0',
cpuCount: '2',
memoryMiB: '2048',
workloadType: 'service',
exposePorts: '8080',
},
});
console.log(`Enclave ${enclave.id} deploying...`);Option 2: CLI
# Install the CLI
npm install -g treza-cli
# Configure your endpoint
treza config set apiUrl https://app.trezalabs.com
# Deploy a Docker image into a secure enclave
treza enclave create \
--name my-api-server \
--provider aws-nitro \
--region us-east-1 \
--image myorg/api-server:v2.1.0 \
--cpu 2 \
--memory 2048
# Check status
treza enclave list --wallet 0xYourWallet...Option 3: REST API
curl -X POST https://app.trezalabs.com/api/enclaves \
-H "Content-Type: application/json" \
-d '{
"name": "my-api-server",
"region": "us-east-1",
"walletAddress": "0xYourWallet...",
"providerId": "aws-nitro",
"providerConfig": {
"dockerImage": "myorg/api-server:v2.1.0",
"cpuCount": "2",
"memoryMiB": "2048",
"workloadType": "service",
"exposePorts": "8080"
}
}'All three methods produce the same result: a Nitro Enclave running your Docker image with hardware isolation, encrypted memory, and attestation.
Understanding Attestation
Attestation is what makes secure enclaves verifiable rather than just isolated. When your enclave boots, the Nitro hypervisor measures everything loaded into it and records the results in Platform Configuration Registers (PCRs):
| PCR | Measures | Changes when |
|---|---|---|
| PCR0 | Enclave image hash | You update the Docker image |
| PCR1 | Linux kernel hash | The kernel is patched or replaced |
| PCR2 | Application hash | Application code changes |
| PCR8 | Signing certificate hash | The signing authority changes |
Verifying an Enclave
After deployment, verify that your enclave is running the expected code:
// Get the raw attestation document
const attestation = await treza.getAttestation(enclave.id);
console.log(attestation.attestationDocument.pcrs);
// { "0": "a1b2c3...", "1": "d4e5f6...", "2": "g7h8i9...", "8": "j0k1l2..." }
// Full cryptographic verification
const result = await treza.verifyAttestation(enclave.id, {
nonce: 'verify-' + Date.now(),
});
console.log(result.isValid); // true
console.log(result.trustLevel); // 'HIGH'
console.log(result.riskScore); // 5 (out of 100)You can store the expected PCR values in your CI/CD pipeline and automatically verify them after each deployment. If the values don't match, something changed in the enclave image, and the deployment should be rolled back.
Attestation in Production
For production deployments, integrate attestation verification into your trust chain:
- Build — Build your Docker image in CI, record the image hash
- Deploy — Push the image to a secure enclave via Treza
- Attest — Verify the enclave's PCR0 matches the expected image hash
- Monitor — Periodically re-verify attestation to detect runtime tampering
- Rotate — When you deploy a new version, update your expected PCR values
Workload Types
Secure enclaves support three workload patterns:
Service (Long-Running)
A continuously running process — APIs, web servers, bots, agents. The enclave stays up until you pause or terminate it.
providerConfig: {
workloadType: 'service',
dockerImage: 'myorg/api:latest',
exposePorts: '8080',
}Batch (Run-to-Completion)
A job that runs, produces output, and exits. Useful for data processing, model training, or report generation.
providerConfig: {
workloadType: 'batch',
dockerImage: 'myorg/etl-pipeline:latest',
}Daemon (Background Process)
A background service that supports other enclaves — key management, certificate rotation, log aggregation.
providerConfig: {
workloadType: 'daemon',
dockerImage: 'myorg/key-manager:latest',
}Signing Transactions from a Secure Enclave
One of the most powerful patterns is using the enclave as a blockchain signer. Private keys are generated inside the TEE and never leave:
import { TrezaClient, EnclaveSigner } from '@treza/sdk';
import { ethers } from 'ethers';
const signer = new EnclaveSigner(treza, {
enclaveId: enclave.id,
verifyAttestation: true,
});
const provider = new ethers.JsonRpcProvider('https://mainnet.base.org');
const wallet = await signer.getSigner(provider);
// Sign and broadcast — the key never leaves the enclave
const tx = await wallet.sendTransaction({
to: '0xRecipient...',
value: ethers.parseEther('0.01'),
});This is the same signing mechanism used for x402 micropayments — the enclave signs USDC transfers autonomously while keeping the private key hardware-protected.
Lifecycle Management
Manage enclave costs by pausing when idle and resuming on demand:
// Pause — stops billing, preserves configuration
await treza.enclaveLifecycleAction(enclave.id, {
action: 'pause',
walletAddress: '0xYourWallet...',
});
// Resume — back online in seconds
await treza.enclaveLifecycleAction(enclave.id, {
action: 'resume',
walletAddress: '0xYourWallet...',
});
// Terminate — permanent deletion
await treza.enclaveLifecycleAction(enclave.id, {
action: 'terminate',
walletAddress: '0xYourWallet...',
});Monitor enclave health and application output through the logs API:
const logs = await treza.getEnclaveLogs(enclave.id, {
type: 'application',
limit: 100,
});Common Patterns
Secret Injection via Attestation
Instead of injecting secrets through environment variables (which are visible on the host), use attestation-gated secret delivery:
- The enclave boots and generates an attestation document
- A secrets manager (like AWS Secrets Manager or HashiCorp Vault) verifies the attestation
- If the PCR values match, secrets are delivered over the secure vsock channel
- Secrets exist only in enclave memory — never on disk, never on the host
Multi-Enclave Architectures
Deploy multiple enclaves with different roles:
- Signing enclave — Holds private keys, only responds to verified signing requests
- Application enclave — Runs business logic, requests signatures from the signing enclave
- KMS enclave — Manages encryption keys for data at rest
Each enclave is independently attestable, so you can verify the entire chain of trust.
Secure Enclave Constraints
Be aware of the trade-offs:
- No SSH or interactive debugging — You can't exec into an enclave. Debug through logs and health endpoints.
- No persistent storage — All state is ephemeral. Use external databases for durability.
- Constrained networking — Enclaves communicate through vsock, not standard TCP/IP. Treza handles the proxying.
- Cold start time — Enclave boot takes 2-5 minutes (image pull + TEE initialization). Plan accordingly.
- Memory limits — Enclave memory is carved from the parent instance. Choose instance sizes based on workload requirements.
These constraints are features, not bugs — they dramatically reduce the attack surface.
Next Steps
- Treza documentation — Quickstart guides, attestation, and API reference
- x402 payments — Autonomous micropayments for enclave services
- Treza SDK — Open-source TypeScript SDK
- Treza Terraform — Infrastructure as Code for enclave provisioning
- MCP Registry — Discover Treza tools for AI agents
Treza builds privacy infrastructure for crypto and finance. Deploy workloads in hardware-secured enclaves with cryptographic proof of integrity. Learn more.
