GitHub Actions Runbooks

NOTE

Use this page as a prompt reference. Every file below is built to be handed straight to an AI. Download it, drop it into Claude, ChatGPT, Cursor, or Lovable, and say "use this as my playbook." The prompts on this page are copy-paste ready.

NOTE

Action versions in these files are current as of July 2026: actions/checkout@v7, actions/setup-node@v6, actions/github-script@v8. First-party actions/* are fine on floating major tags; anything third-party (like peter-evans/create-pull-request) should be pinned to a full commit SHA. More in the secrets section.

WATCH OUT

The built-in GITHUB_TOKEN defaults matter. Go to Settings -> Actions -> General -> Workflow permissions and set the default to Read repository contents. Every runbook here declares the exact permissions it needs on top of that (issues: write, pull-requests: write, etc.), so nothing breaks, and a compromised dependency in one workflow can't push commits.

# deploy-with-migrations.yml
# Production deploy: test -> migrate DB -> deploy to Vercel -> alert on failure.
# Action versions current as of July 2026 (checkout v7, setup-node v6).
#
# SECRETS REQUIRED (Settings -> Secrets and variables -> Actions):
#   VERCEL_TOKEN        - Vercel access token (vercel.com/account/tokens, scope to one project if on a team)
#   VERCEL_ORG_ID       - from .vercel/project.json after running `vercel link` locally
#   VERCEL_PROJECT_ID   - same file
#   DATABASE_URL        - production Postgres connection string. Use the DIRECT
#                         (or session-mode) string, not the transaction pooler:
#                         prisma migrate fails through transaction pooling.
#   ALERT_WEBHOOK_URL   - Slack or Discord incoming webhook URL
#
# ONE-TIME SETUP:
#   1. Run `vercel link` locally, copy the two IDs from .vercel/project.json into secrets.
#   2. Disable Vercel's Git auto-deploy for this project (or set "git": { "deploymentEnabled": false }
#      in vercel.json). Otherwise Vercel and this workflow will both deploy every push and race.
#   3. Swap the migration command for your tool (prisma / drizzle / whatever you use).

name: Deploy to production

on:
  push:
    branches: [main]
  workflow_dispatch: {} # manual "Run workflow" button, useful for redeploys

# Deploys must never overlap. Same group name for every run of this workflow,
# cancel-in-progress: false means a second push QUEUES behind the running deploy
# instead of killing it mid-migration. GitHub keeps at most one run queued;
# older queued runs get superseded, which is what you want.
concurrency:
  group: production-deploy
  cancel-in-progress: false

env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    # Least privilege: this job only needs to read the repo.
    permissions:
      contents: read
    # Optional but recommended: create a "production" environment in
    # Settings -> Environments and move DATABASE_URL there. You can then add
    # required reviewers or a wait timer in front of prod deploys.
    environment:
      name: production
      url: ${{ steps.deploy.outputs.url }}

    steps:
      - name: Check out code
        uses: actions/checkout@v7

      - name: Set up Node
        uses: actions/setup-node@v6
        with:
          node-version: 22
          cache: npm # v6 only auto-caches npm; set 'pnpm' or 'yarn' explicitly if you use those

      - name: Install dependencies
        run: npm ci # ci, not install: exact lockfile versions, fails loudly on drift

      # Gate: broken code should never reach the migration step, let alone prod.
      - name: Run tests
        run: npm test

      # ---- DATABASE MIGRATION ----
      # Runs BEFORE the deploy so new code never talks to an old schema.
      # This ordering means migrations must be backward-compatible:
      # old code (still serving traffic) must survive the new schema for
      # the ~60s until the deploy finishes. Additive changes (new tables,
      # new nullable columns) are safe. Renames and drops are two-deploy jobs.
      - name: Run database migrations
        env:
          DATABASE_URL: ${{ secrets.DATABASE_URL }}
        run: npx prisma migrate deploy
        # drizzle:  npx drizzle-kit migrate
        # raw SQL:  psql "$DATABASE_URL" -f migrations/latest.sql
        # none yet: delete this step, add it back when you have a DB

      # ---- VERCEL DEPLOY (build here, ship prebuilt output) ----
      # vercel pull  = fetch project settings + prod env vars into .vercel/
      # vercel build = build locally on this runner using those settings
      # deploy --prebuilt = upload the finished build; Vercel never rebuilds
      - name: Install Vercel CLI
        run: npm install --global vercel@latest

      - name: Pull Vercel production settings
        run: vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}

      - name: Build
        run: vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}

      - name: Deploy to production
        id: deploy
        run: |
          url=$(vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }})
          echo "url=$url" >> "$GITHUB_OUTPUT"
          echo "Deployed: $url"

      # ---- FAILURE ALERT ----
      # if: failure() makes this run ONLY when an earlier step failed.
      # Works with Slack and Discord; both accept a JSON body on their
      # incoming webhook URL (Discord wants "content", Slack wants "text",
      # sending both keys works for either).
      - name: Alert on failure
        if: failure()
        env:
          WEBHOOK: ${{ secrets.ALERT_WEBHOOK_URL }}
        run: |
          msg="Production deploy FAILED on ${GITHUB_REPOSITORY}@${GITHUB_REF_NAME}. Run: ${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID}"
          curl -sS -X POST -H 'Content-Type: application/json' \
            -d "{\"text\": \"$msg\", \"content\": \"$msg\"}" \
            "$WEBHOOK"

WATCH OUT

The thing that bites people: Vercel deploys twice. If Vercel's Git integration is still connected, Vercel auto-deploys your push AND this workflow deploys it, racing each other and occasionally shipping the version that skipped your tests. Disable auto-deploy (disconnect the Git integration, or set "git": {"deploymentEnabled": false} in vercel.json) so Actions is the only thing that ships.

# nightly-backup.yml
# Nightly pg_dump of your Postgres (Supabase / Neon / any Postgres) to
# Cloudflare R2, with 30-day retention pruning and a failure alert.
#
# SECRETS REQUIRED:
#   DATABASE_URL         - Postgres connection string. For Supabase use the
#                          DIRECT (non-pooled, port 5432) connection string;
#                          pg_dump through a transaction pooler can fail.
#   R2_ACCOUNT_ID        - Cloudflare account ID (dashboard -> R2 -> right sidebar)
#   R2_ACCESS_KEY_ID     - from an R2 API token, scoped to ONE bucket, Object Read & Write only
#   R2_SECRET_ACCESS_KEY - same token
#   ALERT_WEBHOOK_URL    - Slack/Discord incoming webhook
#
# ONE-TIME SETUP:
#   1. Create an R2 bucket (example name below: "db-backups"). R2 has zero
#      egress fees, which is why it beats S3 for backups you hope to never read.
#   2. Create an R2 API token: Object Read & Write, limited to that one bucket.
#      R2 does not accept GitHub OIDC, so these are real keys; scope them hard.
#   3. Change BUCKET below to your bucket name.

name: Nightly database backup

on:
  schedule:
    # 03:17 UTC. Odd minute on purpose: :00 crons queue behind everyone
    # else's :00 crons and get delayed 5-30 min, sometimes skipped entirely.
    - cron: "17 3 * * *"
  workflow_dispatch: {} # always keep a manual trigger next to schedule

env:
  BUCKET: db-backups # <- your R2 bucket name
  PREFIX: postgres # folder inside the bucket

jobs:
  backup:
    runs-on: ubuntu-latest
    permissions:
      contents: read

    steps:
      # Match pg_dump's major version to your server. Supabase and Neon run
      # Postgres 15-17 depending on project age; ubuntu-latest ships an older
      # client, and pg_dump refuses to dump a server NEWER than itself.
      # Installing the v17 client dumps any server up to 17.
      - name: Install Postgres 17 client
        run: |
          sudo apt-get -qq update
          sudo apt-get -qq install -y postgresql-common
          sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh -y
          sudo apt-get -qq install -y postgresql-client-17

      - name: Dump database
        env:
          DATABASE_URL: ${{ secrets.DATABASE_URL }}
        run: |
          STAMP=$(date -u +%Y%m%dT%H%M%SZ)
          echo "STAMP=$STAMP" >> "$GITHUB_ENV"
          # --no-owner --no-privileges: restores cleanly to a different
          # project/role, which is exactly the disaster scenario.
          pg_dump "$DATABASE_URL" --no-owner --no-privileges \
            | gzip > "backup-${STAMP}.sql.gz"
          ls -lh backup-*.sql.gz

      # Sanity check: an "empty" dump usually means a wrong URL or a pooler
      # issue, and it exits 0 anyway. Fail if the file is suspiciously small.
      - name: Verify dump is not empty
        run: |
          SIZE=$(stat -c%s backup-${STAMP}.sql.gz)
          echo "Dump size: $SIZE bytes"
          if [ "$SIZE" -lt 1024 ]; then
            echo "Dump under 1KB, something is wrong"; exit 1
          fi

      # AWS CLI is preinstalled on ubuntu-latest and speaks R2's S3 API.
      # The two CHECKSUM env vars are REQUIRED: AWS CLI v2.23+ sends CRC32
      # integrity checksums by default and R2 rejects them.
      - name: Upload to Cloudflare R2
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.R2_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.R2_SECRET_ACCESS_KEY }}
          AWS_DEFAULT_REGION: auto
          AWS_REQUEST_CHECKSUM_CALCULATION: when_required
          AWS_RESPONSE_CHECKSUM_VALIDATION: when_required
          ENDPOINT: https://${{ secrets.R2_ACCOUNT_ID }}.r2.cloudflarestorage.com
        run: |
          aws s3 cp "backup-${STAMP}.sql.gz" \
            "s3://${BUCKET}/${PREFIX}/backup-${STAMP}.sql.gz" \
            --endpoint-url "$ENDPOINT"

      # ---- 30-DAY RETENTION ----
      # Delete objects older than 30 days. rclone does this in one line and
      # its Cloudflare provider mode auto-handles R2 quirks.
      - name: Prune backups older than 30 days
        env:
          RCLONE_CONFIG_R2_TYPE: s3
          RCLONE_CONFIG_R2_PROVIDER: Cloudflare
          RCLONE_CONFIG_R2_ACCESS_KEY_ID: ${{ secrets.R2_ACCESS_KEY_ID }}
          RCLONE_CONFIG_R2_SECRET_ACCESS_KEY: ${{ secrets.R2_SECRET_ACCESS_KEY }}
          RCLONE_CONFIG_R2_ENDPOINT: https://${{ secrets.R2_ACCOUNT_ID }}.r2.cloudflarestorage.com
        run: |
          curl -fsSL https://rclone.org/install.sh | sudo bash
          rclone delete "r2:${BUCKET}/${PREFIX}/" --min-age 30d --s3-no-check-bucket
          echo "Current backups:"
          rclone ls "r2:${BUCKET}/${PREFIX}/"

      # Optional dead-man's-switch: GitHub silently skips crons under load and
      # auto-disables schedules after 60 days of repo inactivity. Pinging an
      # external monitor (healthchecks.io free tier) on success means you get
      # an email when the backup STOPS happening, not just when it fails.
      # - name: Ping healthcheck
      #   run: curl -fsS https://hc-ping.com/YOUR-UUID-HERE

      - name: Alert on failure
        if: failure()
        env:
          WEBHOOK: ${{ secrets.ALERT_WEBHOOK_URL }}
        run: |
          msg="Nightly DB backup FAILED for ${GITHUB_REPOSITORY}. Run: ${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID}"
          curl -sS -X POST -H 'Content-Type: application/json' \
            -d "{\"text\": \"$msg\", \"content\": \"$msg\"}" \
            "$WEBHOOK"

# RESTORE TEST (do this once a quarter, on the calendar, for real):
#   1. Download the latest backup from R2.
#   2. Create a throwaway Postgres (new Neon branch or local Docker).
#   3. gunzip -c backup-XXXX.sql.gz | psql "$THROWAWAY_URL"
#   4. Row-count 2-3 important tables against prod.
# A backup you have never restored is a hope, not a backup.

WATCH OUT

The thing that bites people: never testing a restore. An untested backup is a hope, not a backup. Once a quarter: download the newest dump, spin up a throwaway Postgres (Neon branch or local Docker), gunzip -c backup.sql.gz | psql $THROWAWAY_URL, and row-count 2-3 important tables against prod. The restore procedure is written at the bottom of the workflow file so it's there when you're panicking.

# uptime-and-errors.yml
# Poor man's uptime monitor: every 10-ish minutes, hit your homepage and one
# key API route. Anything but a 200 fires your Slack/Discord webhook.
#
# HONEST FRAMING: GitHub's cron is best-effort. Expect 5-30 min delays at
# busy hours and occasional silently skipped runs. This is a free safety net,
# not a pager. If your SaaS has paying users, add a real external monitor
# (UptimeRobot / Better Stack free tiers) and keep this as the second opinion
# that also hits a health route backed by a real DB query, which dumb pingers don't.
#
# SECRETS REQUIRED:
#   ALERT_WEBHOOK_URL - Slack/Discord incoming webhook
# (URLs below are plain env vars, they are not secret.)

name: Uptime and error check

on:
  schedule:
    # every 10 min, offset to :07 to dodge the top-of-the-hour cron rush.
    # 5 min is GitHub's minimum interval; more frequent is silently ignored.
    - cron: "7,17,27,37,47,57 * * * *"
  workflow_dispatch: {}

env:
  PROD_URL: https://yourapp.com # <- your production URL
  API_URL: https://yourapp.com/api/health # <- a route that touches your DB

jobs:
  check:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    # If a check hangs, don't burn 6 hours of Actions minutes (the default
    # job timeout). Kill it fast; the next scheduled run is minutes away.
    timeout-minutes: 3

    steps:
      # No checkout needed: this job never touches your code.

      # curl flags, decoded:
      #   -s silent  -o /dev/null throw away the body
      #   -w "%{http_code}" print only the status code
      #   --max-time 20  a "slow" site is a down site for users
      #   --retry 2 --retry-delay 5  one blip should not page you at 3am;
      #     retries happen inside this step, 5s apart
      - name: Ping homepage
        id: home
        run: |
          code=$(curl -s -o /dev/null -w "%{http_code}" \
            --max-time 20 --retry 2 --retry-delay 5 "$PROD_URL" || echo "000")
          echo "code=$code" >> "$GITHUB_OUTPUT"
          echo "Homepage: $code"
          [ "$code" = "200" ] || exit 1

      # A health route should hit the DB (e.g. SELECT 1) so this catches
      # "site renders but database is on fire", the classic silent outage.
      - name: Ping API health route
        id: api
        # Run even if the homepage check failed, so the alert names both.
        if: always()
        run: |
          code=$(curl -s -o /dev/null -w "%{http_code}" \
            --max-time 20 --retry 2 --retry-delay 5 "$API_URL" || echo "000")
          echo "code=$code" >> "$GITHUB_OUTPUT"
          echo "API: $code"
          [ "$code" = "200" ] || exit 1

      - name: Alert on failure
        if: failure()
        env:
          WEBHOOK: ${{ secrets.ALERT_WEBHOOK_URL }}
          HOME_CODE: ${{ steps.home.outputs.code }}
          API_CODE: ${{ steps.api.outputs.code }}
        run: |
          msg="DOWN ALERT: ${PROD_URL} returned ${HOME_CODE:-?}, API returned ${API_CODE:-?} (000 = timeout/DNS/conn refused). Run: ${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID}"
          curl -sS -X POST -H 'Content-Type: application/json' \
            -d "{\"text\": \"$msg\", \"content\": \"$msg\"}" \
            "$WEBHOOK"

# CAVEATS THAT BITE:
# - 60-day auto-disable: GitHub disables scheduled workflows after 60 days
#   with no commits to the repo. If your project is "done", your monitor
#   dies quietly two months later. Commit occasionally or re-enable manually
#   (Actions tab shows a banner), or run this from an active repo.
# - This alerts on EVERY failed run. At 10-min intervals a 2-hour outage is
#   ~12 pings. For an indie project that is a feature (you cannot miss it).

WATCH OUT

The thing that bites people: trusting GitHub's cron. Scheduled workflows are best-effort. 5-30 minute delays are routine at peak hours, runs get silently skipped when queues saturate, and schedules are auto-disabled after 60 days without a commit to the repo (as of July 2026, on public and private repos; only commits reset the timer). Treat this runbook as a free second opinion. If you have paying customers, put UptimeRobot or Better Stack (both have free tiers) in front as the primary pager and keep this one because it checks your API for real, which dumb pingers don't.

# dependency-patrol.yml
# Weekly dependency report: npm audit + npm outdated, posted as a single
# GitHub issue every Monday. One recurring issue, updated in place, so your
# tracker doesn't fill up with 52 stale reports a year.
#
# Optional add-on at the bottom: auto-PR for patch/minor updates.
#
# SECRETS REQUIRED: none. Uses the built-in GITHUB_TOKEN with
# least-privilege permissions declared per job.

name: Dependency patrol

on:
  schedule:
    - cron: "23 6 * * 1" # Mondays 06:23 UTC (odd minute dodges cron rush)
  workflow_dispatch: {}

jobs:
  report:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: write # only what this job needs: read code, write one issue

    steps:
      - uses: actions/checkout@v7

      - uses: actions/setup-node@v6
        with:
          node-version: 22
          cache: npm

      - run: npm ci

      # Both commands exit non-zero when they find anything, which would
      # fail the job before we can post. `|| true` captures output either way.
      - name: Collect audit and outdated reports
        run: |
          {
            echo "## npm audit (prod deps)"
            echo '```'
            npm audit --omit=dev 2>&1 || true
            echo '```'
            echo ""
            echo "## npm outdated"
            echo '```'
            npm outdated 2>&1 || true
            echo '```'
            echo ""
            echo "_Generated $(date -u +%Y-%m-%d) by dependency-patrol. Triage rule: fix criticals this week, highs this month, park the rest._"
          } > report.md

      # github-script gives you an authenticated Octokit client inline.
      # Find the existing report issue by label; update it, or create it.
      - name: Post or update the report issue
        uses: actions/github-script@v8
        with:
          script: |
            const fs = require('fs');
            const body = fs.readFileSync('report.md', 'utf8');
            const title = 'Weekly dependency report';
            const label = 'dependency-patrol';

            // Ensure the label exists (ignore "already exists" errors)
            await github.rest.issues.createLabel({
              ...context.repo, name: label, color: '1d76db',
            }).catch(() => {});

            const { data: issues } = await github.rest.issues.listForRepo({
              ...context.repo, labels: label, state: 'open', per_page: 1,
            });

            if (issues.length > 0) {
              await github.rest.issues.update({
                ...context.repo, issue_number: issues[0].number, title, body,
              });
              core.info(`Updated issue #${issues[0].number}`);
            } else {
              const { data: issue } = await github.rest.issues.create({
                ...context.repo, title, body, labels: [label],
              });
              core.info(`Created issue #${issue.number}`);
            }

  # ---- OPTIONAL: auto-PR patch + minor updates ----
  # Semver honesty check: "minor" updates break things too, just less often.
  # This PR runs your tests via your normal PR checks; merge only when green.
  # Delete this whole job if you'd rather update by hand.
  auto-update:
    runs-on: ubuntu-latest
    needs: report
    permissions:
      contents: write # push the update branch
      pull-requests: write # open the PR
    steps:
      - uses: actions/checkout@v7

      - uses: actions/setup-node@v6
        with:
          node-version: 22
          cache: npm

      - run: npm ci

      # `npm update` respects the semver ranges in package.json (the default
      # caret ^ range = minor + patch only). It will not jump majors.
      - name: Apply minor and patch updates
        run: npm update

      # Only opens a PR if npm update actually changed the lockfile.
      # NOTE: peter-evans/create-pull-request is a third-party action.
      # For supply-chain safety, pin it to a full commit SHA:
      #   uses: peter-evans/create-pull-request@<full-sha> # v7
      # (grab the SHA from the action's releases page).
      - name: Open PR if anything changed
        uses: peter-evans/create-pull-request@v7
        with:
          branch: deps/weekly-minor-updates
          title: "chore(deps): weekly minor and patch updates"
          commit-message: "chore(deps): weekly minor and patch updates"
          body: |
            Automated `npm update` from dependency-patrol.
            Minor + patch bumps only (respects package.json semver ranges).
            Merge when checks are green; close if anything looks off.
          labels: dependencies
          delete-branch: true

# NOTE: PRs opened with the default GITHUB_TOKEN do NOT trigger your other
# workflows (GitHub prevents recursion). If your CI doesn't run on this PR,
# close and reopen it by hand to kick the checks, or use a fine-grained PAT
# stored as a secret and passed via the `token:` input.

WATCH OUT

The thing that bites people: the auto-PR shows no CI checks. PRs created with the built-in GITHUB_TOKEN deliberately don't trigger other workflows (GitHub's anti-recursion rule). So your test workflow won't run on the patrol PR. Fixes, easiest first: close and reopen the PR by hand (kicks the checks), or create a fine-grained PAT and pass it to the create-pull-request step's token: input. Don't merge a deps PR that never ran your tests.

# preview-envs.yml
# Every PR gets its own live preview URL on Vercel, posted as a PR comment.
# Same build-locally pattern as the prod deploy (pull -> build -> deploy
# --prebuilt), so previews and prod go through identical machinery.
#
# SECRETS REQUIRED:
#   VERCEL_TOKEN, VERCEL_ORG_ID, VERCEL_PROJECT_ID (same three as the deploy
#   runbook; from `vercel link` -> .vercel/project.json)
#
# NOTE: If Vercel's Git integration is still connected, Vercel already makes
# previews on its own and this duplicates them. Pick one owner. This workflow
# exists for when Actions owns deploys (you disabled Vercel auto-deploy) or
# when you want tests gating previews.

name: PR preview deploy

on:
  pull_request:
    branches: [main]

# One preview per PR. New pushes to the same PR cancel the older in-flight
# preview build (unlike prod, cancelling a preview is free and correct).
concurrency:
  group: preview-${{ github.ref }}
  cancel-in-progress: true

env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}

jobs:
  preview:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write # needed to comment the URL on the PR

    steps:
      - uses: actions/checkout@v7

      - uses: actions/setup-node@v6
        with:
          node-version: 22
          cache: npm

      - run: npm ci

      # Broken PRs should not get preview URLs; fail here, fix, push again.
      - name: Lint and test
        run: |
          npm run lint --if-present
          npm test --if-present

      - name: Install Vercel CLI
        run: npm install --global vercel@latest

      - name: Pull Vercel preview settings
        run: vercel pull --yes --environment=preview --token=${{ secrets.VERCEL_TOKEN }}

      - name: Build
        run: vercel build --token=${{ secrets.VERCEL_TOKEN }}

      - name: Deploy preview
        id: deploy
        run: |
          url=$(vercel deploy --prebuilt --token=${{ secrets.VERCEL_TOKEN }})
          echo "url=$url" >> "$GITHUB_OUTPUT"

      # Sticky comment: finds this workflow's earlier comment on the PR and
      # edits it instead of stacking a new comment on every push.
      - name: Comment preview URL on the PR
        uses: actions/github-script@v8
        with:
          script: |
            const marker = '<!-- preview-envs -->';
            const url = '${{ steps.deploy.outputs.url }}';
            const body = `${marker}\n**Preview deployed:** ${url}\n\n_Updated ${new Date().toISOString()} for commit ${context.payload.pull_request.head.sha.slice(0, 7)}._`;

            const { data: comments } = await github.rest.issues.listComments({
              ...context.repo, issue_number: context.issue.number, per_page: 100,
            });
            const existing = comments.find(c => c.body.includes(marker));

            if (existing) {
              await github.rest.issues.updateComment({
                ...context.repo, comment_id: existing.id, body,
              });
            } else {
              await github.rest.issues.createComment({
                ...context.repo, issue_number: context.issue.number, body,
              });
            }

# SECURITY NOTE: `pull_request` (used here) runs the PR's own code WITHOUT
# access to your secrets for forks, which is safe. Never "upgrade" this to
# `pull_request_target` to make fork previews work; that trigger hands your
# secrets to code from strangers (the classic pwn-request attack, and the
# reason checkout v7 now blocks fork checkouts under it by default).
# For a solo/private repo where all PRs are yours, this is a non-issue.

WATCH OUT

The thing that bites people: fork PRs and `pull_request_target`. On the pull_request trigger used here, PRs from forks run without access to your secrets, so fork previews simply fail to deploy. Safe, if annoying. The "fix" people Google their way into is switching to pull_request_target, which runs with your secrets against a stranger's code: that's the pwn-request attack, and it's how CI secrets get stolen. Solo repo where every PR is yours? Non-issue, ignore fork support. Public repo with outside contributors? Live without fork previews.

NOTE

The pattern all three scheduled runbooks share: schedule: for the automation, workflow_dispatch: for the manual button, odd-minute cron, and an alert path that doesn't depend on the schedule itself firing. Copy that shape into any scheduled workflow you write later.

You are adapting a production GitHub Actions workflow to my stack. Precision over creativity: change only what my stack requires, preserve every safety mechanism.

MY STACK:
- Package manager: [npm | pnpm | yarn | bun]
- Framework: [Next.js | SvelteKit | Remix | other]
- Hosting: [Vercel | Railway | Fly.io | Cloudflare | other]
- Database + provider: [Postgres on Supabase | Neon | PlanetScale MySQL | other]
- Migration tool: [prisma | drizzle | none | other]
- Alert channel: [Slack | Discord]

THE WORKFLOW TO ADAPT:
[PASTE THE FULL YML FILE HERE]

RULES:
1. Preserve these mechanisms exactly unless my stack makes one impossible, and if so, say so explicitly: concurrency groups and their cancel-in-progress values, least-privilege permissions blocks, if: failure() alerting, timeout-minutes, odd-minute cron schedules, workflow_dispatch triggers.
2. Keep action major versions as-is (checkout@v7, setup-node@v6, github-script@v8). Do not "upgrade" or downgrade them.
3. If my host has no CLI equivalent of a step (e.g. no --prebuilt deploys), replace it with that host's documented CI pattern and mark the line with a comment: # CHANGED: reason.
4. Mark every line you changed with # CHANGED: and every line you removed with a note at the bottom.
5. List the exact secrets I must create, with where to obtain each value.

OUTPUT FORMAT:
1. The complete adapted YAML in one code block, comments intact.
2. A CHANGES table: line/step, what changed, why.
3. A SECRETS table: name, where to get it, minimal scope.
4. Any safety mechanism you could not preserve, with the closest substitute.

PAYOFF

That's the whole ops story for an indie SaaS: five files, ~30 minutes of setup, under $0.10/month in R2 storage, and every failure mode reports to the same channel. The first time the deploy alert fires before a customer notices anything, this page paid for itself.

Get the next drop

Every new Vault system ships to the list first. Twice a week, free.