> ## Documentation Index
> Fetch the complete documentation index at: https://www.activepieces.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Release Cycle

This page explains how code moves from merge to production and why each step exists.

## The Cycle

```
Merge to main ──→ Deploy to staging ──→ e2e-staging on that commit
                                                 │
                          Started by hand: the Cloud gate picks the newest passed commit
                                                 │
                          E2E matrix + upgrade test on the staging image
                                                 │
                          One approval ──→ canary ──→ whole Cloud fleet
```

## Steps & Why

### Staging — every merge

Each merge to `main` builds a `version.sha.beta` image, deploys it to staging, and runs the E2E suite against staging. The `e2e-staging` check on the commit records the result.

**Why**: Every commit gets tested on a real deployment, and the result stays on the commit for the gate to read.

### Cloud gate — by hand

`continuous-delivery-cloud.yml` takes the newest `main` commit whose `e2e-staging` passed. It runs the E2E matrix (four configurations) and the upgrade test from the last self-hosted release on the image staging built. The run summary lists the tickets in the candidate. One approval in the `production` environment deploys the image to the canary and then to the fleet.

**Why**: Cloud gets the exact image that staging tested. The gate runs by hand until the E2E suite covers more of the product; then it runs Sunday to Thursday at 8 AM UTC, so each deploy is small.

### Self-hosted

Self-hosted releases use `release-self-hosted.yml`. See [Releases](https://www.activepieces.com/docs/handbook/engineering/playbooks/releases.md).

## Putting It Together

| Time | What Happens |
| - | - |
| Any time | Merge to `main` → staging deploy → `e2e-staging` |
| When the release captain starts it | Cloud gate: checks, approval, canary, fleet |

## Overrides

* **Hotfix**: Merge the fix into `main`, then run `continuous-delivery-cloud.yml` by hand with `hotfix_prs`. Cloud gets only those PRs on top of what it runs, after the same checks and approval. The rest of `main` waits for the next full gate run.
* **Emergency**: Use `emergency-cloud-deploy.yml` to deploy directly to production, bypassing staging entirely. Use sparingly.

## FAQ

**Q: I merged at 10 AM UTC on a Wednesday. When does my code reach production?**
It deploys to staging immediately. If `e2e-staging` passes, the next Cloud gate run picks it up, and it reaches Cloud when the deploy is approved. Until the gate runs on a schedule, that is when the release captain starts it.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.