Skip to main content

​
What to back up

PostgreSQL is the source of truth for projects, keywords, schedules, rank checks, encrypted provider connections, alerts, notifications, and audit history. Keep:
  • regular PostgreSQL backups with tested restore procedures;
  • the exact BISIBILITY_SECRETS_KEY used to encrypt provider credentials;
  • BETTER_AUTH_SECRET and the deployment’s secret/environment inventory;
  • your deployment manifests and the application version or image digest.
Redis or Valkey contains rate-limit, idempotency, and realtime coordination data and normally does not need durable backup. If you self-host Temporal and need to preserve in-flight workflow history, back up its persistence database separately. Keyword schedule intent remains in the application database and the worker can reconcile Temporal schedules after recovery. Example PostgreSQL backup:
Test restores in an isolated database. --clean is destructive and must never target the active production database.

​
Upgrade Docker Compose

  1. Read the changelog and note schema or environment changes.
  2. Stop writes or schedule a maintenance window.
  3. Back up PostgreSQL and secrets.
  4. Fetch the target tag, review .env.example, and update .env deliberately.
  5. Rebuild and start:
The one-shot migrate service runs prisma migrate deploy before the web app. With scheduled checks enabled, include --profile scheduled when starting the stack. Never enable demo OTP or demo seeding on a real deployment. After an upgrade that adds competitor organic snapshots, optionally compact the latest completed SERP for each keyword into the new query-friendly column:
Run the command with DATABASE_URL available. It is batched and idempotent, and leaves checks without a usable historical organic payload unchanged. The app continues to read those legacy payloads directly, so the backfill does not need to block the web deployment.

​
Keep web and worker on the same version

The web app and Temporal worker share one Prisma schema. For a split deployment, back up PostgreSQL, deploy the web app so it runs prisma migrate deploy, and then immediately deploy the worker from the same release tag. Version skew commonly appears as “The column … does not exist” errors in worker logs or as failing scheduled checks while the web app works.

​
Verify and roll back

Check GET /api/v1/health, sign-in, one project read, and worker logs. Confirm the Temporal worker reports ready and its maintenance schedules are created or already exist. For split deployments, verify that both processes use the same release by following Keep web and worker on the same version. Rolling the application image back does not reverse Prisma migrations. If a release contains an incompatible schema migration, restore the pre-upgrade database backup together with the matching application version. Practice that procedure before relying on it during an incident. For managed platforms, use the platform database backup and rollback features, but keep independent exports for disaster recovery. Deployment topology is in Self-hosting.