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) and commit your changes
  2. Trigger the Tinfoil Release workflow with a new version. Wait for both phases to finish — if either 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.

​
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.

​
Using the CLI

# Trigger a blue-green update with a new tag or config
tinfoil container relaunch my-api --tag v1.2.4
tinfoil container relaunch my-api --variable LOG_LEVEL=debug

# Inspect or control an in-progress update
tinfoil container update status my-api
tinfoil container update accept my-api    # promote a "ready" candidate (staging)
tinfoil container update cancel my-api    # discard, keep current version
See the CLI reference for all flags.