2026-10-18
Check the offsite copy of a Coolify compose database backup
A successful local dump and an offsite backup are two different claims. Check both before promising recovery.
The risk is simple: a dashboard can tell you something useful about one step while the copy you meant to keep does not exist. In one Coolify issue, a compose-based MongoDB backup showed a queued toast but no job reached the queue. Another report says a manual compose MariaDB backup produced no execution and no visible error. Those are reports about compose databases, not a proof that every compose Postgres backup fails.
https://github.com/coollabsio/coolify/issues/5915
https://github.com/coollabsio/coolify/issues/9417A separate issue involved Coolify's own database, not a compose-stack Postgres service. The local backup was marked successful, the S3 step failed, and the remote bucket had zero objects. That is a useful warning about reading local success as offsite success, but it does not establish the exact compose Postgres claim either.
https://github.com/coollabsio/coolify/issues/7779What I would verify before relying on it
- Confirm the schedule produces an execution for the intended database. Open that execution and check its status, database name and non-zero file size.
- If offsite storage is configured, check the upload result and find the actual object in the destination. A green local result or storage connection test is not the object.
- Restore a recent copy into a throwaway Postgres database and check that the expected tables and records are there. Record the date and the result.
Coolify's current backup documentation describes backups for service databases and explicitly asks operators to inspect execution details and the S3 result. It also says a successful backup proves only that a file was created. This is a version-sensitive area, so I would check the installed version and its actual output before treating an old issue as a current product rule.
Keep an independent recovery path
For a compose Postgres that carries a recovery promise, I would schedule pg_dump independently of the Coolify backup tab, send the resulting archive off the server, fail loudly when the upload does not complete, and run a documented restore test. pg_restore can load a custom-format pg_dump archive into a disposable database. The restore is the evidence that the archive can bring data back.
The issue tracker is a reason to verify the whole path, not a substitute for observing your own backup job. The thing to trust is a recent object you can retrieve and restore.
Topics
More notes
- A fresh DNS record existed, but my Mac still said the domain did not
- Put a feature branch on an existing Coolify URL, then put it back
- Two Umami first-boot checks I nearly missed on Coolify
- Choosing a VPS in Australia for self-hosting
- Point your app at a Coolify Postgres by container name, not IP
- A launchd job that dies with no code change
- Coolify quietly bakes your build secrets into the image layers
- A full VPS disk on Coolify: 1905 MB per rebuild, down to 31 MB
- The Next.js standalone healthcheck trap on Coolify
- serve -s makes every URL on a multi-page site come back 200