Skip to main content

​
What holding does

On a new project, an update switches traffic to the new version as soon as it is running. Holding an update for review keeps the current enclave serving production while the new version boots and gets its own review URL. Nothing changes for your users until you promote the held version. Updates inherit the project’s hold default unless explicitly overridden. Use it to check a release against production configuration before it takes traffic.

​
How it works

Holding applies to blue/green updates: running CPU-only and single-GPU instances without persistent volumes. It is also available for instances selected by a project update. Initial creates and deploys of stopped or failed instances have no current version to keep serving and cannot be held. Multi-GPU updates and updates with persistent volumes stop the running enclave before deploying the new version, so they cannot be held either. The CLI’s --hold flag is available on update commands, not on create or deploy. When the held version is running, the instance card shows Held · ready to promote with its review URL. Try it there, then choose Promote to switch production traffic to it, or Cancel update to discard it while the current version keeps serving. If project-update preflight finds an eligible instance whose target release requires replacement, a requested hold returns HOLD_UNAVAILABLE before any instance is updated.

​
Setting a project default

Hold every update of a project for review by default:
New projects have hold_by_default=false. Individual updates, edited-config updates, and batch project updates inherit the saved setting. An explicit --hold=true or --hold=false overrides it for one operation, without changing the project default:

​
Using the CLI

The update command returns when the candidate is ready for review, not after promotion. It and container get print the available review URL and a verified tinfoil http get command pinned to the candidate’s repository and tag. Use that command for a one-off request, or keep the review proxy above running and use another terminal:
This local request goes through the verified proxy. A direct request to the review URL with ordinary curl does not verify attestation. --review refuses an unavailable candidate instead of silently connecting to production. Keep any port in the returned review URL; do not substitute the production domain or tag. Debug candidates still fail attestation and must not receive sensitive data. After checking the candidate, choose one action:
Promotion can mark the tag as GitHub’s repository-wide latest release if that option was enabled for the update. Use --mark-latest=false when initiating the update if you do not want that effect. Cancel discards the candidate without switching production traffic.