Backups

Coolify can create scheduled, engine-aware database backups for PostgreSQL, MySQL, MariaDB, MongoDB, ClickHouse, and SQLite. Each backup schedule creates a backup on the database's server, and can upload a copy to an S3-compatible storage provider.

Redis, Dragonfly, and KeyDB do not support this scheduled database backup workflow. Use the engine's persistence and backup tools for those databases, or deploy a backup-capable service separately.

Create a backup schedule

1. Open a supported database.
2. Select Backups in the resource navigation.
3. Select + Add next to Database backups.
4. Enter a cron expression or a supported human-readable frequency.
5. Select Add schedule.

The schedule runs on the server where the database is deployed. The Timezone field is read-only: it uses the server timezone when one is configured, otherwise the Coolify instance timezone.

SQLite backups use its configured database files. See SQLite for application connections and file recovery.

A backup job runs only while the database is running. If the database is stopped when the schedule fires, Coolify skips that execution.

Back up a database inside a service

A database component deployed inside a Service uses credentials from the environment of its running container. This differs from a standalone database resource, whose connection values are stored directly by Coolify.

Coolify reads the resolved container variables listed below. These names do not need to match the variable names shown on the parent Service's Environment Variables page. A one-click Service commonly maps a generated value such as SERVICE_PASSWORD_POSTGRES to POSTGRES_PASSWORD in its Compose definition.

For example, a PostgreSQL component can map Service variables to the names Coolify reads:

services:
  postgres:
    environment:
      POSTGRES_USER: ${SERVICE_USER_POSTGRES}
      POSTGRES_PASSWORD: ${SERVICE_PASSWORD_POSTGRES}
      POSTGRES_DB: ${POSTGRES_DB:-app}

Variable names inside the database container are case-sensitive. Do not add duplicate POSTGRES_*, MYSQL_*, MARIADB_*, or MONGO_INITDB_* entries to Environment Variables when the Compose definition already maps generated Service variables to those names.

To verify or correct the configuration:

1. Open the parent Service and select Edit Compose File.
2. Find the database component and inspect its environment entries.
3. Confirm that the required container-variable names in the table are present and mapped to the intended Service variables or values.
4. To change a referenced value such as SERVICE_PASSWORD_POSTGRES, open Environment Variables. Change a hard-coded value in the Compose file instead.
5. Restart or deploy the Service so Coolify recreates the database container with the updated environment.
6. Confirm that the database component is running, then open its backup schedule and select Back up now.
7. Inspect the execution status and message.

Read Service environment variables for details about generated, referenced, and hard-coded Compose values.

A missing MySQL or MariaDB database-name variable can stop the job before Coolify creates a normal execution entry. If Back up now produces no execution, confirm that the database is running and recheck the variables in the table.

Set the backup scope

Open a schedule and use General > Backup schedule to configure the databases included in each execution. Select Enable backup or Disable backup to control scheduled runs, and Save changes after editing fields.

For PostgreSQL, MySQL, and MariaDB, select Specific databases, then type each database name and press Enter in Databases to back up. For ClickHouse, enter a comma-separated list. An empty field uses the database configured in the resource.

For MongoDB, use database:collection1,collection2|database2 to exclude collections from each database. For example:

app:events,logs|analytics

This includes all collections in app except events and logs, and all collections in analytics. Leave the field empty to include all databases and collections.

Choose a frequency

Coolify accepts standard five-field cron expressions and these named schedules:

Use a Timeout of at least 60 seconds when a database dump needs more time. The timeout applies to the backup job and defaults to 3600 seconds in the job when no value is set.

Store backups locally

Coolify writes local database backups under /data/coolify/backups on the deployment server. The exact subdirectory includes the team, database, and execution name; use the Executions page to inspect the result instead of relying on a manually reconstructed path.

Local retention can remove successful backup files after an execution completes. In Retention, set any of these values to 0 for no limit:

• Backups to keep
• Days to keep
• Maximum storage (GB)

The limits work independently. Coolify deletes a backup when any configured limit is reached, keeping the most recent backups first.

Upload backups to S3

1. Configure and validate an S3-compatible storage under S3 storage.
2. Open the database schedule and open S3 storage.
3. Select the validated S3 storage, select Enable S3, and select Save changes.
4. Optionally set Local copy to Delete after S3 upload.

Coolify uploads the local backup file to the selected S3 storage after the local dump succeeds. If the upload fails, the local backup can still remain available and the execution reports the S3 warning.

Local copy > Delete after S3 upload removes the local file after a successful S3 upload. It does not remove the S3 copy. Set S3 retention separately; local and S3 retention rules are independent.

Run and verify a backup

Open a schedule and select Back up now while the database is running. Coolify queues the backup job and shows the execution in the schedule.

Open the execution to verify:

• status is Success
• the database names match the intended scope
• the file size is greater than zero
• S3 upload status is successful when S3 is enabled
• the local copy still exists unless Local copy was set to Delete after S3 upload

A failed S3 upload does not necessarily mean the local database dump failed. Read the execution message and notification to identify which copy is available.

Related guides

Scheduling and failed executions

Due database backups are dispatched every minute independently of other schedule types. A scheduled backup whose queued job was lost is queued again after 60 minutes. A backup is skipped while the database starts, restarts, or imports, and a backup that exceeds its timeout fails with the timeout error.

For backups of several databases, each database has its own result and finish time. All-database PostgreSQL, MySQL, and MariaDB backups fail if the dump command fails rather than retaining an incomplete archive. Review every result before relying on a backup set.