Deployment configuration¶

Configure shared deployment settings that control how your application runs, is verified, and is exposed across deployment models.

Source verification¶

To enable third-party verification and reproducibility of your deployment, you must specify the source repositories in your Procfile:

app_sources: https://codeberg.org/myorg/myapp

These URLs are embedded in the attestation manifest and used to pull all required source code for reproducibility.

Without app_sources, third parties cannot independently reproduce and verify your deployment.

Network connectivity¶

Caution supports two modes for exposing your application to the network.

End-to-end encryption (recommended)¶

For full security, enable end-to-end encryption using STEVE (Secure Transport Encryption via Enclave):

e2e: true

Run the app on any unreserved port. The reserved app-facing range is 49500-49600; STEVE uses port 49500 for the /e2p/* proxy path.

This requires:

1. Procfile configuration: Set e2e: true and specify your application port
2. SDK integration: Integrate the STEVE SDK into your client application

With e2e enabled, data is encrypted on the client and only decrypted inside the enclave. The STEVE proxy uses reserved port 49500 inside the enclave and forwards decrypted traffic to your application.

See the Encryption concepts page for details on how STEVE works.

Direct port exposure¶

If you cannot use end-to-end encryption, you can expose ports directly. This example uses port 3000 only as a placeholder:

run: /app/server --port 3000
ports: 3000

Use the port your application listens on. Do not declare ports in Caution's reserved 49500-49600 range.

When a single port is specified, it is automatically reverse-proxied through Caddy with TLS termination on port 443. For multiple ports, use http_port to specify which one Caddy should proxy. The rest are exposed as raw TCP (useful for P2P or binary protocols).

This establishes a connection from the enclave to the host without STEVE encryption. Traffic is still protected by TLS, but the encryption terminates outside the enclave rather than inside it.

Use this only when e2e encryption is not feasible for your use case.

Reproducibility requirements¶

For full verifiability benefits, your application must be reproducible. A reproducible build produces bit-for-bit identical outputs from the same inputs, allowing anyone to verify that your deployed binary matches your source code.

Without reproducibility, attestation can only prove that the deployment hasn't changed. It cannot prove that it matches specific source code.

Container build inputs¶

Caution uses the same Docker build shape for deployment and verification:

docker build -f <containerfile> .

The build context is the repository root, and extra Docker build arguments are not part of the Caution workflow. Values that affect the build output must be visible in the Containerfile, default ARG values, ENV instructions, or files copied into the image. This keeps the build inputs reviewable and reproducible. Use Locksmith instead of image-baked values for secrets.

Making your application reproducible¶

To build reproducible applications, use StageX, a Linux distribution designed for full-source bootstrapping and deterministic builds. While other Linux distributions can be used, StageX is recommended because it was designed as a security-first distribution.

See Verifiability for more on why reproducibility matters for confidential compute.

See also¶