Production readiness checklist
Verify the HTTPS, access control, data protection, observability, and rollback conditions required before serving production traffic.
Use this checklist before the first production release and after a deployment change. It turns the supported PocketBase deployment and backup behavior into concrete checks; adapt ownership, alert thresholds, and retention to your organization.
Before you begin
You need access to the deployment host or platform, a superuser account, the reverse proxy configuration, the persistent data volume, and the current release artifact. Prepare a tested backup destination and a rollback artifact before changing the live service.
Run the readiness checks
Open the public domain over HTTPS and confirm the certificate covers the domain. Send a health request through the same public route:
curl -fsS https://example.com/api/healthThe response is HTTP 200 with API is healthy.. If a reverse proxy is in use, confirm it forwards Host, X-Real-IP or X-Forwarded-For, and X-Forwarded-Proto, and that PocketBase trusts only the headers from that proxy.
Confirm that production credentials are not in source control, image layers, or shared command history. If database-stored settings contain SMTP or S3 credentials, consider enabling settings encryption with a random 32-character environment value and starting PocketBase with --encryptionEnv=YOUR_ENV_VAR.
Verify superuser MFA or OTP controls and, where appropriate, a superuser IP allowlist. Test a least-privilege application account separately from the superuser account.
Check the production schema and run representative authenticated and unauthenticated requests. Confirm that collection API rules reject operations that the application should not permit, and that protected files require the expected authorization. Record the release and migration state before continuing.
Confirm that pb_data is on durable storage and that a recent backup can be located in the configured destination. PocketBase backups are full snapshots of pb_data; local backups are the default, and S3-compatible storage is supported. For a filesystem copy, stop the application for transactional safety before copying or replacing pb_data.
The built-in backup configuration includes fields for enabling backups, scheduling, retention, and storage settings. Review the configured values and ensure the backup destination is separate from the primary failure domain.
Apply the release’s migrations in a controlled pre-production or maintenance window. Confirm that the PocketBase process can read its executable and hooks, write the intended pb_data location, and access the backup destination without broader host permissions.
Confirm that health checks, process logs, and PocketBase request logs are visible to the operations team. Keep the previous executable or image and the matching migration and configuration record available. Define the abort condition before release: a failed health check, unexpected API-rule result, missing data volume, or rising error log entries.
After deployment, repeat the health request, exercise one representative read and write path, and check Health checks, logs, and statistics. If the checks fail, stop accepting traffic and restore the last known-good artifact and data path using the tested backup and restore procedure.
Operational limits to record
Large pb_data backups can be slow and may temporarily increase query latency. Applications with many realtime connections can hit the operating system’s open-file limit; check ulimit -a and configure the service limit when evidence from the workload requires it. Do not invent a universal alert threshold: set one from your workload and incident objectives.
Next steps
Keep this checklist with the release record and rehearse backup and restore before the next schema or infrastructure change.