Issue with Volume Mounting in Docker Compose

[sotoplatero]

I'm experiencing an issue where volume mounts defined in my docker-compose.yml are not working as expected when deployed through Dokploy's AutoDeploy feature from a Bitbucket repository. The containers are created and run without errors, but the mounted directories and files are either missing or not populated inside the container.

This same setup works perfectly in both of the following environments:

• Running docker compose up locally.
• Running docker compose up manually via SSH on the same server used by Dokploy.

This strongly suggests the problem is specific to how Dokploy handles context or volume resolution during AutoDeploy.

Below are the detailed reproduction steps, observed behavior, and additional information.

To Reproduce

1. Deploy the following docker-compose.yml using Dokploy:

services:
  web:
    image: volttus/odoo-enterprise:18.0
    depends_on:
      - db
    volumes:
      - odoo-data:/var/lib/odoo
      - ./:/mnt/extra-addons/va_subscription_18
      - ./docker/config/odoo.conf:/etc/odoo/odoo.conf
    environment:
      - HOST=db
      - USER=odoo
      - PASSWORD=odoo
      - DB_NAME=odoo
    networks:
      - custom_network
      - dokploy-network
    restart: always

  db:
    image: postgres:16
    environment:
      - POSTGRES_DB=postgres
      - POSTGRES_USER=odoo
      - POSTGRES_PASSWORD=odoo
      - PGDATA=/var/lib/postgresql/data/pgdata
    volumes:
      - postgres-data:/var/lib/postgresql/data/pgdata
    networks:
      - custom_network
    restart: always

volumes:
  odoo-data: null
  postgres-data: null

networks:
  custom_network:
    name: ${NETWORK_NAME:-odoo_va_subscription_18_network}
  dokploy-network:
    external: true

2. Wait for deployment to complete.
3. Enter the web container and inspect the mount points:
   • /mnt/extra-addons/va_subscription_18
   • /etc/odoo/odoo.conf
   • /var/lib/odoo

Current vs. Expected behavior

Current behavior:

• The container starts without error.
• However, the mount points are not populated as expected:
  • /mnt/extra-addons/va_subscription_18 is empty or missing.
  • /etc/odoo/odoo.conf is not present inside the container.
  • /var/lib/odoo does not persist data across restarts.

Expected behavior:

• The current working directory should be mounted correctly to /mnt/extra-addons/va_subscription_18.
• The file ./docker/config/odoo.conf should appear at /etc/odoo/odoo.conf inside the container.
• The named volume odoo-data should be mounted to /var/lib/odoo and preserve Odoo data.

Provide environment information

NETWORK_NAME=odoo-network

Which area(s) are affected? (Select all that apply)

Cloud Version

Are you deploying the applications where Dokploy is installed or on a remote server?

Remote server

Additional context

• The deployment is managed using Dokploy's AutoDeploy feature from a private Bitbucket repository.
• The docker-compose.yml file is located in the root of the repository.
• Dokploy detects the file and initiates the deployment without errors in the UI or logs.
• The issue occurs only when the container is started via AutoDeploy.
• When the exact same docker-compose.yml is run locally using docker compose up, all volume mounts work correctly.

Additionally, if I SSH into the same server used by Dokploy and run docker compose up manually from the console, the volumes are mounted as expected.

This suggests the issue is related to how Dokploy interprets the working directory or volume context during the AutoDeploy process, rather than an error in the Compose file itself.

Will you send a PR to fix it?

No

[Siumauricio]

The docker compose you shared doesn't work, I need permissions to download those images apparently, another thing, when using auto deploy with dokcer compose and you are using volumes, every time you deploy the directory will be deleted, so you need to use the file mounts that are in the advanced tab https://docs.dokploy.com/docs/core/troubleshooting#i-added-a-volume-to-my-docker-compose-but-is-not-finding-the-volume for mounts and so on.

You can see an example of many templates we have where we use mounts check here:

