Skip to main content

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.

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

​
The Cycle

Merge to main (Mon–Thu) ──→ Deploy to staging
                                    │
                          5 PM UTC Thu: staging freezes + RC tagged
                                    │
                          Fri–Sat: canary runs daily from main
                                    │
                          Sun 9 AM UTC: canary rebuilt from main
                                    │                → release-candidate promoted to production
                                    │                + deploy/cloud/YYYY-MM-DD branch created
                          Mon 9 AM UTC: self-hosted release published

​
Cutoffs & Why

​
Staging Freeze / RC Tag — Thursday 5 PM UTC

Merges to main after 5 PM UTC on Thursday are not deployed to staging. At Thursday 5 PM UTC, the current staging image and commit are tagged as release-candidate — this is the stability gate for the week. Why: Anything merged after the Thursday cut doesn’t go to cloud production until the following week. This gives the team a predictable, stable window to validate changes before they reach customers.

​
Promotion — Sunday 9 AM UTC

At 9 AM UTC on Sunday, the cloud workflow first refreshes the canary environment by invoking continuous-delivery-canary.yml as a reusable workflow, then promotes Thursday’s release-candidate to production. Why: By Sunday, the release candidate has soaked in the canary environment (Fri–Sat). Refreshing canary again right before promotion ensures it is running the latest main when production is updated. If something is broken, we catch it before it reaches all customers. After promotion, a deploy/cloud/YYYY-MM-DD branch is created.

​
Weekly Release — Monday 9 AM UTC

On Monday at 9 AM UTC, the self-hosted release is published: git tag, GitHub release notes, and the release-candidate cloud image re-tagged as the versioned self-hosted image on Docker Hub and GHCR. Why: Publishing the day after cloud promotion means self-hosted users get the exact same bits that cloud deployed on Sunday — no separate build, no divergence. The Monday timing also allows the team to catch any issues from Sunday’s cloud deployment before the self-hosted image goes public.

​
Putting It Together

TimeWhat Happens
Mon–Thu, 9 AM–5 PM UTCMerge to main → auto-deployed to staging
Mon–Thu, 5 PM–9 AM UTCMerge to main → code in main only, staging frozen
Thu 5 PM UTCStaging image + commit tagged as release-candidate
Fri–SatCanary deploys daily from main; cloud is quiet
Sun 9 AM UTCCanary rebuilt from latest main; release-candidate promoted to cloud production; deploy/cloud/YYYY-MM-DD branch created
Mon 9 AM UTCSelf-hosted release published (re-tags cloud RC image)

​
Overrides

Sometimes the cycle needs to be bypassed:
  • Hotfix: Apply your fix to the current deploy/cloud/YYYY-MM-DD branch, then manually dispatch continuous-delivery-cloud.yml with action cloud-hotfix on that branch (not main). This builds the image and deploys directly to production — staging is not involved. After promotion, merge the hotfix branch into main — this automatically triggers tag-release-candidate, which SSHes to staging and retrags whatever image is running there as release-candidate. Sunday’s scheduled run will then re-deploy what is already on prod — a safe no-op.
  • Emergency: Use emergency-cloud-deploy.yml to deploy directly to production, bypassing staging entirely. Use sparingly.

​
FAQ

Q: I merged at 6 PM UTC on a Wednesday. When does my code reach production? Your code is in main but staging is frozen. It won’t be included in the Thursday RC tag unless it lands before 5 PM UTC Thursday. If it misses that cut, it won’t reach cloud production until the following Sunday. Q: I merged at 10 AM UTC on a Wednesday. When does my code reach production? It deploys to staging immediately. As long as nothing breaks before Thursday 5 PM UTC, it will be included in the RC tag and will reach cloud production the following Sunday. Q: Can I deploy to staging during the freeze window? Yes, manually dispatch continuous-delivery.yml with deploy-staging. But consider that the content team may be relying on the frozen version.