main.
How It Works
Five separate workflows cover the full delivery lifecycle:- Merge to
main(Mon–Thu, 9 AM–5 PM UTC) —continuous-delivery-stg.ymlautomatically builds a Docker image and deploys to staging (stg.activepieces.com). - Staging freeze (5 PM UTC) — merges to
mainafter 5 PM UTC are accepted but not deployed to staging. The content team uses the frozen staging environment overnight. - Daily 9 AM UTC —
continuous-delivery-canary.ymlbuilds aversion.sha.canaryimage from the latestmainand deploys it to the canary environment. Breaking migrations block the deployment. See the Canary Deployment playbook for details. - Thursday 5 PM UTC —
tag-release-candidatejob tags the current staging image and commit asrelease-candidate. - Sunday 9 AM UTC —
continuous-delivery-cloud.ymlruns a fresh canary build frommain(by callingcontinuous-delivery-canary.ymlas a reusable workflow), then promotesrelease-candidateto production and creates adeploy/cloud/YYYY-MM-DDbranch. - Monday 9 AM UTC —
continuous-delivery-release.ymlre-tags therelease-candidateimage and publishes the self-hosted release.
Environments
| Environment | URL | Purpose |
|---|---|---|
| Preview | branch-name.activepieces.com | Per-PR ephemeral environment for review. Requires the preview label on the PR. |
| Staging | stg.activepieces.com | Internal testing, content team daily use |
| Canary | canary.activepieces.com | Daily cut from main; catches issues before they reach production |
| Production | cloud.activepieces.com | Live customers |
Hotfix Workflow
- Checkout from the current
deploy/cloud/YYYY-MM-DDbranch (created by the last Sunday promotion). - Push your fix commit(s) to that branch.
- Manually trigger
continuous-delivery-cloud.ymlwith actioncloud-hotfixon the hotfix branch (notmain). This builds the image and deploys directly to production — staging is not involved. If the next scheduled Sunday promotion is within 1 hour, the workflow will refuse to run — just wait for the scheduled run instead. - Merge the hotfix branch into
main. This automatically triggerstag-release-candidate, which SSHes to staging and retrags whatever image is running there asrelease-candidate. Sunday’s scheduled run will re-deploy — a safe no-op.
Self-Hosted Release
The weekly self-hosted release runs automatically on Mondays at 9 AM UTC. It re-tags therelease-candidate cloud image as the versioned self-hosted image — no separate build required.
For off-cycle or hotfix releases from any branch, use release-self-hosted.yml (see below).
GitHub Actions Workflows
To run any workflow manually, go to the repo’s Actions tab, select the workflow, and click Run workflow.continuous-delivery-stg.yml — Staging
| Trigger | What happens |
|---|---|
Push to main | Builds a version.sha.beta image and deploys to staging. Skipped automatically during the freeze window (5 PM – 9 AM UTC). |
| Manual dispatch | Presents a dropdown with two choices (see below). |
Manual dispatch choices
deploy-staging— Re-deploy the latestmainto staging. Use this after an infra change, or to force a deploy that was skipped due to the freeze window.deploy-staging-skip-freeze— Same as above but explicitly bypasses the freeze window check.
continuous-delivery-cloud.yml — Production Promotion
| Trigger | What happens |
|---|---|
| Scheduled (Sunday 9 AM UTC) | Triggers continuous-delivery-canary.yml as a reusable workflow to refresh the canary environment from the latest main, then promotes release-candidate to production (requires approval via the production GitHub Environment). After promotion, creates a deploy/cloud/YYYY-MM-DD branch and runs a smoke test. |
workflow_call | Same as above, triggered by another workflow. |
Manual dispatch — cloud-hotfix | Builds the image from the current branch and deploys directly to production, bypassing staging. Trigger this on the hotfix branch (deploy/cloud/YYYY-MM-DD), not main. After promotion, merge the hotfix branch into main to automatically retag release-candidate. Blocked automatically if the next scheduled Sunday promotion is within 1 hour. |
continuous-delivery-release.yml — Weekly Release
| Trigger | What happens |
|---|---|
| Scheduled (Mondays 9 AM UTC) | Publishes a GitHub release with changelog, creates a git tag, and re-tags ghcr.io/activepieces/activepieces-cloud:release-candidate as activepieces/activepieces:X.Y.Z + latest on Docker Hub and GHCR. |
| Manual dispatch | Same as above, on demand. Use this if a Monday run was skipped or you need an off-cycle release. |
continuous-delivery-canary.yml — Canary
| Trigger | What happens |
|---|---|
| Scheduled (daily 9 AM UTC) | Builds a version.sha.canary image from the latest main, checks migrations, deploys the canary app and workers. Breaking migrations always block the deployment. |
workflow_call | Same as scheduled, triggered by continuous-delivery-cloud.yml on the Sunday promotion so the canary always receives a fresh build just before production is updated. |
| Manual dispatch | Same as scheduled, on demand. |
continuous-delivery-rollback-canary.yml — Canary Rollback
Manual dispatch only. Rolls back the canary environment to a previous image tag. Reverses DB migrations not present in the target image’s manifest, then redeploys the canary app and workers to that tag.
| Input | Description |
|---|---|
rollback_to_image_tag | Target image tag to roll back to (e.g. 0.51.0.abc1234.canary). Leave blank to roll back to the current cloud production image. |
force | Force rollback even if breaking migrations exist. Default: false. |
release-self-hosted.yml
Manual dispatch only. Prompts for a release tag (e.g., 0.79.2 or 0.79.2-hotfix.1). Builds multi-platform images (amd64 + arm64), pushes to Docker Hub and GHCR, and creates a git tag. Can be run from any branch — useful for patching older versions.