Map persistent state
Identify databases, uploaded files, repositories, attachments, and configuration that must move together during backup or restore.
Maintained workload baselines
Start from the state that must survive.
Each baseline joins the service boundary, durable state, update sequence, rollback package, and recovery acceptance checks. Choose the workload closest to yours, then carry its contract into planning and Compose inspection.
content site
WordPress public-site baseline
Keep the database and site files in one recoverable update point, then verify publishing, media, plugins, and public routing after change.
- State boundaries
- 3
- Recovery proofs
- 4
file sync
Nextcloud personal-cloud baseline
Keep files, database, configuration, custom apps, and themes synchronized through maintenance, upgrade, rollback, and client-facing restore checks.
- State boundaries
- 4
- Recovery proofs
- 4
source control
Gitea source-control baseline
Keep repositories, database, application data, configuration, and external object storage consistent through migration-aware update and clone/push recovery checks.
- State boundaries
- 3
- Recovery proofs
- 4
How to use a baseline
Choose by state and recovery shape, not by a copied YAML file.
Define exposure
Record the public web, private database, and optional SSH boundaries before inspecting ports, networks, secrets, and proxy behavior.
Control each update
Capture, quiesce, apply, and verify against one compatible rollback set instead of treating an image pull as the whole update.
Prove recovery
Test the application’s real read, write, identity, state, and public-access workflows after restoration.