Skip to content

chore(relay): prod deploy script — 6 regions, scale before deploy#4678

Merged
saddlepaddle merged 1 commit into
mainfrom
chore/relay-prod-multiregion
May 18, 2026
Merged

chore(relay): prod deploy script — 6 regions, scale before deploy#4678
saddlepaddle merged 1 commit into
mainfrom
chore/relay-prod-multiregion

Conversation

@saddlepaddle
Copy link
Copy Markdown
Collaborator

@saddlepaddle saddlepaddle commented May 18, 2026

Prepares apps/relay/scripts/deploy.sh for the prod multi-region cutover.

  • REGIONS → full prod target: sjc iad fra nrt sin gru
  • Reorders scale before deploy — provisioning the new-region machines first means a rolling deploy always has healthy machines in other regions to catch host reconnects. Deploy-then-scale would replace the lone existing sjc machine before the others exist → single-machine outage window on the first cutover.
  • Deploy pinned to --strategy rolling.

The relay image itself (graceful drain + multi-region routing) is already on main via #4594.


Open in Stage

Summary by cubic

Update apps/relay/scripts/deploy.sh for the prod multi‑region cutover. Scale to six regions (sjc, iad, fra, nrt, sin, gru) before deploying, then deploy with --strategy rolling to avoid downtime during the first cutover.

Written for commit 3acae22. Summary will update on new commits. Review in cubic

Summary by CodeRabbit

Release Notes

  • Chores
    • Updated deployment configuration to automatically scale the application across multiple geographic regions, improving global coverage and availability
    • Deployment process now uses a rolling update strategy to minimize service disruption and maintain uptime during releases

Review Change Stack

…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.
@stage-review
Copy link
Copy Markdown

stage-review Bot commented May 18, 2026

Ready to review this PR? Stage has broken it down into 1 individual chapter for you:

Title
1 Scale global capacity before initiating rolling deployment
Open in Stage

Chapters generated by Stage for commit 3acae22 on May 18, 2026 3:11am UTC.

@capy-ai
Copy link
Copy Markdown

capy-ai Bot commented May 18, 2026

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.

@saddlepaddle saddlepaddle merged commit e2edff2 into main May 18, 2026
10 of 11 checks passed
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 18, 2026

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: e5ff4736-af47-49b7-8e6b-9d742777c588

📥 Commits

Reviewing files that changed from the base of the PR and between 0820af1 and 3acae22.

📒 Files selected for processing (1)
  • apps/relay/scripts/deploy.sh

📝 Walkthrough

Walkthrough

The deployment script for Relay is updated to implement multi-region scaling. The script now explicitly defines target regions (sjc iad fra nrt sin gru), calculates machine count and region list from that configuration, scales machines across those regions first, and then deploys using a rolling strategy.

Changes

Multi-region Relay Deployment

Layer / File(s) Summary
Multi-region scaling and rolling deployment
apps/relay/scripts/deploy.sh
Region array updated to explicit list (sjc iad fra nrt sin gru); COUNT and REGION_LIST derived from regions. Deployment workflow reordered to run fly scale first with multi-region configuration, then fly deploy with --strategy rolling in place of prior sequential steps.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 A rabbit hops through regions six,
Scaling machines with careful tricks,
From coast to coast, the relays roll,
One swift deployment, one grand goal! 🌍✨

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch chore/relay-prod-multiregion

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 18, 2026

🚀 Preview Deployment

🔗 Preview Links

Service Status Link
Neon Database (Neon) View Branch
Vercel API (Vercel) Open Preview
Vercel Web (Vercel) Open Preview
Vercel Marketing (Vercel) Open Preview
Vercel Admin (Vercel) Open Preview
Vercel Docs (Vercel) Open Preview

Preview updates automatically with new commits

@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps Bot commented May 18, 2026

Greptile Summary

This PR prepares apps/relay/scripts/deploy.sh for the prod multi-region cutover by expanding REGIONS from (sjc) to all six target regions, reordering the steps so machines are scaled up before the deploy runs, and pinning --strategy rolling on fly deploy.

  • Scale-before-deploy ordering: provisioning new-region machines first ensures the rolling deploy always has healthy machines elsewhere to absorb reconnects, avoiding the brief single-machine outage window that deploy-then-scale would cause on first cutover.
  • --strategy rolling: serialises machine updates one-at-a-time so no two regions restart simultaneously.
  • deploy-staging.sh divergence: the staging script still uses the old deploy-then-scale order without --strategy rolling, so staging runs no longer exercise the same sequence as prod.

Confidence Score: 4/5

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

Important Files Changed

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)

  1. apps/relay/scripts/deploy.sh, line 1-5 (link)

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

    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

sazabi Bot pushed a commit that referenced this pull request May 20, 2026
…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.
MocA-Love added a commit to MocA-Love/superset that referenced this pull request May 29, 2026
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant