Automate Deployments

This guide walks through the three most common automation setups:

Auto-Deploy Staging on Push

The most common setup — every commit to main triggers a full deploy to staging automatically.

Open the Automation tab

Go to your Project → Automation tab → click New Rule.

Pick the template

Click Browse Templates and select "Deploy staging on push to main". The template auto-fills most settings — just confirm which environment to deploy to.

Or configure manually

Trigger: Push
Branch patterns: main
Action: Deploy
Target environment: your staging environment
Cooldown: 5 minutes (prevents rapid re-deploys on a burst of commits)
Circuit breaker: 3 failures → auto-disable

Save and test

Click Create Rule. Push a commit to main — the rule fires within seconds and you'll see a new run appear in the history.

If your staging environment is already on the latest commit, the deploy still runs unless you uncheck "force". Use Quick Update action instead of Deploy for faster deploys when you haven't changed dependencies or migrations.

Production Release on Tag

Push a v1.0.0 tag → oec.sh asks for approval → after sign-off, promotes the exact build from staging to production.

Create the rule

Go to Automation → New Rule → select template "Production release on version tag", or configure manually:

Trigger: Tag Push
Tag pattern: v*
Action: Promote
Source environment: staging (the tested build)
Target environment: production

Add the approval gate

Enable Require approval and set the expiry window to 60 minutes. This gives your team time to review before the deploy executes.

Tighten the circuit breaker

Set Max consecutive failures: 1 — any production failure should pause the rule immediately and require a human to investigate and re-enable.

Release

Push your tag:

git tag v1.2.0 && git push --tags

A pending approval notification appears in the dashboard. An Admin approves it → the promote action runs → production is updated to the exact build QA signed off on staging.

⚠️

Use Promote (not Deploy) for production releases. Promote copies the exact tested build from staging — no rebuild, no surprises from dependency resolution.

Refresh Staging on Demand

Clone production data into staging with one click, automatically disabling all outgoing emails, payments, and integrations.

Create a manual rule

Go to Automation → New Rule:

Trigger: Manual
Action: Clone & Neutralize
Source: production environment
Target: staging environment
Neutralize: enabled (disables emails, crons, Stripe, OAuth, etc.)
Include filestore: your choice — disable for ~80% faster refresh

Set a cooldown

Add a 60-minute cooldown so the rule can't be accidentally triggered twice in quick succession (cloning is destructive to the target environment's data).

Trigger it

From the Automation tab, click the ▶ Run button on the rule. The clone runs in the background — you'll see progress in the run history and a notification when it's done.

⚠️

Clone & Neutralize overwrites all data in the target environment. Double-check you have source and target the right way around before running.

Viewing Run History

Every time a rule fires, a run record is created. Click on any rule to see:

What triggered it (branch, commit SHA, actor)
Current status and how long it took
Error message if it failed
Link to the deployment it created

Rules that skip (e.g. cooldown not expired, file paths didn't match) are also recorded with a reason, so you can see exactly what happened.

Troubleshooting

Rule fired but deploy didn't happen Check the run history. Status skipped means conditions weren't met — expand the run to see the skip reason (cooldown, path filter, env status mismatch).

Rule auto-disabled The circuit breaker tripped after repeated failures. Fix the underlying deploy error, then re-enable the rule from the toggle on the Automation tab.

Approval expired The approval window closed without a response. Push the tag again (or use Re-run if available) to create a new pending run.

Deploy succeeded but staging looks wrong Check if Quick Update was used when a full Deploy was needed (e.g. you added a new Python dependency or migration that Quick Update skips).

Multi-Environment Deployment Daily Operations