Up to now you have deployed when you were ready. Once the floor depends on the platform, a deploy at 6:55 on a Monday that breaks the operator screen stops the start-up meeting. The answer is not to deploy less. It is to make every deploy small, checked and easy to undo, so it stops being an event.

One path for every change

You built most of this path in Sessions 1 and 17: the protected main branch, the required CI checks, the OWASP Top 10 suite and Vercel's preview addresses. Today you put it in writing and make sure nothing can skip it. GitHub's branch protection is what makes the path compulsory: with Require a pull request before merging and Require status checks to pass switched on, and bypassing switched off, not even an owner can push straight to main ^[1].

Three environments, three databases

A preview that points at the production database is a production deploy with a different address: a half-finished migration or a test that deletes rows hits real records. Keep a staging database for previews, loaded with the synthetic data from Session 4.

Start with the free way. In Vercel, set the database address for the Preview environment to the staging project and for Production to the production project; Vercel keeps a separate value per environment ^[6]. You type both values into Vercel's settings page yourself. They never go into a chat, a prompt or a file.

Database changes travel as migrations

Every change to the schema is a numbered SQL file in supabase/migrations/, committed with the code that needs it. The Supabase command-line tool creates the file (supabase migration new add_scrap_reason), applies all files to a fresh local database to prove they run in order (supabase db reset) and applies new ones to a linked project (supabase db push) ^[7]. A migration that has run in production is never edited; a correction is a new migration.

# .github/workflows/deploy-db.yml: apply new migrations to staging on every pull request, to production on merge.
name: Database migrations
on:
  pull_request:
  push:
    branches: [main]
jobs:
  migrate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: supabase/setup-cli@v1
      # The project id, access token and password are GitHub Actions secrets, typed into GitHub's settings by a person.
      - run: supabase link --project-ref "$PROJECT"
        env:
          PROJECT: ${{ github.event_name == 'push' && secrets.PROD_PROJECT_REF || secrets.STAGING_PROJECT_REF }}
          SUPABASE_ACCESS_TOKEN: ${{ secrets.SUPABASE_ACCESS_TOKEN }}
          SUPABASE_DB_PASSWORD: ${{ github.event_name == 'push' && secrets.PROD_DB_PASSWORD || secrets.STAGING_DB_PASSWORD }}
      - run: supabase db push
        env:
          SUPABASE_ACCESS_TOKEN: ${{ secrets.SUPABASE_ACCESS_TOKEN }}
          SUPABASE_DB_PASSWORD: ${{ github.event_name == 'push' && secrets.PROD_DB_PASSWORD || secrets.STAGING_DB_PASSWORD }}

Change the schema without breaking the running version

During a deploy, and after any rollback, the old version of the app runs against the new database. So a migration must suit both versions. The pattern is called expand and contract (also parallel change) ^[8]: add the new thing, move code and data across, and remove the old thing only in a later release, once nothing reads it.

• Safe in one step: add a table, add a nullable column, add an index, add a view.
• Needs expand and contract: rename or drop a column or table, change a column's type, make a column required.
• Row-level security: a new table arrives with its policies in the same migration (Session 7). A table without them never reaches production.

Measure the pipeline

Google's DevOps Research and Assessment programme (DORA) has measured software teams for more than a decade and found that speed and stability go together: teams that deploy small changes often also break things less and recover faster ^[9]. Four measures are enough:

These targets suit a plant platform with one or two owners; they are a starting point, not a DORA benchmark. Write your own in the runbook and check them monthly.

Rolling back a bad deploy

Vercel keeps every deployment it has built. The production address is a pointer to one of them, so going back is a matter of moving the pointer, with no rebuild. Vercel calls this Instant Rollback: from the project's Deployments page, open the menu on an earlier production deployment and choose Instant Rollback ^[1]. On the free Hobby plan you can return to the previous production deployment; paid plans can choose older ones ^[1].

• After a rollback, new merges do not go live by themselves until you promote a deployment again. That is deliberate: a second broken merge cannot undo your rollback ^[1].
• A rollback does not touch the database. If the bad release ran a migration, the old code now runs on the new schema. That is why chapter 1's expand-and-contract rule matters: it keeps the previous version compatible.
• A rollback does not change environment variables. If the problem was a wrong setting, fix the setting and redeploy; Vercel applies variable changes only to new deployments ^[2].

Backups: what you are promising

Before choosing a backup tool, decide two numbers with the people who use the platform. NIST's contingency planning guide defines them ^[3]:

Write both numbers in the runbook. They decide how often you back up (at least as often as the RPO) and how practised the restore must be (faster than the RTO, with time to spare).

Choosing a backup plan, free way first

Database backups do not include files in Supabase Storage, such as photos attached to a quality record ^[6]. If your platform stores files, back up the bucket too, or keep files somewhere that has its own backups.

The free way, written as a workflow. The three export commands follow Supabase's own backup guide ^[9]; underneath they run PostgreSQL's standard pg_dump tool, so the files restore into any Postgres database, not only Supabase ^[10].

# .github/workflows/backup.yml: a nightly, encrypted export of the production database.
name: Nightly backup
on:
  schedule:
    - cron: "17 7 * * *"   # 07:17 UTC = 3:17 AM Eastern in summer (2:17 AM in winter)
  workflow_dispatch:        # a Run workflow button for drills
