Bring your own compute¶

Learn how bring your own compute works, what stays in your AWS account, and what Caution manages within that boundary.

Overview¶

Bring your own compute (BYOC) lets you run confidential enclaves in your own AWS account. A one-time setup script creates isolated AWS infrastructure and a scoped IAM identity limited to resources tagged for Caution, then Caution manages deployments within that environment.

It is best for teams that:

• Need workloads and data to stay in their own AWS account
• Need control over AWS billing and account boundaries
• Want Caution to manage enclave operations within their environment

For a side-by-side comparison with other deployment options, see deployment models.

Responsibility split¶

In bring your own compute, Caution runs the standard Docker application build and manages the enclave lifecycle in your AWS account, while you retain control over the account, network boundaries, and where data resides.

BYOC is not a private or air-gapped control plane: the normal Git deployment flow still supplies your source to Caution. Source URLs and commit metadata may be public in attestation responses even when repository access is restricted. See private-source verification.

How it works¶

To deploy with bring your own compute, you'll need a containerized application, Docker, and AWS credentials for the target account. Caution builds from the repository root with docker build -f <containerfile> .; it does not run a custom build command or pass extra Docker build arguments. Public build-time values must be part of the image inputs, and secrets should use Locksmith.

The deployment boundary for an app on the deployments lifecycle looks like this:

flowchart TB
    subgraph Operator["Your environment"]
        Repo["Application repository<br/>caution.hcl and Containerfile"]
        Setup["caution init --byoc"]
        AwsCreds["AWS credentials<br/>for provisioning"]
    end

    subgraph Caution["Caution"]
        Control["Caution control plane"]
        Build["Standard Docker build"]
        ScopedCreds["Scoped deployment credentials"]
    end

    subgraph Aws["Your AWS account"]
        Iam["Scoped IAM user<br/>tag-limited permissions"]
        Env["Provisioned AWS environment<br/>VPC, S3, roles, launch template, ASG"]
        Eip["Elastic IP<br/>held by the live deployment"]
        Ec2["EC2 parent instance<br/>one per deployment"]
        Enclave["AWS Nitro Enclave<br/>application runtime"]
    end

    Repo --> Setup
    AwsCreds --> Setup
    Setup -->|sets up| Env
    Setup --> Iam
    Iam --> ScopedCreds

    Repo -->|git push caution main| Control
    Control --> Build
    Control -->|uses| ScopedCreds
    Build -->|uploads EIF| Env
    ScopedCreds -->|manage tagged resources| Env
    ScopedCreds --> Eip
    Env --> Ec2
    Ec2 --> Enclave
    Eip --> Ec2

Once you have everything in place, the setup flow looks like this:

1. Provide AWS credentials and run the setup flow from your application directory.
2. Caution provisions an isolated environment in your AWS account and registers scoped credentials for the deployment.
3. Deploy your application and let Caution manage the enclave lifecycle within that environment.

Security model¶

Tag-based resource scoping¶

Scoped resources carry the BYOC environment tag:

caution:deployment-id = <environment-id>

This is the setup environment's identifier, not an individual blue-green deployment ID. Candidates and retained deployments within that environment share the delegated scope; the tag is not an isolation boundary between them.

The IAM policy uses AWS condition keys to enforce scope:

• aws:ResourceTag/caution:deployment-id - For existing resources
• aws:RequestTag/caution:deployment-id - For new resources

What the scoped credentials CAN do¶

• Read/write EIF images to the deployment's S3 bucket
• Start/stop/terminate EC2 instances with the deployment tag
• Create tagged standalone EC2 instances for the deployments lifecycle; legacy deployments use the ASG
• Manage volumes, security groups, and EIPs with the deployment tag
• Scale the specific Auto Scaling Group where the legacy lifecycle uses it; blue-green leaves it at zero
• Create and manage launch template versions

Scope boundaries¶

The setup policy constrains resource-changing operations to the delegated environment's tagged resources and applicable bucket, VPC, role and template permissions. It does not provide a separate credential boundary for each candidate. Do not interpret these mutation restrictions as a promise that every AWS discovery or describe operation is tag-filtered.

Review the policy actually installed by your setup version when changing permissions; the BYOC setup source is the authoritative policy definition. Keep provisioning credentials separate from the scoped credentials used for routine deployments.

Instance types¶

Caution automatically selects an appropriate Nitro Enclave-compatible instance based on your CPU and memory requirements:

The host instance reserves ~2 vCPUs and ~2 GB memory for the parent instance.

Maintenance¶

These tasks apply to existing bring your own compute deployments after provisioning, for example when you need to refresh IAM permissions or remove the AWS resources created during setup.

Updating IAM policy¶

To update the IAM policy for an existing deployment (for example, after script improvements), set DEPLOYMENT_ID and VPC_ID in your .env file, then run:

docker run --rm \
  --env-file .env \
  caution-provisioner-setup python setup.py --update-policy

Cleanup¶

To remove all resources created by the setup, see the cleanup instructions in the BYOC repo.

See also¶