How to deploy something on a worker node

[luizkowalski]

I have two hosts, one main and one worker

I have a valkey database prepared, which I selected to deployed on the worker node, but when I do that, I get this error

Starting redis deployment...
8: Pulling from valkey/valkey
Digest: sha256:fea8b3e67b15729d4bb70589eb03367bab9ad1ee89c876f54327fc7c6e618571
Status: Image is up to date for valkey/valkey:8
docker.io/valkey/valkey:8
Error: Error: (HTTP code 503) unexpected - This node is not a swarm manager. Worker nodes can't be used to view or modify cluster state. Please run this command on a manager node or promote the current node to a manager.

am I missing something? can't I just do that?

[luizkowalski]

I still couldn't manage to deploy something on a worker node...bumping in case someone else can help

[luizkowalski]

Are you blocking the control ports?

nope, ufw is disabled.

i think the network was created by dokploy on the node, so they aren't connected

sounds like a bug to be honest, could be worth opening an issue

[djsisson]

after thinking more, i dont think its a dokploy issue as the id's are the same

but the peer ip's should list the lan ip of both machines, but one is a docker bridge and the other is a public ip

What's the advertise address on the manager and the lan ip on both

[luizkowalski]

(i deleted everything and started from scratch)

On the manager:

root@manager:~# docker info | grep 'Address'
  Node Address: 172.17.0.1
  Manager Addresses:

on the worker

root@worker:~# docker info | grep 'Address'
  Node Address: 91.99.191.194
  Manager Addresses:
root@worker:~#

manager's addres is 91.99.114.244 and the worker is the one above

[djsisson]

these are both incorrect

they need to be a lan ip, outside the docker address pools
the first one is a docker bridge, the second one is a public ip

if youre running this on a public ip, you are exposing everything over the internet

if this is hetzner make sure you set up a private network

then use the private network ip as your advertise address, you can leave the listen address as 0.0.0.0 as long as you block the ports using hetzner firewall, otherwise also set listen address

if you set your hetzner network to be 10.0.0.x then make sure you alter the address pools so you don't overlap

currently because your nodes are on different subnets, they cannot communicate, and should definitely not be communicating over the public internet.

[konmeo]

The only way I was able to get my Swarm setup to work to then deploy to worker node is by making sure that the advertised IP address for both manager and worker nodes are explicitly set:

# new manager:
ADVERTISE_ADDR=<manager_ip> https://dokploy.com/install.sh | sh
# -OR- existing manager:
docker swarm leave
docker swarm init --advertise-addr=<manager_ip>

# worker (token from Cluster -> Add Node):
docker swarm leave
docker swarm join --token <token> --advertise-addr=<worker_ip> <manager_ip>:2377

[luizkowalski]

did exactly that now, did not help unfortunately, this is what I'm seeing

manager:

Swarm: active
  NodeID: f14xzdsoowf8vmdusr2x3zhaf
  Is Manager: true
  ClusterID: n6b5q3xfot3my80mq6q8gj6m8
  Managers: 1
  Nodes: 2
  Default Address Pool: 10.0.0.0/8
  SubnetSize: 24
  Data Path Port: 4789
  Orchestration:
   Task History Retention Limit: 5
  Raft:
   Snapshot Interval: 10000
   Number of Old Snapshots to Retain: 0
   Heartbeat Tick: 1
   Election Tick: 10
  Dispatcher:
   Heartbeat Period: 5 seconds
  CA Configuration:
   Expiry Duration: 3 months
   Force Rotate: 0
  Autolock Managers: false
  Root Rotation In Progress: false
  Node Address: 91.99.114.244
  Manager Addresses:
   172.17.0.1:2377

manager address is still 172...

[djsisson]

what command are you running ?

[luizkowalski]

@djsisson and @konmeo thank you for the tips; it was indeed the private network. I put it all behind a private network on Hetzner, using IPs like 10.0.0.2, and it works like a charm now!

[quangthien27]

Had same issue, worker added to swarm through public IP but load balancer is not working properly due to advertise address.
So I have run below:

On manager

1. Note down running services
   docker service ls

