A recoverable Coolify deployment needs three separate things: a backup of the Coolify panel, backups of the applications it manages, and the keys needed to use both. Restoring the panel can bring back a convincing dashboard while the business database and uploaded files are still missing.
As of 1 November 2026, the Coolify v4.5.0 release notes, published on 23 October, include automatic backup of the Coolify database before an update. That protects the management layer during an upgrade. It does not turn the update into a backup of every deployed workload.
What a Coolify backup actually protects
Separate management metadata from the data your customers create. These layers have different recovery methods and can live on different servers.
| Layer | What to preserve | Recovery purpose |
|---|---|---|
| Coolify panel | Instance database and matching APP_KEY | Recover deployment configuration and access to saved secrets |
| Workload databases | Engine-aware database backups | Recover application records |
| Application files | Uploads, persistent mounts and configuration files | Recover content that an image rebuild cannot recreate |
| External dependencies | DNS, registry access, provider accounts and recovery credentials | Reconnect the restored deployment to the outside world |
The official instance-backup guide describes a panel backup as Coolify's own database, not application data. Keep its APP_KEY separately: the dump does not include the environment file containing that key. Without the matching key, restored encrypted credentials are unusable.
A Git repository is useful recovery material, but it usually cannot reproduce customer uploads or recent database transactions. Likewise, a retained container image can reproduce executable code without reproducing the state attached to that container. Identify every persistent path before assuming a redeployment is enough.
Set recovery targets before choosing a schedule
Write down two business decisions. The recovery point objective, or RPO, is how much recent data you can afford to lose. The recovery time objective, or RTO, is how long the service can remain unavailable. These are targets you must design and rehearse; selecting a daily schedule does not establish either one.
For example, a nightly backup can leave almost a day's changes exposed between successful runs. If an application records orders throughout the day, decide how those orders would be reconciled with the payment provider after recovery. A brochure site might accept a much longer gap. Use separate targets for separate workloads.
Include transfer time in the recovery budget. A large archive must be downloaded, unpacked and checked before an application can use it. Add time for acquiring a replacement server, recovering account access, obtaining images and correcting DNS. Recording those dependencies now makes an outage checklist much shorter.
Build a backup plan that survives loss of the host
1. Configure and export the panel backup
In a self-hosted instance, open Settings > Backup, configure the backup, and run Back up now. Check the execution result and retrieve an off-server copy. The documented S3 option copies the database dump; it does not bundle the encryption key. Review storage availability, not just the presence of an execution row.
Record the Coolify version, backup timestamp, location and owner of the recovery procedure. Put secret values in a protected vault or password manager, referenced by the recovery record. Do not paste them into a shared operations ticket or store the only recovery credentials inside the service you are trying to recover.
2. Schedule workload database backups independently
Coolify's database backup documentation covers scheduled backups for PostgreSQL, MySQL, MariaDB, MongoDB, ClickHouse and SQLite. Redis, Dragonfly and KeyDB need their own persistence and backup approach. Inspect which databases a job includes; a successful backup of one database says nothing about an omitted second database.
Check that the remote upload finished, retain enough history to outlast delayed discovery of mistakes, and assign someone to investigate failures. A job that produces a local file but fails to upload it has not delivered protection against losing that host. For PostgreSQL-specific planning, see our guide to PostgreSQL backups in S3.
3. Protect files with a consistency plan
The storage-mount backup guide documents archives for eligible application volumes and directories. File mounts and host file mounts are excluded from that workflow. Archives of changing files may be inconsistent; the documented option to stop containers during archiving trades availability for safer file capture. Use a database-aware backup for live databases.
Choose how database rows and files will line up after recovery. A restored row may reference an upload created after the file archive, or an archived file may have no matching row. For an application with linked assets, document an acceptable consistent recovery point and how to pause writes when necessary.
4. Separate backup access from application access
Use a private backup destination and narrowly scoped credentials. Consider what a compromised deployment account could delete, including old recovery points. Keep a second recovery path whose credentials are unavailable to the application. Encrypt sensitive archives before placing them in storage that other operators can access.
Retention and deletion rules need to agree. A bucket lifecycle that removes archives sooner than the documented recovery window defeats the schedule. Our S3 versioning guide explains another layer of protection, while the rclone guide covers moving copies between compatible storage destinations. Neither replaces restoring a real backup.
Fresh-server restore: recover the Coolify panel first
Use a dedicated replacement or disposable recovery server. The restore below replaces the target panel database. Confirm the host and backup identity before proceeding; preserve any target state that matters. This is a recovery procedure, not a command to run on a healthy production panel.
Isolate a rehearsal before restoring working credentials or starting the recovered panel. Use the test server's host or provider firewall to allow dashboard and SSH access only from the operator's address. Deny outbound access by default, allowing only the destinations needed to install software and retrieve backups; keep production servers and integration endpoints blocked. Preserve the original dump, APP_KEY and SSH keys unchanged in secure recovery storage. Use separate test credentials for integrations you enable during rehearsal. Review restored schedules, deployment webhooks and automation before lifting any restriction: a panel with working SSH keys could contact surviving production hosts. For an actual recovery, reconnect only the intended production targets at the planned cutover.
Follow the official restore guide for your release. Its replacement-server sequence is:
- Install the version recorded with the backup; confirm the fresh dashboard opens.
- Copy the .dmp backup onto that server and verify it is non-empty.
- Stop the panel and Redis containers while leaving coolify-db running. Older releases may also have coolify-realtime.
- Set the original APP_KEY in /data/coolify/source/.env. Keep other fresh-installation values, including DB_PASSWORD.
- Restore the panel database with the documented command below.
- Replace fresh-installation SSH keys with the original files under /data/coolify/ssh/keys/ and authorize the matching public key on the replacement server.
- Rerun the installer for the chosen version; it starts containers and applies migrations.
Set BACKUP_PATH to your actual file. Run the file check first and continue only if it succeeds. Keep the control plane stopped during the database import:
export BACKUP_PATH=/data/backups/coolify-db-backup.dmp
test -s "$BACKUP_PATH" && ls -lh "$BACKUP_PATH"docker exec -i coolify-db pg_restore \
--clean \
--if-exists \
--exit-on-error \
--no-acl \
--no-owner \
--username=coolify \
--dbname=coolify \
< "$BACKUP_PATH"If the import fails, keep the panel stopped and inspect the first error. Repeatedly starting services against a partly restored database makes diagnosis harder. Record the output in restricted recovery evidence without copying secret values.
Recover workloads and reconnect traffic deliberately
Establish whether the original application servers survived. Recovering a separate panel does not mean those servers need to be rebuilt. Conversely, if the lost machine hosted both the panel and applications, the panel restore leaves the workload recovery work still to do.
For each missing workload, prepare its runtime and storage, restore the database, restore related files, and check permissions and secrets before enabling writes. Coolify's database restore guide lists supported import formats and warns that imports can overwrite data and credentials. Review the generated import command and replacement options rather than assuming every archive uses the same restore path.
Keep the rehearsal restrictions in place while restoring workloads. A recovered automation can send real mail, process an order twice or call a payment API even when nobody has changed public DNS. Review pending work before intentionally resuming production integrations.
Before changing traffic, check the application through its intended HTTPS hostname, confirm login and representative read/write operations, and inspect failed jobs. Verify that DNS and external callbacks point to the intended server. Reconcile transactions received during the outage before replaying queued work.
What a useful recovery rehearsal records
Run the procedure on an isolated target using an off-server copy. Have a colleague follow the record without depending on the original operator's memory. Record:
- The backup timestamp and recovered data timestamp for every workload.
- How long retrieval, panel recovery, data recovery and validation each took.
- Whether secrets decrypted and server connections validated.
- Whether representative records and uploaded files matched.
- Any missing account access, commands, permissions or dependencies.
Repeat after a meaningful change to storage, authentication, backup tooling or deployment topology. Start new backups after a real recovery and check that the replacement environment is covered. A restore that leaves tomorrow's backup pointed at a deleted server is unfinished.
If you are designing the underlying setup, compare DanubeData VPS resources and S3-compatible object storage against your recovery plan. Hosting and backup storage are components of that plan; the rehearsal establishes whether the complete service can be recovered.
Frequently asked questions
Does the automatic pre-update backup cover my apps?
No. The v4.5.0 release item concerns Coolify's database. Maintain separate recovery points for workload databases, uploads and other persistent state.
Can I recover without the original APP_KEY?
A database file alone cannot make encrypted credentials usable. Preserve the matching key before an incident and verify that recovery material is accessible independently of the lost server.
Is copying Docker volumes enough?
It depends on the application and whether the capture is consistent. A copy of files changing underneath a running database is not a substitute for its supported backup method. Include any persistent paths outside those volumes.
How long will recovery take?
There is no universal time. Data size, transfer speed, available replacement capacity and external access all matter. Measure an isolated rehearsal and compare its result with the business recovery target.
Sources and further reading
Coolify v4.5.0 release; instance backup; instance restore; database backups; database restore; storage-mount backups.
