Skip to main content
All changes flow through a staging environment before reaching production. There are no release branches — everything merges to main.

​
How It Works

The continuous-delivery.yml workflow handles everything:
  1. Merge to main — automatically builds a Docker image and deploys to staging (stg.activepieces.com).
  2. Staging freeze (5 PM UTC) — merges to main after 5 PM UTC are accepted but not deployed to staging. The content team uses the frozen staging environment overnight.
  3. Daily promotion (9 AM UTC) — a scheduled job compares staging vs production. If they differ, staging is promoted to production. After promotion, a catch-up deploy brings staging up to the latest main.
  4. Weekly release (Sundays) — after promotion, the workflow publishes the GitHub release, creates a git tag, and builds official multi-platform Docker images (activepieces/activepieces:X.Y.Z + latest).

​
Environments

EnvironmentURLPurpose
Stagingstg.activepieces.comInternal testing, content team daily use
Productioncloud.activepieces.comLive customers

​
Hotfix Workflow

  • Normal hotfix: Merge fix to main → deploys to staging → trigger continuous-delivery.yml manually with action promote-to-production.
  • Emergency: Use emergency-cloud-deploy.yml (manual dispatch) to bypass staging and deploy directly to production.

​
Self-Hosted Release

To release a self-hosted version from any branch:
  1. Go to Actions → Release Self-Hosted → Run workflow.
  2. Select the branch and enter the release tag (e.g., 0.79.2 or 0.79.2-hotfix.1).
  3. The workflow builds multi-platform images (amd64 + arm64) and pushes to Docker Hub and GHCR.

​
GitHub Actions Workflows

We have three workflows. To run any of them manually, go to the repo’s Actions tab, select the workflow, and click Run workflow.

​
continuous-delivery.yml

The main workflow. It has three trigger paths:
TriggerWhat happens
Push to mainBuilds a Docker image and deploys to staging. Skipped automatically if the push happens during the freeze window (5 PM – 9 AM UTC).
Scheduled (daily 9 AM UTC)Compares staging vs production versions. If different, promotes staging to production (requires reviewer approval via the production GitHub Environment). After promotion, triggers a catch-up deploy to bring staging to latest main. On Sundays, also runs the weekly release (git tag, GitHub release, official Docker images).
Manual dispatchPresents a dropdown with three choices (see below).

​
Manual dispatch choices

  • deploy-staging — Re-deploy the latest main to staging. Use this after an infra change, or to override the freeze window when you know it’s safe.
  • promote-to-production — Immediately promote whatever is running on staging to production. This is the hotfix path — merge your fix to main, wait for it to deploy to staging, then trigger this to push it to prod without waiting for the next 9 AM cycle.
  • weekly-release — Manually trigger the weekly self-hosted release (git tag, publish GitHub release notes, build multi-platform Docker images). Normally this runs automatically on Sundays, but use this if a Sunday run was skipped or you need an off-cycle release.

​
emergency-cloud-deploy.yml

Break-glass workflow. Manual dispatch only, no choices — it builds from the current main and deploys directly to production, bypassing staging entirely. Use only for critical incidents where staging soak is not acceptable.

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

​
Changelog

Before each weekly release, ensure the draft GitHub release has accurate notes. PRs should be labeled correctly so the auto-generated changelog categorizes them properly.