Operations and troubleshooting

Production origin: https://asi-database-node-api.arybit.co.ke

Check /health, /ready and /version separately. A healthy process can have an unavailable database. Verify the expected revision after release promotion. On the VM, inspect the selected systemd service and Nginx configuration; deployment service names depend on release state.

bash run.sh --13 --verify
bash run.sh --13 --logs --stream

Private runtime files and backup artifacts live under /opt/asi-database-node-api/shared/ on the managed VM. Do not copy secrets or log contents into public documentation.

For HTTPS failures, check domain/alias DNS, certificate coverage, expiry and Nginx configuration. For 400 responses check ALLOWED_HOSTS. For browser cross-origin failures check exact HTTPS CORS origins. For unavailable console operations, check database-node-setup.service, the operator token, and the prerequisites listed in console operations. The old cookie-session adapter is no longer used by the console.

Backups use a separate protected database identity and age encryption. Configure backup_recipient and backup_env_file; retain the decryption identity off-host. A checksum and encrypted archive are not proof of recoverability. Use python deploy-database-api/ops/restore-backup.py --help to prepare an isolated restore, then verify row counts, tenant roles, grants and application behavior. Release rollback does not restore database state.

If deployment is interrupted, inspect protected logs and the recorded state before using resume. Do not erase state or rerun migrations to mask an unresolved failure.