Skip to main content

​
How updates work

Tinfoil uses a blue-green update strategy: the new version boots alongside the current one, and traffic switches atomically once it reaches Ready. If the new version fails health checks, the current one keeps running — no rollback needed mid-update. Blue-green deployment
Multi-GPU containers (gpus: > 1) can’t run two versions simultaneously, so updates for them are not zero-downtime. See GPU container updates.

​
Starting an update

  1. Edit tinfoil-config.yml (image digest, env, secrets, resources), commit, and push a new Git tag
  2. Wait for the Build and Attest workflow to finish — if it fails, the tag won’t be deployable
  3. In the dashboard, click Update on the container, pick the new tag, and confirm
The current version keeps serving until the new version is Ready, then traffic switches and the old version is shut down.

​
Update statuses

StatusMeaning
PendingNew version is being deployed
StartedNew version’s enclave is running, health checks in progress
ReadyNew version is healthy and ready to accept traffic
FailedNew version failed to start

​
Multi-container updates

If your config has multiple containers, they update together. Changing one container’s image restarts all of them in the enclave.

​
Rolling back

To revert to a previous version, click Update, pick an older Git tag, and confirm. It’s the same blue-green flow — the current version keeps serving until the older version is ready.

​
Canceling an in-progress update

Click Cancel Update to stop the new version and keep the current one running. The new enclave is torn down and no traffic switches.

​
GPU container updates

Single-GPU containers use the blue-green flow like CPU containers. Multi-GPU containers (gpus: > 1) 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. If a multi-GPU update fails, the container is left in a failed state and you can retry or redeploy.

​
Auto-update on tag push

Turn on Auto update (requires GitHub App connection) to have Tinfoil deploy every new tag automatically.
  • Only tags with a successful Build and Attest workflow are deployable
  • If the new version fails to start, the current version keeps running (same blue-green guarantee)
  • Multi-GPU containers still have downtime during the switch
  • A bad config pushed as a tag will trigger an auto-update — test on a debug container first if you’re uncertain

​
Redeploying without a new tag

To re-launch a container with modified secrets or config, click Update and select Edit config. 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. This is also how you pick up updated secret values — the dashboard shows a stale secrets indicator when a redeploy is needed.

​
Recovering from a failed update

  • New version fails health checks: click Cancel Update. Deploy a debug mode instance with the new tag to investigate, fix the issue, then retry the update.
  • Update stuck in Pending or Started: the new version follows the same lifecycle as a fresh deployment — see deployment troubleshooting.
  • Auto-update didn’t fire for a pushed tag: check the Actions tab in your repo. A failed workflow means no measured release was published, so the tag isn’t deployable.