2. Leave swarm (important: all services will be removed, your dokploy will be down and all apps stop. Don't panic, dokploy has everything in volumes, containers will keep running as Independent ones, so you probably won't loose anything. But do it at your own risk!
   docker swarm leave --force

3. Create new manager using install script
   export ADVERTISE_ADDR=10.0.0.2 (change it to your manager private IP when adding it to a private network, example on Hetzner)
   curl -sSL https://dokploy.com/install.sh | s

4. Dokploy should now be back online, but you need to reload all apps. Compare the services list with notes above to make sure nothing is missing

On worker

leave swarm. Make sure it's in same private network with manager, then join the new manager again using the new private advertise address. command in konmeo comment

Hope that helps

[shivam-clary]

How do we "select" for it to be deployed on a worker server exactly? I don't see an option to do that

[shivam-clary]

I do not see that service at all. If I do docker service inspect supervisor

[]
Error: no such service: supervisor

I also tried docker service ls
But it doesn't have the service that I am looking for at all.

[djsisson]

when you deployed did you not select stack? it sounds like you only did a normal compose not a swarm stack

[shivam-clary]

Not sure if it helps or not but this is what I see in the logs when I try to deploy it:

Initializing deployment
File 'docker-compose.yml' created: ✅
╔══════════════════════════════════════════════════════════════════════════════╗
║                                                                              ║
║ App Name: clary-triggerdevwebapp-rjhcp1                                      ║
║ Build Compose 🐳                                                             ║
║ Detected: 0 mounts 📂                                                        ║
║ Command: docker compose -p clary-triggerdevwebapp-rjhcp1 -f                  ║
║ docker-compose.yml up -d --build --remove-orphans                            ║
║ Source Type: docker raw ✅                                                   ║
║ Compose Type: docker-compose ✅                                              ║
║                                                                              ║
╚══════════════════════════════════════════════════════════════════════════════╝
time="2026-02-23T13:34:02Z" level=warning msg="The \"NODE_MAX_OLD_SPACE_SIZE\" variable is not set. Defaulting to a blank string."
time="2026-02-23T13:34:02Z" level=warning msg="a network with name webapp exists but was not created for project \"clary-triggerdevwebapp-rjhcp1\".\nSet `external: true` to use an existing network"
Container clary-triggerdevwebapp-rjhcp1-postgres-1 Running
Container clary-triggerdevwebapp-rjhcp1-electric-1 Running
Container clary-triggerdevwebapp-rjhcp1-docker-proxy-1 Recreate
Container clary-triggerdevwebapp-rjhcp1-clickhouse-1 Running
Container clary-triggerdevwebapp-rjhcp1-redis-1 Running
Container clary-triggerdevwebapp-rjhcp1-webapp-1 Running
Container clary-triggerdevwebapp-rjhcp1-minio-1 Running
Container clary-triggerdevwebapp-rjhcp1-docker-proxy-1 Recreated
Container clary-triggerdevwebapp-rjhcp1-supervisor-1 Running
Container clary-triggerdevwebapp-rjhcp1-docker-proxy-1 Starting
Container clary-triggerdevwebapp-rjhcp1-docker-proxy-1 Started
Docker Compose Deployed: ✅

I also asked chatgpt for some help, it says that this is happening because it is running in raw docker mode. It should rather be running in Swarm mode. I don't know if it makes any sense.

[shivam-clary]

Is there anyway to switch the mode after deployment?

[shivam-clary]

Alright thanks @djsisson . I just created a new app with stack mode selected. Now it is working properly

[hbroer]

I don't get it. I installed Dokploy on a small vm and a worker node on a big vm. In my naive world I now could setup a app via template (i did with gitlab) and it will run on a worker node. Nope. it crashed the leader node... So ok... new setup, added a constrain... crashed... yea deploy constrains don't apply for what ever reason to templates... without warning, blew up the leader node again. Next try remote server... theoretical maybe possible... but there I can not tunnel traffic trough the leader node and use the internal network... yay...

Just sain. I rly thought this ecosystem is doing smarter than this in 2026, but docker ecosystems still feel like the most unstable and unintuitive pice of software, the opposite of what it is marketed as. It's frustrating. Rly frustrating. And not sain Azure for example is better. That's way more crap than this.