https://github.com/Dokploy/templates/blob/main/blueprints/plausible/docker-compose.yml#L18-L19

[sotoplatero]

Just to clarify: the docker-compose.yml I shared is not a full reproduction — it's only meant to show how volumes are defined.

The file is part of the repository, not an isolated config. That’s why I’m using relative paths like:

volumes:
  - odoo-data:/var/lib/odoo
  - ./:/mnt/extra-addons/va_subscription_18
  - ./docker/config/odoo.conf:/etc/odoo/odoo.conf

I’ve read the docs and understand the behavior of mounts in AutoDeploy. The issue isn’t that volumes get deleted — it’s that repository folders and files aren’t being mounted at all during AutoDeploy, even though the same setup works fine locally and via SSH on the same server.

Any help would be appreciated.

[GeitV]

@sotoplatero did you get to some solution?

I've created custom Dockerfile to copy the configs over to container (running pocketbase, have migrations and hooks in the same repo). But this is not ideal - as this means deployment creates restart in DB, whereas the running application auto-updates itself when files update (so if the volumes would work correctly, no restart would be needed).

[Davincible]

I seem to be hitting the same issue. Cant get any volume to work in combiation with github autodeploy

[sagarey]

The same issue: when the code hasn't changed, deployment causes the bind mount folder in the service to be emptied, but the files in the actual bound host machine folder exist normally.

functions:
    container_name: supabase-edge-functions
    image: supabase/edge-runtime:v1.69.6
    restart: unless-stopped
    volumes:
      - ./volumes/functions:/home/deno/functions:Z

When redeploying, there are no files in /home/deno/functions

[Siumauricio]

Okay, I really see the problem here:

when doing the first deployment, it works fine

but with subsequent deployments, what happens is that when dokploy extracts a repository from any git source (GitHub, Bitbucket, Gitea, GitLab, etc.), the folder where it was located is deleted because we do a git clone on the directory again, which clears everything

and if you were using this syntax, it means that you are mounting the entire directory of your repository inside the container

volumes:
  - ./:/mnt/extra-addons/va_subscription_18 # Or
  - ./docker/config/odoo.conf:/etc/odoo/odoo.conf

What happens is that when we do a git clone, we clean the folder and download the repository again, which causes Docker to lose the reference to the file that is in its filesystem, and the new files have a new reference.

I think the easiest solution is to switch to using dokploy's file mounts solution, which always maintains the reference since the files are not recreated, unless you change manually or delete.

I think we can do two things

1. Update the documentation and explain this behaviour (this would be the easiest and quickest option).
2. Be able to create file mounts based on the files in your repository, so you can create them quickly, but you would have to use the dokploy file mounts method we recommend inside your compose file.

volumes:
    - ‘../files/my-database:/var/lib/mysql’ ✅
    - ‘../files/my-configs:/etc/my-app/config’ ✅

[Siumauricio]

I updated the docs to cover this case

https://github.com/Dokploy/website/commit/bde61bf0b4a1cc5084bb828012ed24c0995de21f

Feel free to reopen if you have any questions

[Kakha01]

Using a ../files/ volume gives me an empty folder. It seems that's for persisting data, not for using code directly from the repo. And mounting it directly with ./my-addons-folder works on the first deployment, but breaks on any future ones because the directory gets wiped and re-cloned by AutoDeploy. So this issue has to be reopened because it's not really fixed.

[Siumauricio]

Using a ../files/ volume gives me an empty folder. It seems that's for persisting data, not for using code directly from the repo. And mounting it directly with ./my-addons-folder works on the first deployment, but breaks on any future ones because the directory gets wiped and re-cloned by AutoDeploy. So this issue has to be reopened because it's not really fixed.

The problem is, as I mentioned, that with each deployment, the folder where the code is cloned is deleted, so anything in the cloned folder will never be persistent. If you have a simple reproduction to test and help me with, that would be great.