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.
Starting an update
An update has two stages: publish a deployable release from your config repo, then roll that release out to the running container.1. Publish a release
Choose one of these approaches:-
Dashboard: Open the repo from Containers → Repositories, edit
tinfoil-config.yml, open and merge the generated pull request, then follow the Release steps. See the quickstart for the full walkthrough. -
Tinfoil CLI: Open the config pull request and trigger the release through the installed GitHub App:
-
GitHub directly: Commit the config change, then run:
You can also use Actions → Tinfoil Release → Run workflow in the GitHub UI.
repo build run prints the GitHub Actions URL where you can follow their status. If either fails, the tag is not deployable.
2. Roll out the release
In the dashboard, click Update on the container and select the new tag. From the CLI, run:container relaunch.
Updating a deployment
A deployment groups all container instances in your organization that use the same config repository. Update every eligible instance to one tag with:--instance with their container UUIDs:
--staging true or --staging false.
Only running or failed instances are eligible. Instances in any other state, or already updating, are skipped. The CLI reports each result and exits non-zero if any selected instance is skipped or fails.
Update statuses
The container’s deployment status describes the version currently serving traffic. During a blue-green update, the update candidate has a separate status:Multi-container configs
If onetinfoil-config.yml defines multiple processes in its containers section, they run in the same enclave and update together. This is separate from a deployment containing multiple independently deployed container instances.
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 instance troubleshooting.