Backups

There are two halves to the feature:

• Backup Destinations — where backups are stored. Defined once per organization under Configuration → Backup Destinations.
• Backup schedules — what gets backed up and how often. Created on a server’s Backups section (for databases and services) or on a project’s Backups tab (for project files).

You need at least one destination before you can create a schedule.

Backup destinations #

Destinations live at the organization level, so a destination you add once can be used by every server and project in that organization.

Supported destination types #

• Amazon S3 — bucket, region, access key ID, secret access key, optional path prefix
• Cloudflare R2 — bucket, S3 endpoint, access key ID, secret access key, optional path prefix
• Custom S3-compatible — bucket, endpoint URL, region, access key ID, secret access key, an optional path-style endpoint toggle, and an optional path prefix
• SFTP — host, port, username, and either a password or a private key, plus the remote path
• FTP — host, port, username, password, remote path, and an optional FTPS (TLS) toggle
• Local folder — a folder path on the server itself, for example /var/backups/depfloy

Add a destination #

1. Open Configuration → Backup Destinations.
2. Click Add destination.
3. Give it a Name — this is what you’ll pick from when creating a schedule.
4. Choose a Type and fill in the fields for that type.
5. Save with Add destination.

Test connection #

Every destination row has a Test connection action. This is not a superficial check — Depfloy actually writes a test object to the destination and deletes it again, so a passing test means your credentials really can create and remove backup data there.

The Status column reflects the last test:

• Validated — the round trip succeeded
• Error — the test failed, with the reason shown next to the badge
• Not tested — no test has been run yet

If a test fails, the message tells you what went wrong: a rejected bucket permission, a refused SFTP or FTP login, or a remote path that is not writable. Fix the cause and test again.

Editing a destination resets its status back to Not tested, since the connection details may have changed. Run the test again after editing.

Local folder destinations are the one exception: they can’t be reached from Depfloy’s side, so the test reports that they will be verified on the target server the first time a backup runs there.

Credentials and deletion #

Destination secrets — access keys, passwords, and private keys — are stored encrypted and are never sent back to the browser. When you edit a destination, the secret fields are blank with a Leave blank to keep current placeholder; type a new value only if you want to replace the stored one.

A destination that is currently used by a backup schedule cannot be deleted. Remove or repoint the schedules that use it first — the Usage column shows In use or Unused so you can tell at a glance.

What you can back up #

Databases and services, from a server’s Backups section:

• PostgreSQL
• MySQL / MariaDB
• Redis and Valkey
• ClickHouse
• Meilisearch

The Backups section appears on Database Servers and on any application server that has a database or service installed. Only databases Depfloy knows how to back up are offered in the schedule form.

Project files, from a project’s Backups tab — a copy of the project’s directory, with an exclusion list so you can skip anything rebuildable.

Project files on zero-downtime projects #

If the project uses zero-downtime deployments, the backup follows the symlinks rather than saving them: it captures the shared directory (your persistent data, such as .env and storage) together with the release that is currently live. The rebuildable release history is skipped, so you get the real content without the churn.

Classic (non zero-downtime) projects simply back up the full project directory.

Create a backup schedule #

For a database or service:

1. Open the server in the Console and go to Backups.
2. Click Add backup schedule.
3. Fill in:
   • Database — which database or service on this server to back up.
   • Destination — one of your configured destinations.
   • Frequency — Hourly, Daily at 3 AM, Weekly (Sun 3 AM), Monthly (1st, 3 AM), or Custom cron for your own expression. crontab.guru is a good helper for custom expressions.
   • Keep last N backups — how many runs to retain. Older backups beyond this count are pruned after each successful run. Defaults to 7.
   • Name (optional) — a label for the schedule; the database name is used if you leave it blank.
4. Save with Add schedule.

For project files the flow is the same from the project’s Backups tab, with one extra field:

