Backups

Conceptual model for backups: scope by Service type, environments, and where task guides live.

Written By Zoro

Last updated 28 days ago

Backups in dFlow are not a separate top-level object in theApplication → Environment → Service model. Instead, backup behavior isscoped to the kind of thing you run, especially database Services andpersistent volumes, plus platform-level expectations when you self-hostthe control plane.

What you are protecting

  • 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 configurationin dFlow for reproducibility; volumes hold data that may need explicitbackup strategy if your app writes local state.
  • Self-hosted control plane: Your Organisation data, dashboard state,and configuration may require infrastructure backups separate fromcustomer workloads; treat the install guide as source of truth.

Relationship to deployments

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

Where backup actions live

  • 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 also