Deleting persistent storage mount silently destroys host directory contents — insufficient warning

[peterdrier]

Description

Deleting a persistent storage mount in the Coolify UI causes the host directory contents to be deleted on the next redeploy. The only safeguard is a small checkbox — far too subtle for an action that permanently destroys data.

Severity

Critical / Data Loss — this destroyed uploaded files (images) with no way to recover.

Steps to Reproduce

1. Have a running service with a persistent storage mount (e.g. /opt/docker/myapp/uploads:/app/wwwroot/uploads rw) that contains user-uploaded files
2. In Coolify UI, go to the service's Storage settings
3. Delete the persistent storage mount (there is a checkbox, but it does not clearly communicate that host directory contents will be permanently destroyed)
4. Redeploy the service

Expected Behavior

• A checkbox is not sufficient warning for permanent data destruction. This needs a prominent confirmation dialog explicitly stating: "This will permanently delete all files in [path] on the host. This cannot be undone."
• Better yet: deleting a mount should only remove the mount configuration — not delete the host directory or its contents. That's the whole point of "persistent" storage.

Actual Behavior

The host directory (/opt/docker/myapp/uploads/) was wiped clean — all files permanently deleted. The existing checkbox warning was too subtle to convey the severity of the action.

Impact

Lost all user-uploaded images (camp photos, profile pictures, etc.) from a QA environment. The database still references the file paths, so every page with images now shows broken links.

Environment

• Coolify version: latest (self-hosted, updated regularly)
• Docker on Ubuntu/Linux
• Service type: Dockerfile-based application

Suggested Fix

1. Ideally: never delete host directory contents when removing a persistent storage mount — just remove the mount configuration
2. If deletion is intentional behavior, replace the checkbox with a modal confirmation dialog that explicitly names the host path and warns about permanent data loss (similar to GitHub's "type the repo name to confirm" pattern)
3. Consider a "soft delete" approach: rename the directory instead of removing it, giving the user a window to recover