• Exclusions (one per line) — paths and patterns to skip. Depfloy pre-fills sensible defaults (node_modules, .git, vendor, storage/logs, storage/framework/cache). You can change the list later from the schedule’s Edit dialog, which opens with the exclusions currently saved. Clearing it excludes nothing.

Manage schedules #

Each schedule row shows what it backs up, where it sends it, how often, and how many copies it keeps, plus an active or paused badge.

The row’s ⋯ menu gives you:

• Edit — change the destination, frequency, retention count, name, and — on a project files schedule — the exclusion list. The source database cannot be changed after creation; create a new schedule instead.
• Pause / Resume — stop the schedule from firing without deleting it or its history.
• Delete — remove the schedule. Backups already stored at the destination are left untouched.

Run a backup now #

Backup now on a schedule row starts a run immediately, outside the schedule. The button reflects the run as it moves along — Queued…, then Running… — and the new run appears in the history as it progresses.

History and status #

Under each schedule is its recent run history — the five most recent runs — showing:

• Status — pending, running, completed, partial, or failed. A partial run means some, but not all, of the configured sources were captured; it is still usable for download and restore.
• When the run happened
• Size of the resulting backup
• A checksum you can copy, to verify a file you’ve pulled down yourself

The list updates live while a backup is running, so you can leave the screen open and watch it finish. Failed runs show the error inline; hover for the full message.

Each run’s ⋯ menu has Download, Restore, and Delete.

Deleting a run removes the stored backup from the destination as well. Deleting a failed run only removes the record, since a failed run has nothing stored.

Failure notifications #

Depfloy can tell you when a scheduled backup fails. Turn on Backup Failed under Settings → Notifications — it is available for both email and Slack, and can be enabled per channel. See Notifications for the full list of events.

Restore a backup #

Restore is available on completed and partial runs, from the run’s ⋯ menu. Restoring is a significant operation, so Depfloy always shows a confirmation dialog that spells out exactly what will happen before anything is touched.

What each restore does:

• MySQL / MariaDB — overwrites the target database with the contents of the backup.
• PostgreSQL — drops and recreates the target database. Active connections to it are terminated.
• Redis / Valkey — replaces the entire dataset and restarts the service. It requires appendonly (AOF) to be turned off: with AOF on, the server reloads from the append-only file, so a restored snapshot would silently have no effect — Depfloy refuses the restore rather than let that happen.
• ClickHouse — drops the database and recreates it from the backup.
• Meilisearch — replaces the index data and restarts the service. The backup must come from the same Meilisearch version; snapshots are not portable between versions, and Depfloy checks this before it touches anything. Your existing data is kept until the import succeeds — if the service doesn’t come back up, the previous data is put back.
• Project files — extracts the backup into a new directory next to the project, leaving the live project untouched. You can then inspect the restored files and move what you need into place yourself.

Restores run in the background and you’re notified when they finish.

Download a backup #

Download on a completed or partial run opens a temporary, time-limited download link in a new tab.

Direct download is available for the S3-family destinations — Amazon S3, Cloudflare R2, and Custom S3-compatible. For SFTP, FTP, and Local folder destinations, fetch the file from that storage directly; Depfloy will tell you so if you try.

Permissions #

Backups follow your role in the organization (see Members for the full role list):

Capability	Owner	Admin	Manager	Developer	Viewer
View backups and history	✓	✓	✓	✓	✓
Create and edit backup schedules and destinations	✓	✓	—	—	—
Restore and download backups	✓	✓	—	—	—
Delete backups and destinations	✓	✓	—	—	—

Everyone can see the Backups screens and check whether backups are healthy. Only Owners and Admins can create, edit, or delete schedules and destinations, run a backup on demand, or download and restore a backup — the controls simply aren’t rendered for other roles.

Related #

• Database Server — managing the databases you back up
• Project Settings — project directory and deployment configuration
• Members — roles and what each one can do
• Notifications — turning on backup failure alerts
• Billing — plans and changing yours