jobs:
  backup:
    runs-on: ubuntu-latest
    steps:
      - uses: supabase/setup-cli@v1
      - name: Export roles, schema and data
        env:
          DB_URL: ${{ secrets.PROD_DB_URL }}            # typed into GitHub's settings by a person
        run: |
          supabase db dump --db-url "$DB_URL" -f roles.sql --role-only
          supabase db dump --db-url "$DB_URL" -f schema.sql
          supabase db dump --db-url "$DB_URL" -f data.sql --use-copy --data-only
      - name: Encrypt
        env:
          PASS: ${{ secrets.BACKUP_PASSPHRASE }}       # also kept in the company password manager
        run: tar czf - roles.sql schema.sql data.sql | gpg --batch --symmetric --cipher-algo AES256 --passphrase "$PASS" -o backup.tgz.gpg
      - uses: actions/upload-artifact@v4
        with:
          name: backup-${{ github.run_id }}
          path: backup.tgz.gpg
          retention-days: 30

A backup you have not restored is a hope

The only proof is a restore. Restore into the staging project, never into production, and time it from "start" to "a supervisor can open yesterday's records". Supabase's guide restores the three files with one command ^[9]:

# Run on your laptop, in a terminal, after decrypting the backup. STAGING_DB_URL is read from your password manager
# into the terminal session; it is never pasted into a chat or saved in a file.
gpg --decrypt backup.tgz.gpg | tar xzf -
psql --single-transaction --variable ON_ERROR_STOP=1 \
  --file roles.sql --file schema.sql \
  --command 'SET session_replication_role = replica' \
  --file data.sql --dbname "$STAGING_DB_URL"

1. Note the time. Download last night's artifact from the workflow run page.
2. Decrypt and restore into staging with the command above.
3. Point a preview at staging (it already is) and open yesterday's records as a supervisor.
4. Count rows in two key tables in production and in staging; they should match last night's numbers.
5. Note the time. Write the date, who did it and the minutes taken in the runbook's drill log.

What goes in a runbook

Google's site reliability engineers describe the value plainly: written procedures, practised in advance, roughly triple the speed of recovery compared with improvising ^[1]. You do not need their scale. You need one page per procedure, in plain words, that a supervisor or IT colleague can follow.

Generate the first draft, then make it true

Your repository already knows most of the runbook: the workflows, the environment variable names (never their values), the migrations, the health page. Ask your coding agent to draft it from the repository, then correct it by doing every procedure. The draft saves an hour; the drills are what make it trustworthy.

Read this repository: .github/workflows, vercel.json, supabase/migrations, app/api/health and the README.
Write docs/runbook.md with these sections: What it is; Who to call (leave names as a table for me to fill in);
Deploy; Roll back (Vercel Instant Rollback); Restore a backup (from the nightly backup workflow, into staging first);
Rotate a key (list every environment variable NAME the code reads and where each is set; never print a value);
Known problems (empty table: symptom, check, fix); Drill log (empty table: date, who, procedure, minutes, changes).
Plain language for a shift supervisor. Every step names the exact page or command. Open a pull request.

Know before the floor calls

A health page is a small route that checks the app can reach the database and answers ok or an error. An uptime monitor opens it every few minutes and alerts you when it fails. Free monitors exist, such as UptimeRobot's free plan ^[2]; a scheduled GitHub Actions workflow can also do it at no cost, though GitHub may delay scheduled runs at busy times ^[3].

// app/api/health/route.ts: answers 200 when the app can read from the database, 503 when it cannot.
import { createClient } from "@supabase/supabase-js";

export const dynamic = "force-dynamic";
export async function GET() {
  const started = Date.now();
  const db = createClient(process.env.NEXT_PUBLIC_SUPABASE_URL!, process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!);
  // A public, harmless read: a one-row table the matrix opens to everyone, holding the current schema version.
  const { error } = await db.from("platform_status").select("schema_version").limit(1);
  const body = { ok: !error, ms: Date.now() - started, version: process.env.VERCEL_GIT_COMMIT_SHA?.slice(0, 7) };
  return Response.json(body, { status: error ? 503 : 200, headers: { "Cache-Control": "no-store" } });
}

The health page reports no records and no keys, only whether the parts talk to each other and which version is live. Add /api/health to the matrix as open to all, and point the pipeline's smoke check (gate 8) at it too.

Running an incident

NIST's incident response guide, revised in 2025, frames incident response as part of everyday risk management: prepare, detect, respond, recover, and feed what you learn back into preparation ^[4]. For a plant platform that comes down to five habits:

1. Detect. The monitor alerts, or a supervisor calls. Write the time down.
2. Triage. What is broken (one screen, everything), since when (match it to the last deploy in Vercel), how many people are affected.
3. Mitigate. If the last deploy is the likely cause, roll back. If the database is the cause, switch the floor to the paper fallback and follow the restore page. Tell the floor what to do in one sentence.
4. Fix. The real fix is a normal change through the pipeline, reviewed and tested. Never edit production by hand under pressure.
5. Review. Within a week, write one page: what happened, the timeline, what helped, what will change. Blame the system, not the person, so people keep reporting problems early ^[5].

Rotating a key without an outage

Keys leak: a laptop is lost, a contractor leaves, a key is pasted somewhere it should not be. Rotation is the routine that makes a leak a non-event. Supabase's newer API keys support several secret keys at once, so a new one can be created, deployed and proven before the old one is revoked ^[6]. Vercel only uses a changed variable in deployments made after the change, so a redeploy is part of every rotation ^[7]. OWASP's secrets guidance adds the rest: rotate on a schedule and at once after any suspected exposure, and record every rotation ^[8].