Skip to main content

​
What is staging mode?

Staging mode lets you keep a container out of automatic release updates and manually promote ready updates after testing them through Tinfoil’s staging ingress. It is intended for validating a tag before it replaces the currently serving deployment.

​
When to use staging mode

  • Validating a new release tag before switching production traffic
  • Pinning a long-lived test deployment to a specific tag
  • Manually controlling promotion instead of auto-updating on release webhooks

​
How it works

Staging containers use the same production certificate flow as normal containers. The difference is in update promotion:
ProductionStaging
Ready updatesAutomatically promotedWait for manual promotion
Auto-update on new releasesYes (when enabled)No
When an update for a staging container becomes ready, the existing deployment continues serving production traffic. The ready update candidate remains available through the Tinfoil staging ingress until you promote or cancel it. Staging mode is independent from debug mode — a container can be in staging, in debug, in both, or in neither.

​
Deploying a staging container

  1. In the All Containers tab, click Create Deployment
  2. Configure the container as normal
  3. Tick the Staging checkbox above the launch button
  4. Click Deploy in Staging
You can also tick Staging in the Update Deployment dialog or the Start Container dialog to push a new tag straight into staging without touching production.

​
Updating a staging container

A staging container is never auto-updated by a GitHub release webhook, even if Auto update is enabled on the container. To pick up a new tag, click Update, select the tag, and click Deploy in Staging. If a staging update candidate becomes ready while the container itself is already in staging, click Promote Update to switch traffic to the staged deployment, or Cancel Update to discard it.

​
Promoting to production

A staging container shows a Deploy to Prod button in its action sidebar. Click it to relaunch the container with the same tag and configuration in production mode. The new deployment goes through the normal blue/green relaunch flow and, once ready, is marked as the GitHub latest release. This is the recommended path. If you instead want to push a new tag directly to production, open the Update dialog, leave the Staging checkbox unchecked, and click Update — the same end-state is reached. The GitHub latest release is bumped only when the post-deploy mode is neither staging nor debug.