Backups

Backups in dFlow are not a separate top-level object in the Application → Environment → Service model. Instead, backup behavior is scoped to the kind of thing you run, especially database Services and persistent volumes, plus platform-level expectations when you self-host the control plane.

What you are protectingCopy Anchor Link

• Database Services: Primary candidate for scheduled or on-demand backups, restore, download, and import-from-file flows; credentials and connection details stay tied to the Service in its Environment.
• App and Docker Services: Rely on Git, images, and configuration in dFlow for reproducibility; volumes hold data that may need explicit backup strategy if your app writes local state.
• Self-hosted control plane: Your Organisation data, dashboard state, and configuration may require infrastructure backups separate from customer workloads; treat the install guide as source of truth.

Relationship to deploymentsCopy Anchor Link

A deployment replaces runtime bits; it does not automatically replace database files or volume contents. Plan backups when losing the disk would hurt, not only when you redeploy.

Where backup actions liveCopy Anchor Link

• Service → Backups tab: destination, schedules, manual backups, restore, delete, download, and import-from-file for one database.
• Organisation → Backups: read-only list of database backups across applications (manage snapshots from the service tab).
• Integrations → Backup Storage: S3-compatible credentials used when a database’s destination is External storage.

See alsoCopy Anchor Link

• Backups: operational task guide.
• Backups and restore: database-focused procedures and permissions.
• Volumes and persistent storage: what persists across deploys.
• Self-hosting overview and Backups and recovery: control plane operations.