Multi-server feature

[jocubeit]

Am I correct in understanding that the multi-node feature is just for clusters (swarm) which provides replicated redundancy via a load balancer?

If so, are there any plans to add multi-server functionality? That is, the ability to run disparate apps/services on servers all managed by a dokploy instance. Coolify has this functionality, you add additional VPSs without needing them to be part of a cluster.

I installed Dokploy on a VPS, and mistakenly thought that the multi-node functionality was the same as the Coolify's multiple server functionality. In my use case I would have to have an enormous VPS to house all the containers I need to run, and then I have a single point of failure in that huge server. Running a cluster then becomes quite expensive as they all have to be very large servers.

[Siumauricio]

Hi @jocubeit ,

Docker swarm is specifically to manage multiple servers as nodes and scaling, you can build and deploy from the node manager and if you want you can also deploy an application to a specific node(server), however of course we have a single point of failure, so you would need more manager nodes to share traefik information and more things to have an abundance of nodes to prevent single point of entry failures and also the problem is that builds are executed on the manager node which can cause instability.

The multi server feature of coolify I don't know to what extent it allows manager nodes to overflow and recover from a failure in the main node.

According to the documentation they do not natively integrate docker swarm and it is experimental so I do not know to what extent you are referring to manage multiple servers and have redundancy and recover from failures that I think it does not handle it or maybe I'm wrong.

https://coolify.io/docs/knowledge-base/docker/swarm

It's almost the same term, the main point is to be able to deploy applications on a specific node or server, you can actually do that with docker swarm as we have it integrated.

If you could give me more details on how you think it should work/steps we could create/rethink a more complex functionality thought in server management and how it currently works coolify would be great!

Thanks!

[anbraten]

From what I understand instead of using one docker socket connected to the swarm master to manage apps, a first step would be to allow adding "nodes" using an additional docker socket. So basically dokploy would be able to manage multiple docker systems or even multiple docker swarms and if I understand OP correctly you could select "deploy to swarm1" where swarm1 would be a docker connection to a swarm or just a single docker server. Each swarm / node would provide its own Traefik etc if you select multiple servers (as in Coolify) it would deploy it to independet systems as if you would manually deploy to two dokploys, but instead both systems are sharing one UI / management system.

[ErSauravAdhikari]

Isn't this already present?

[ErickLuis00]

An easy way to eliminate a single point of failure now is to deploy Traefik in the cluster in global mode. This way, there will be a Traefik instance on each node, all with the same configurations (through labels). It will be possible to receive traffic through the IP of any node in the cluster using an external load balancer. If one node goes down, the others will continue receiving traffic and routing it to the correct containers.

[Siumauricio]

An easy way to eliminate a single point of failure now is to deploy Traefik in the cluster in global mode. This way, there will be a Traefik instance on each node, all with the same configurations (through labels). It will be possible to receive traffic through the IP of any node in the cluster using an external load balancer. If one node goes down, the others will continue receiving traffic and routing it to the correct containers.

The question is that you need to synchronize the file system of the traefik files for this to work.

[jhorlima]

Hii, @Siumauricio!

I know this issue is closed, but I couldn't find another that directly addresses my question, so I decided to ask here.

I'm looking for the best practice to set up internal communication between containers distributed across different VPS servers managed by Dokploy. I currently have two VPSs (and plan to add more) running various services. Intentionally, one of them has more resources, and I want to use it exclusively for a database, while the other VPSs will host the remaining applications. My main goal is to ensure that containers on these VPSs can communicate with each other using Docker's internal network (preferably dokploy-network) or, at the very least, the VPSs' private network.

Initially, I ran into a problem where containers couldn't connect. For example, I have the main Beszel instance on one VPS and two Beszel agents (one on each VPS). To work around this, I adopted the following sequence of steps:

1. I ran docker swarm leave --force on the second VPS.

2. I then performed a docker swarm join from the second VPS to the primary VPS, configuring both as Managers in the Swarm cluster.

3. Finally, I executed the Dokploy "remote server" setup command on this second VPS.

With this strategy, communication between the containers was successfully established. Additionally, I configured UFW, which was previously blocking the Swarm ports. Although the installation generated a warning, the functionality is working, except for the Docker Swarm service listing on the Dokploy frontend, which doesn't appear.

My main question is: is this practice of adding the VPS to the Swarm before configuring the Dokploy "remote server" the recommended approach by your team? Is there any other practice or workflow you recommend to ensure this cross-VPS container connectivity, especially considering that I cannot allocate a database in Dokploy to a specific VPS using only Docker Swarm?

I can open a new issue if that's more appropriate.