[Bug]: Persistent storage volumes for Preview Builds

[sponte]

Error Message and Logs

Configured persistent storage volumes automatically append the -pr-<number> suffix to the source which can cause issues if user wants to mount a socket e.g. /var/run/docker.sock.

This is happening inside of this function app/Jobs/ApplicationDeploymentJob.php:1915:

    private function generate_local_persistent_volumes()
    {
        $local_persistent_volumes = [];
        foreach ($this->application->persistentStorages as $persistentStorage) {
            if ($persistentStorage->host_path !== '' && $persistentStorage->host_path !== null) {
                $volume_name = $persistentStorage->host_path;
            } else {
                $volume_name = $persistentStorage->name;
            }
            if ($this->pull_request_id !== 0) {
                $volume_name = $volume_name.'-pr-'.$this->pull_request_id;
            }
            $local_persistent_volumes[] = $volume_name.':'.$persistentStorage->mount_path;
        }

        return $local_persistent_volumes;
    }

Steps to Reproduce

1. Create application that uses Github and enable preview deployments
2. Configure persistent storage for your application and set source and target to /var/run/docker.sock
3. Create a pull request in Github

Expected result: The configured bind mount is provided to the preview deployment container without changing the source path

Actual result: The -pr-<number> suffix is added to the source path breaking the deployment.

Example Repository URL

No response

Coolify Version

v4.0.0-beta.397

Are you using Coolify Cloud?

No (self-hosted)

Operating System and Version (self-hosted)

CentOS Stream 10 (Coughlan)

Additional Information

No response

[sponte]

I haven't got the PR to fix it yet, but solved the issue in my local deployment via my fork - feel free to have a look. There are also other fixes which I haven't raised issues for yet.

https://github.com/coollabsio/coolify/compare/main...eu-evops:coolify:main?expand=1

[dentroai]

I believe I am experiencing a variation of this bug with managed Docker volumes, not just bind mounts.

Setup: A service deployed from a main branch (e.g., development). Persistent storage is configured using a Volume Mount (not a Directory/Host Mount). In the UI, a Name is provided for the volume, but the Source Path is left blank. The Destination Path is set to /app/data.

The application uses a SQLite database, which is stored in this volume at /app/data/database.db.

Preview deployments are enabled for pull requests.

Problem: When a preview deployment is created for a pull request, it appears to be mounting the exact same volume as the main development branch, instead of creating its own new, isolated volume (e.g., my-volume-pr-16).

This causes the two live deployments to interfere with each other's SQLite database file. The result is immediate database corruption and sqlite3.OperationalError crashes on both the preview and main branch applications, as their schemas become out of sync with the shared, corrupted database file.

Expected Behavior: The preview deployment should automatically create and use a completely separate, isolated volume for its persistent storage to ensure the preview environment cannot conflict with the data of another deployment. I have confirmed this behavior is consistently reproducible by deleting all deployments and Docker volumes to start from a clean slate. The problem reappears every time a preview deployment is created alongside a main deployment. This shows that the volume isolation issue for preview builds also affects managed volumes, not only bind mounts.

[dentroai]

I have new information after checking my server:

Using docker volume ls, I can confirm that Coolify is successfully creating the correctly suffixed preview volume (e.g., my-volume-name-pr-16).

However, the data conflict between my main deployment and the preview deployment is still happening. This makes me think: the bug is not that the preview volume isn't being created, but that the preview container is not being mounted to it. It seems to be incorrectly mounting the main branch's volume instead, while the correct -pr-16 volume sits on the disk, unused.

This would explain why the separate volume exists, but the deployments still interfere with each other's data. It points to a bug in how the container's mount configuration is generated during a preview deployment.