Pipelines and Promotions
A pipeline groups several apps that represent stages of the same product (staging, production) and lets you move releases through them in a controlled way.
Why pipelines
Section titled “Why pipelines”Without a pipeline, every environment builds independently — staging builds from your branch, production builds from your branch, and the two artifacts technically aren’t the same image.
With a pipeline, promotion moves the artifact that staging just validated into production. No rebuild. Same bytes.
A typical shape
Section titled “A typical shape”myapp-staging— auto-deploys onmainpushmyapp-production— receives promotions from staging
The flow:
- you merge to
main - staging builds, deploys, and runs (your QA, smoke tests, manual checks happen here)
- when staging is healthy, you promote → production gets the same image, with production’s own config vars and add-ons
Promote vs. redeploy
Section titled “Promote vs. redeploy”These are not the same thing:
- promote — copy a release’s image into the next stage and let it run there with that stage’s config and add-ons
- redeploy — build from source again
Promote when you want production to run the exact build staging validated. Redeploy when you want a fresh build from current source.
Build costs
Section titled “Build costs”Source builds in every stage cost €0.50/hour by running seconds, with limits of 16 vCPU and 30 GiB RAM. They use the destination app’s billing account and require available funds. Failed and canceled builds are charged for their running time.
An image-only promotion has no build charge because it does not execute a build. The promoted app’s runtime and add-ons are billed normally. A source rebuild uses the normal temporary hold and funded deadline; see Build billing.
Required checks gate the whole pipeline
Section titled “Required checks gate the whole pipeline”If GitHub required checks are configured, the pipeline respects them. A staging deploy that depends on a check won’t proceed until the check passes; the same applies on the way to production.
- keep staging and production add-ons separate. The whole point is to validate without touching production data.
- match staging and production as closely as you can otherwise. Differences in plan size are fine; differences in code paths defeat the point.
- promote often. Long gaps between staging and production releases turn promotion into a guessing game.