Skip to content

Sentry Setup Checklist

Sentry config lives in two completely separate places. They do not share values:

  • GitHub repo secrets — only available to the CI release workflow (.github/workflows/sentry_release.yml). Used at build/release time.
  • App Runner runtime env vars — available to the running Node process. Used at runtime.

A value set in GitHub secrets is invisible to App Runner, and vice-versa.

1. GitHub repo secrets (build / release time)

Settings → Secrets and variables → Actions → New repository secret.

Name Value Used by
SENTRY_AUTH_TOKEN Sentry org auth token (create at Sentry → Settings → Auth Tokens) getsentry/action-release to upload source maps
SENTRY_ORG studiojadu release action
SENTRY_PROJECT studio-backend release action

These should already exist (used by other workflows); confirm they are present:

Name Purpose
SCENARIX_GITHUB_PKG_TOKEN npm ci against the private GitHub registry
AUTO_PR_BOT_APP_PRIVATE_KEY (secret) + AUTO_PR_BOT_APP_ID (variable) GitHub App token for the version-bump push (main is branch-protected)

Do not put SENTRY_DSN or SENTRY_ENVIRONMENT here — the running app never reads GitHub secrets.

2. App Runner runtime env vars (runtime)

Set per service in the App Runner console → Configuration → Environment variables. Region us-east-1, account 408921634255.

studio-backend-prod (branch main)

Name Value
SENTRY_DSN <dsn>
SENTRY_ENVIRONMENT production

studio-backend-staging (branch staging)

Name Value
SENTRY_DSN <dsn>
SENTRY_ENVIRONMENT staging

DSN (org studiojadu, project studio-backend):

https://4639b857b48387a7883f56af5da85211@o4511307846713344.ingest.us.sentry.io/4511607481630720

The DSN is safe to expose — it can only send events, not read them. It is not a credential, so it lives in App Runner config rather than as a secret.

Why the split matters

  • instrument.ts reads process.env.SENTRY_DSN and process.env.SENTRY_ENVIRONMENT at startup. If SENTRY_DSN is unset, Sentry init is skipped entirely and the app reports nothing. So the DSN + environment must be App Runner env vars — putting them only in GitHub secrets leaves Sentry disabled in prod/staging.
  • SENTRY_AUTH_TOKEN is a real credential and is only needed by CI to upload source maps. It must never ship to the running app.
  • SENTRY_RELEASE is not needed anywhere: the app self-reports its release from package.json version, and the CI workflow uploads source maps under that same bumped version. (It remains available as an optional override env var.)

How the release flow ties together

  1. Push lands on main → sentry_release.yml runs.
  2. Workflow bumps package.json patch version, commits [skip ci], pushes (via GitHub App token, since main is branch-protected).
  3. App Runner auto-deploys that exact commit. At startup the app reports release = <package.json version>.
  4. getsentry/action-release@v3 injects debug IDs into ./dist and uploads the source maps under the same version → stack traces in Sentry resolve to src/*.ts, tagged with the correct environment and release.

Verify after configuring

  1. Confirm both App Runner services have SENTRY_DSN + SENTRY_ENVIRONMENT set and have redeployed.
  2. Hit /api/debug-sentry/error (requires ENABLE_TEST_ROUTES=true) on a deployed service.
  3. In Sentry, confirm the issue appears tagged environment: staging|production, release: <version>, with a src/*.ts stack trace (not dist/*.js).