Skip to main content

What is staging mode?

Staging holds an eligible, ready blue-green update candidate for manual acceptance while the existing container instance continues serving production traffic. It is intended for validating a release before it replaces the production-serving instance.

When to use staging mode

  • Validating a new release tag before switching production traffic
  • Manually accepting ready updates instead of relying on the automatic blue-green flip

How it works

Staging applies to blue-green relaunches of running CPU-only and single-GPU container instances. It is also available for eligible instances selected by a repository deployment update. Initial creates, starts of stopped instances, and multi-GPU updates cannot use staging. When the candidate is ready, test it through the staging ingress. Choose Accept Update to switch production traffic to it, or Cancel Update to discard it while the existing instance keeps serving production. If staging is requested for an unsupported instance in a repository deployment update, that instance reports a failure. It is not updated without staging.

Setting a repository default

Set staging as the default for eligible repository deployment updates:
New repository deployments have default_staging=false. An explicit --staging true or --staging false overrides the saved setting for one repository deployment update:

Using the CLI

The Tinfoil CLI supports the same update flow: