Deployment lifecycle
The dashboard shows three statuses:
| Status | Description |
|---|
| Deploying | Image is being pulled and the enclave is booting |
| Running | Container is live and serving traffic |
| Failed | Something went wrong — check your config and Docker image |
Updates
Non-GPU containers use a blue-green deployment strategy, running both versions simultaneously:
If the new version fails, the update is canceled and the current version keeps running.
No downtime and no rollback required.
Starting an update
- Update
tinfoil-config.yml (e.g. change the image digest), commit, and push a new Git tag
- If you included the GitHub Actions workflow from the template repo, this automatically creates a pre-release on GitHub
- In the dashboard, click Update on the container you want to update
- In the modal, select a new Git tag and confirm
The current version keeps serving traffic while the new version boots up.
Other update options
The Update modal also supports:
- Edit config — redeploy the container with modified configuration parameters (e.g. updated secrets, resource changes). The container is redeployed using the same tag but with the new config.
- Deploy to prod — promote a debug container to a production enclave (see debug mode).
All update options use the same blue-green deployment strategy described above.
Update statuses
| Status | Description |
|---|
| Pending | New version is being deployed |
| Started | New version’s enclave is running, health checks in progress |
| Ready | New version is healthy and ready to accept traffic |
| Failed | New version failed to start |
GPU containers
GPU containers use all available GPUs on the host, so there are no
free GPUs to run a second copy. Updates stop the current deployment before
starting the new one, which means there is downtime — typically while
the new enclave boots and loads your model.
DNS records are kept in place during the transition so clients reconnect
automatically once the new version is ready. The dashboard shows a two-phase
progress indicator: stopping the old deployment, then deploying the new one.
If the new deployment fails, the container is left in a failed state and you
can retry or redeploy.
Redeploying
To re-launch a container with modified configuration, click Update on the container and select Edit config. This is useful when:
- You’ve updated secrets and need the container to pick up new values
- A deployment failed and you’ve fixed the underlying issue
The modal opens pre-populated with the container’s current config. You can change settings before submitting. The redeployment uses the same blue-green strategy.
Deleting a container
Click Delete on a container to permanently remove it. This:
- Stops the running enclave
- Cancels any in-progress update
- Deletes the container’s secret bindings
- Removes the container from your org
Deletion is irreversible. The container’s configuration, secret bindings,
and environment variables are permanently removed.
