Detect unsafe repo-relative bind mounts in Git-based Compose apps and offer persistent remapping

What problem will this feature address?

When deploying a Docker Compose application from a Git repository, many upstream Compose files use relative bind mounts like ./data:/data or ./config:/app/config. In Dokploy, repository files are re-cloned on each deployment, and the recommended persistent path is ../files instead. This means many standard Compose setups do not work reliably out of the box in Dokploy unless the user manually rewrites the Compose file.

Describe the solution you'd like

Dokploy should detect repo-relative bind mounts in Git-based Docker Compose deployments and offer a built-in fix.

Suggested behavior:

• detect mounts like ./data:/data or ./config:/app/config
• warn that these paths are unsafe for persistent writable data in AutoDeploy
• optionally remap them to a Dokploy-managed persistent path, ideally aligned with the existing files directory structure

This would let users deploy common upstream Compose files without having to fork the repository or patch the Compose file manually.

Describe alternatives you've considered

• Manually rewriting mounts to ../files/...
• Switching to Docker named volumes
• Forking the upstream repository
• Using Dokploy patches

These workarounds exist, but they all require changing or maintaining deployment-specific overrides for upstream Compose files.

Additional context

Dokploy already documents that repository-mounted files should be moved to File Mounts and referenced through ../files/.... This request is about improving compatibility with real-world third-party Compose files that commonly use relative bind mounts. A warning-only mode would already help, but an optional automatic remap would be even better.

Will you send a PR to implement it?

No

Start by tracing Git-based Docker Compose deployment handling and the existing File Mounts path described in the issue. Review how repo-relative bind mounts such as ./data:/data are identified, then establish acceptance cases for warning users and optionally remapping mounts to the persistent files structure.