Fix Persistent Volume Data Loss After Redeploy on Coolify

Error: Coolify volume data lost after redeploy / a new empty volume is created every deploy

Coolify creates a brand-new, empty volume on some redeploys instead of reattaching the existing one, so any data the app wrote is gone even though the deploy itself succeeded.

Coolify auto-suffixes volume names with the resource's UUID. If that resource is ever recreated (its UUID changes) or you edit the storage mount's configuration after data already exists, Coolify creates a brand-new volume under the new name instead of reattaching the old one, so the app starts fresh with nothing in it. It gets worse if "Delete Unused Volumes" cleanup is enabled on the server: the now-orphaned old volume holding your real data gets deleted outright on the next cleanup run instead of just being left behind.

The fix

  1. In the resource's Docker Engine destination, set an explicit volume name and container path rather than relying on Coolify's UUID-suffixed default.

  2. Never rename or recreate the storage mount entry once real data exists in it — editing it after the fact is what triggers a new volume to be created.

  3. Disable "Delete Unused Volumes" under the server's Docker Cleanup settings until you've confirmed the correct volume is attached and holding your data.

  4. For Compose resources, define the volume block directly in docker-compose.yml instead of relying on Coolify's auto-generated storage config.

Verify it worked

docker volume ls shows the same volume name before and after a redeploy, and data written before the deploy is still present afterwards.

docker volume ls | grep <resource-uuid>

Related Coolify errors

Sources

Have Emsden Studio fix it for you — from A$149

All Coolify deploy errors