Backups

Coolify can create scheduled, engine-aware database backups for PostgreSQL, MySQL, MariaDB, MongoDB, and ClickHouse. 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 Scheduled Backups.
4. Enter a cron expression or a supported human-readable frequency.
5. Select Save.

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.

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 Configuration > 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 Backup 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 Backup Now produces no execution, confirm that the database is running and recheck the variables in the table.

Set the backup scope

Open a schedule to configure the databases included in each execution.

For PostgreSQL, MySQL, MariaDB, and ClickHouse, enter multiple database names as 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:

• Number of backups to keep
• Days to keep backups
• 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 select the S3 section.
3. Enable S3, select the validated storage, and select Save.
4. Optionally enable Disable Local Backup.

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.

Disable Local Backup 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 Backup 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 Disable Local Backup was enabled

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