From 5259b1e55395144e516d3a5eb257b97bd6954cd8 Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 20 Jun 2026 12:54:12 +0000 Subject: [PATCH] Run staging on a single Fly machine Staging stores sessions in machine-local SQLite with no shared volume. Fly's default deploy provisions two machines (HA), so requests after login could land on the machine that never wrote the session row, bouncing logged-in users straight back to the login page. Deploy with --ha=false and scale count 1 so each per-branch staging app runs on exactly one machine. Co-Authored-By: Claude Opus 4.8 Claude-Session: https://claude.ai/code/session_01YWAvjVEAibhwbeVgbYmg94 --- .github/workflows/staging.yml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/.github/workflows/staging.yml b/.github/workflows/staging.yml index e4486be..2a87188 100644 --- a/.github/workflows/staging.yml +++ b/.github/workflows/staging.yml @@ -49,7 +49,13 @@ jobs: "APP_URL=https://${HOST}" - name: Deploy - run: flyctl deploy --app "$APP" --config fly.staging.toml --remote-only --yes + # --ha=false so Fly provisions a single machine. Staging stores sessions + # in machine-local SQLite (no shared volume), so a second machine would + # serve requests it has no session for, bouncing logged-in users back to + # the login page. scale count 1 fixes apps already created with two. + run: | + flyctl deploy --app "$APP" --config fly.staging.toml --remote-only --yes --ha=false + flyctl scale count 1 --app "$APP" --yes - name: Summary run: echo "Deployed to https://${HOST}" >> "$GITHUB_STEP_SUMMARY"