Skip to main content

​
How updates work

Tinfoil uses a blue-green update strategy for running CPU-only and single-GPU container instances: 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. With staging enabled, a ready candidate waits for manual acceptance instead of switching traffic automatically.
Multi-GPU containers (gpus: 8) can’t run two versions simultaneously, so updates for them are not zero-downtime. See GPU container updates.

​
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.
  • GitHub directly: Commit the config change, then run:
    You can also use Actions → Tinfoil Release → Run workflow in the GitHub UI.
Wait for both release workflow phases to finish in GitHub Actions. 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:
Publishing a release does not change a running container. The rollout starts only when you select the release in the dashboard or run container relaunch.

​
Updating a deployment

A repository deployment contains all container instances in your organization that use the same config repository. Update every eligible instance to one tag with:
To update only selected instances, repeat --instance with their container UUIDs:
New repository deployments have default_staging=false. Repository deployment updates use that saved setting unless an explicit --staging true or --staging false overrides it for one rollout. If staging is requested for an unsupported selected instance, that instance reports a failure instead of updating without staging. The CLI requires --promote-release=true|false. A true value requests promotion after a changed tag becomes production-serving, or after acceptance for a staging candidate. Promotion occurs only for a non-debug instance when the GitHub App is connected and the repository is active. Raw Admin API callers may omit promote_release, which defaults to true. Only ready 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 one tinfoil-config.yml defines multiple processes in its containers section, they run in the same enclave and update together. This is separate from a repository deployment containing multiple independently deployed container instances.

​
Rolling back

To revert to a previous version, click Update, pick an older Git tag, and confirm. CPU-only and single-GPU instances use the same blue-green flow, so the current version keeps serving until the older version is ready. Multi-GPU instances use the disruptive flow described below.

​
Canceling an in-progress update

For a blue-green 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. Multi-GPU updates cannot be canceled after replacement starts because the current instance has already been scheduled for deletion.

​
GPU container updates

Single-GPU containers use the blue-green flow like CPU containers. Multi-GPU containers (gpus: 8) use all available GPUs on the host, so there are no free GPUs to run a second copy. The control plane requests deletion of the current deployment and immediately queues its replacement. This delete-and-queue flow means there is downtime — typically while the old enclave stops and the replacement boots and loads your model. The replacement can use a different repository tag, but these updates cannot use staging or be canceled once replacement starts. 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. CPU-only and single-GPU instances use the blue-green strategy; multi-GPU instances use the delete-and-queue flow above. 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: For a blue-green update, click Cancel Update. Deploy a debug mode instance with the new tag to investigate, fix the issue, then retry the update. A failed multi-GPU replacement leaves the container in a failed state so you can retry or redeploy it.
  • Update stuck in Pending, Deploying, or Started: the new version follows the same lifecycle as a fresh deployment — see instance troubleshooting.

​
Using the CLI

See the CLI reference for all flags.