Dokploy
Project with database + isolated docker compose: database cannot be reached
To Reproduce
- Create a project with a database service (mariadb) added from the Dokploy UI, and a docker compose service with just one container that needs to talk to the db
- For the compose service, set isolated=true
- Note that the database cannot be reached from the compose container
Current vs. Expected behavior
The current behavior does not seem to be documented and the logic behind this behavior seems unclear/questionable.
-
Since the database server service is in the project (added from the project-level UI), it seems logical that it should be reachable from the other services in that project (whether isolated or not). Otherwise what is the point of adding the db from the project-level UI?
-
As a second problem, the current behavior ends up wasting resources for no benefit. Imagine running 3 Wordpress sites that each need a MySql database. Currently Dokploy creates 3 database servers, all of them on the same network (dokploy-network). Each Wordpress, to reach its own db server, must also be connected to that same dokploy-network. So, the network-level isolation of projects from each other is gone, any security benefits are gone. But the resource consumption remains: users are left running three independent database servers, although one single server would have been enough to serve these three not-anymore-isolated databases.
Provide environment information
OS Ubuntu 24.04
Arch: x86_64
VPS Provider: Hetzner
Dokploy: v0.25.6
Trying to install: Custom docker image, similar to Wordpress
Which area(s) are affected? (Select all that apply)
Databases, Docker Compose
Are you deploying the applications where Dokploy is installed or on a remote server?
Same server where Dokploy is installed
Additional context
I am aware I can run the db as a service inside the compose file; this would mitigate my current situation, but not resolve the root problem.
Furthermore: if using Dokploy means manually messing about with compose files, it loses a lot of the advantage over the much simpler dockge or even the bare docker-compose cli.
Will you send a PR to fix it?
No
I was just about to post about this. I've not actually tried it but I was interested in the isolation setting to move my "projects" onto their own networks but it seems like only Dockerfile/Compose services support isolation.
So the database service ends up using dokploy-network while your isolated services use their own.
It's not ideal behaviour to be honest. I for example use Railpack currently and I cannot isolate it. I moved to a Dockerfile to fix this then realised the database service doesn't actually support isolation either.
Is there a manual way to override this?
This is not a bug. At the Docker level, it makes sense that they cannot communicate, as they are on different networks.
Isolation support was created so that you could have N number of templates of the same type without having to do strange things like changing names or adding strange IDs. For that reason, it was only enabled for Raw Mode (because problems like this would arise).
In the end, you have the convenience of having N number of templates of the same type without doing anything, but in these cases, as you mention, it is not worth enabling isolated mode since you need to interact with services that are on the dokploy-network network.
On the other hand, the dokploy-network is an overlay network, whereas when you enable isolated deployment, it uses a bridge network, so you cannot use that bridge network to connect your database, as dokploy databases are service-based (swarm).
However, you can connect overlay networks to regular containers, but that is where the conflict arises. If you have multiple compose services with the same name, there will be a conflict and you will get strange errors because containers with the same name cannot exist in the same dokploy network namespace, and you will have strange problems with traefik.
Therefore, my recommendation is to disable isolated deployment and connect all your containers to the dokploy-network, where they will be able to interact with each other.
https://docs.dokploy.com/docs/core/docker-compose/utilities#isolated-deployments
Thanks @Siumauricio - I appreciate your answer!
It seems to me, however, that by putting the databases on the dokploy-network, Dokploy negates one of its biggest advantages.
Let's take the example from the link you shared:
For example, if you want to deploy two WordPress instances, you would typically encounter service naming conflicts since they share the same network (dokploy-network). Docker doesn't allow services with identical names in the same network.
As in the example, I want to run 2 instances of Wordpress (could be two environments in the same project, like staging vs. production, or two separate projects, like personal vs. business site)
I can't deploy Wordpress as an "application", because I can neither authorize Dokploy to the Wordpress repo on Github, nor do I want to maintain a fork of Wordpress in my own Github account. (Also Wordpress is just an example - it could be any other software, incl. closed-source docker images)
So, the only remaining way to deploy these two Wordpress instances is to add them as two separate services of the type "Docker-Compose". According to the above example from the docs, I must also make these services isolated. So far so good.
But each Wordpress also requires a database.
- If I set the Wordpress services to "isolated", they will not be able to communicate with a Dokploy database, as you say.
- If I un-isolate the Wordpresses, then there will be naming conflicts (according to the documentation)
Which means the only way to deploy two functioning Wordpresses is to add the database containers in the docker-compose files, i.e. not from Dokploy's "Create Database" Menu. And I must also manually manage or assign the volumes, mounts, backups, ports, etc.
Please correct me if I've gotten it wrong - and I hope I'm wrong. Because if the above is correct, then it means that any docker image that requires a database cannot be deployed in more than one copy or more than one environment(!!), unless the user is OK with creating and managing docker-compose files manually. And that's a bummer: If one has to manually create and manage a docker-compose file anyway, docker-compose up -d is much easier than clicking around the Dokploy interface.
I'm not trying to bash Dokploy; I like it and want to use it in my infrastructure, but I'd rather understand its limits beforehand. And this behavior looks like it will create maintenance headaches and hard-to-debug problems.
I have similar question. I tried to setup a pgsql in one project, then create other applications in other projects and connect to that db, so that I don't have to create a db instance for each of the project. However, I can't connect to that db internally. It all have to be done through external link. That's not safe and unnecessary since they are all in same server, just different project.
So my question is, how to set other projects to connect to the db internally. Is there any settings can be used or have to do it mannually throught cmd line?
Same question / problem for me: I have created a DB ( mariadb ), and my app uses a Docker Compose to run (since I have many parts of my app that needs to run the same image but with different start CMD). However, Compose apps cannot communicate with DB. I understood that is a feature, but I can't manage to overcome this : I've tried to add this part to my app, and run the db with a Compose with the same network :
networks:
my-app:
name: my-app
external: true
But it still doesn't seem to work (or am I missing something else ?)
Thought this was just me missing something!
Would be good to get some clarification on the intended design here for the use cases other users have described.
I drove myself barmy trying to deploy a service which looked correct but the isolation flag was tripping me.
Thanks @Siumauricio - I appreciate your answer!
It seems to me, however, that by putting the databases on the dokploy-network, Dokploy negates one of its biggest advantages.
Let's take the example from the link you shared:
For example, if you want to deploy two WordPress instances, you would typically encounter service naming conflicts since they share the same network (dokploy-network). Docker doesn't allow services with identical names in the same network.
As in the example, I want to run 2 instances of Wordpress (could be two environments in the same project, like staging vs. production, or two separate projects, like personal vs. business site)
I can't deploy Wordpress as an "application", because I can neither authorize Dokploy to the Wordpress repo on Github, nor do I want to maintain a fork of Wordpress in my own Github account. (Also Wordpress is just an example - it could be any other software, incl. closed-source docker images)
So, the only remaining way to deploy these two Wordpress instances is to add them as two separate services of the type "Docker-Compose". According to the above example from the docs, I must also make these services isolated. So far so good.
But each Wordpress also requires a database.
- If I set the Wordpress services to "isolated", they will not be able to communicate with a Dokploy database, as you say.
- If I un-isolate the Wordpresses, then there will be naming conflicts (according to the documentation)
Which means the only way to deploy two functioning Wordpresses is to add the database containers in the docker-compose files, i.e. not from Dokploy's "Create Database" Menu. And I must also manually manage or assign the volumes, mounts, backups, ports, etc.
Please correct me if I've gotten it wrong - and I hope I'm wrong. Because if the above is correct, then it means that any docker image that requires a database cannot be deployed in more than one copy or more than one environment(!!), unless the user is OK with creating and managing docker-compose files manually. And that's a bummer: If one has to manually create and manage a docker-compose file anyway,
docker-compose up -dis much easier than clicking around the Dokploy interface.I'm not trying to bash Dokploy; I like it and want to use it in my infrastructure, but I'd rather understand its limits beforehand. And this behavior looks like it will create maintenance headaches and hard-to-debug problems.
Of course, there are downsides to all this, such as the fact that you can't have a duplicate WordPress service in the same Docker network namespace.
The only way I can think of around this is to use unique names in the Docker Compose services, something like this:
- Wordpress 1
services:
wordpress-1: # Important
image: wordpress:latest
volumes:
- wp_app:/var/www/html
- ../files/uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
environment:
WORDPRESS_DB_HOST: wp_db
WORDPRESS_DB_NAME: $DB_NAME
WORDPRESS_DB_USER: root
WORDPRESS_DB_PASSWORD: $DB_PASSWORD
networks:
- dokploy-network
volumes:
wp_app: null
networks:
dokploy-network:
external: true
- Compose 2
services:
wordpress-2: # Important
image: wordpress:latest
volumes:
- wp_app:/var/www/html
- ../files/uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
environment:
WORDPRESS_DB_HOST: wp_db
WORDPRESS_DB_NAME: $DB_NAME
WORDPRESS_DB_USER: root
WORDPRESS_DB_PASSWORD: $DB_PASSWORD
restart: unless-stopped
networks:
- dokploy-network
volumes:
wp_app: null
networks:
dokploy-network:
external: true
- Now create a dedicated dokploy database and simply use the values provided by dokploy and inject the variables into each compose.
This should work. You have two wordpress instances using the dokploy network and the database also which by default is connected to dokploy-network. The only difference is that you have a different name: wordpress-1 and wordpress-2 they are unique service name and cannot be conflicted in the dokploy network namespace.
There may be a better solution, but implementing something custom like adding random IDs to each service is not something I like to do. I prefer it to be as 1:1 as possible. I think we should clarify this use case in the documentation.
However, what I shared above should work fine without having to use isolated.
There may be a better solution, but implementing something custom like adding random IDs to each service is not something I like to do.
Docker Compose allows services to declare network-specific aliases. Would it be possible to use that to prevent name clashes when compose services refer to each other?
For example:
services:
wordpress:
image: wordpress:latest
networks:
dokploy-network:
aliases:
- wordpress.wordpress-wordpress-abcdef.dokploy.internal # <-- Maybe Dokploy can inject something like this?
