Operating it: backups, upgrades and the quarterly checklist

Installing an HRMS takes an afternoon. Operating one is a small ongoing commitment, and skipping it is how self-hosted systems end up unpatched, unbackuped and unloved.

Backups

The single most important thing on this page. If you use a managed database provider, daily automated backups with point-in-time recovery are usually included — turn them on and check the retention window. If you run your own, schedule pg_dump and ship the output somewhere off the machine.

Back up the object store too — receipts, medical certificates and policy PDFs live there, not in the database, and a database-only backup restores an HR system full of broken links.

Upgrading

1. 1Read the release notes, particularly for destructive migrations.
2. 2Take a fresh backup.
3. 3Pull the new version and run npm install.
4. 4Run npm run db:migrate — it is idempotent and applies only what is pending.
5. 5Build and restart.
6. 6Sign in, load the dashboard, apply for a day of leave, approve it. Two minutes, catches most breakage.

Migrations that drop data say so in the file header. Read those before running, not after.

Rotating secrets

• `AUTH_SECRET` — rotating it signs everyone out. That is the intended emergency response if you think it leaked. Otherwise leave it alone.
• `NRIC_ENCRYPTION_KEY` — do not rotate casually. Existing values are encrypted with the current key; changing it without re-encrypting makes them unreadable. Rotation needs a planned re-encryption pass.
• API keys (email, storage, OCR) — rotate on your provider's advice or when someone with access leaves.
• `CRON_SECRET` — rotate whenever the person who had it leaves.

Monitoring

/api/health is an unauthenticated liveness endpoint suitable for an uptime monitor. Point a free monitor at it and have it alert someone who will act.

Also worth watching: the email outbox for a growing count of failed messages, and your database provider's storage usage.

The quarterly checklist

1. 1Restore a backup into a scratch database and verify it.
2. 2Review admin accounts. Everyone with admin or super admin — do they still need it? Has anyone left?
3. 3Skim the audit log for NRIC decryptions and entitlement overrides. Anything unexplained?
4. 4Check the holiday calendar covers the current and next year.
5. 5Apply pending upgrades, dependencies included.
6. 6Confirm retention — is the purge job running, and do the periods still match your policy?

Twenty minutes a quarter. Put it in a calendar with an owner's name on it; an unowned checklist does not get run.

When someone leaves

1. 1Raise a deletion request with their termination date and reason.
2. 2Have a super admin approve it — this revokes their sessions immediately.
3. 3Remove them from any approver assignments, so requests do not route to a departed colleague.
4. 4If they held admin, rotate CRON_SECRET and any API keys they could see.
5. 5Note when their records fall due for deletion under your retention policy.