# Pipelines and Promotions

> Stage delivery with multi-app pipelines and promote built artifacts between environments.

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

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

* `myapp-staging` — auto-deploys on `main` push
* `myapp-production` — receives promotions from staging

The flow:

1. you merge to `main`
2. staging builds, deploys, and runs (your QA, smoke tests, manual checks happen here)
3. when staging is healthy, you promote → production gets the same image, with production's own config vars and add-ons

## 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.

## 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.

## Tips

* 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.

[View this page on the web](https://docs.watasu.io/workflows/pipelines/)