Choose and record the topology
Start with the smallest topology that meets the availability goal: one Daptin process, one durable database, durable file storage, and a TLS-terminating edge. Add multiple Daptin instances only after reading what clustering shares and testing behavior when cluster coordination is unavailable.
Deploy a specific release or immutable image digest rather than an unbounded moving tag. Record the Daptin version, schema input, startup flags, environment variables, database version, storage configuration, and rollback artifact for every release.
Persist and recover the complete application
- Place the database and local asset path on durable storage.
- Back up database rows, asset storage, site content, and required encryption/signing secrets as one documented recovery set.
- Encrypt backup copies and restrict restore credentials.
- Restore into an isolated environment and verify representative records, files, authentication, and actions.
- Write recovery time and recovery point objectives from measured restore drills.
Protect network access
Bind Daptin only where the chosen edge can reach it. Terminate TLS in Daptin or a reverse proxy according to the TLS guide. Forward client identity headers only from trusted proxies. Expose optional SMTP, IMAP, FTP, FTPS, and cluster ports only when used and protected.
Route traffic using meaningful health checks
Use /ping for process liveness. Confirm the exact
readiness/health behavior available in the deployed release before
wiring load balancers. A green HTTP process does not prove database,
storage, provider, mail, or application permission health. Test
those dependencies separately and observe them through
monitoring.
Roll out and roll back
- Back up and verify the rollback artifact and configuration.
- Start one replacement instance against a disposable or staged copy of production state.
- Run liveness, database, file, authentication, permission, and critical action checks.
- Remove an old instance from routing before termination and verify the deployed release's shutdown behavior with in-flight test requests.
- Watch errors, latency, pool pressure, resource use, and background work during rollout.
- Stop the rollout and follow the rehearsed rollback when invariants fail.