chore(relay): prod deploy script — 6 regions, scale before deploy#4678
Conversation
…ploy REGIONS goes to the full prod target (sjc iad fra nrt sin gru). Scale now runs before deploy: provisioning the new-region machines first means the rolling deploy always has healthy machines elsewhere to catch host reconnects. The previous deploy-then-scale order replaced the lone sjc machine before the others existed — a single-machine outage window on the first multi-region cutover. Deploy is pinned to --strategy rolling.
|
Ready to review this PR? Stage has broken it down into 1 individual chapter for you:
Chapters generated by Stage for commit 3acae22 on May 18, 2026 3:11am UTC. |
|
Capy auto-review is paused for this organization because the monthly auto-review limit has been reached. Increase the limit or turn it off in billing settings to resume automatic reviews. |
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe deployment script for Relay is updated to implement multi-region scaling. The script now explicitly defines target regions ( ChangesMulti-region Relay Deployment
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🚀 Preview Deployment🔗 Preview Links
Preview updates automatically with new commits |
Greptile SummaryThis PR prepares
Confidence Score: 4/5Safe to merge; the scale-before-deploy reordering is well-reasoned and the rolling strategy protects against a full-fleet outage during the first cutover. The ordering change is correct and the rationale is solid. The only gap is that deploy-staging.sh now diverges — it still deploys before scaling and lacks --strategy rolling — so staging runs won't validate the same sequence that will run in prod. apps/relay/scripts/deploy-staging.sh — it no longer mirrors the prod deploy order and strategy.
|
| Filename | Overview |
|---|---|
| apps/relay/scripts/deploy.sh | Expands REGIONS from 1 (sjc) to 6, reorders scale-before-deploy, and pins rolling strategy. Logic is sound; staging script now diverges in ordering and strategy. |
Comments Outside Diff (1)
-
apps/relay/scripts/deploy.sh, line 1-5 (link)Staging script now diverges from prod
deploy-staging.shstill uses the old deploy-then-scale order and omits--strategy rolling. The file's own comment says it "mirrors deploy.sh … so we can iterate on multi-region without risking prod," but after this PR the two scripts behave differently: a staging run won't surface the rolling-deploy ordering constraint that motivated this change. Worth updatingdeploy-staging.shto match so staging runs validate the same sequence.Prompt To Fix With AI
This is a comment left during a code review. Path: apps/relay/scripts/deploy.sh Line: 1-5 Comment: **Staging script now diverges from prod** `deploy-staging.sh` still uses the old deploy-then-scale order and omits `--strategy rolling`. The file's own comment says it "mirrors deploy.sh … so we can iterate on multi-region without risking prod," but after this PR the two scripts behave differently: a staging run won't surface the rolling-deploy ordering constraint that motivated this change. Worth updating `deploy-staging.sh` to match so staging runs validate the same sequence. How can I resolve this? If you propose a fix, please make it concise.
Prompt To Fix All With AI
Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 1
apps/relay/scripts/deploy.sh:1-5
**Staging script now diverges from prod**
`deploy-staging.sh` still uses the old deploy-then-scale order and omits `--strategy rolling`. The file's own comment says it "mirrors deploy.sh … so we can iterate on multi-region without risking prod," but after this PR the two scripts behave differently: a staging run won't surface the rolling-deploy ordering constraint that motivated this change. Worth updating `deploy-staging.sh` to match so staging runs validate the same sequence.
Reviews (1): Last reviewed commit: "chore(relay): prod deploy script — 6 reg..." | Re-trigger Greptile
…ploy (#4678) REGIONS goes to the full prod target (sjc iad fra nrt sin gru). Scale now runs before deploy: provisioning the new-region machines first means the rolling deploy always has healthy machines elsewhere to catch host reconnects. The previous deploy-then-scale order replaced the lone sjc machine before the others existed — a single-machine outage window on the first multi-region cutover. Deploy is pinned to --strategy rolling.
Non-applicable to current fork structure: superset-sh#3960 and superset-sh#4068 require linux-arm64/full CLI dist targets that this fork does not ship; superset-sh#4678 targets a relay deploy script intentionally absent from the fork; superset-sh#4694 requires DuckDB native packaging but the fork has no DuckDB runtime dependency; superset-sh#4822 targets removed v1 import modal paths; superset-sh#4826 assumes upstream release-cli.yml while this fork uses build-cli.yml with draft release semantics.
Prepares
apps/relay/scripts/deploy.shfor the prod multi-region cutover.REGIONS→ full prod target:sjc iad fra nrt sin gru--strategy rolling.The relay image itself (graceful drain + multi-region routing) is already on
mainvia #4594.Summary by cubic
Update
apps/relay/scripts/deploy.shfor the prod multi‑region cutover. Scale to six regions (sjc, iad, fra, nrt, sin, gru) before deploying, then deploy with--strategy rollingto avoid downtime during the first cutover.Written for commit 3acae22. Summary will update on new commits. Review in cubic
Summary by CodeRabbit
Release Notes