Is there a safe/documented procedure to recreate dokploy-network with a larger subnet?

[theplatypus]

Hello,

First of all, thanks for your work on this project.

We are running Dokploy on a Docker Swarm cluster with a fairly large number of services, and we recently reached the IP address limit of the default dokploy-network.

As a temporary mitigation, we switched several single-replica services from VIP to DNSRR, which freed enough IP addresses to keep the cluster operational.

However, for a more sustainable solution, we are considering recreating dokploy-network with a larger subnet.

Before attempting this on a production cluster, I wanted to check:

• Is recreating dokploy-network with a different/larger subnet officially supported?
• Is there a documented or recommended procedure to do so safely?
• Can Dokploy automatically recreate/reconnect its services and Traefik configuration after the network is recreated, or do services need to be manually redeployed?
• Are there any Dokploy-specific components or assumptions that could break if the network is manually removed and recreated?

We would of course test the procedure on a separate Swarm cluster before doing it in production, but I would like to avoid relying on an unsupported procedure or leaving Dokploy’s internal state inconsistent with Docker.

I am also aware of the ongoing work around network isolation/custom networks. Until that becomes available, I am mainly looking for the safest way to increase the capacity of the existing shared dokploy-network.

Thanks!

[dosubot[bot]]

Hi @theplatypus! I'm Dosu and I'm helping the Dokploy team.

Good news — recreating dokploy-network with a larger subnet should be safe. Here's why, and how to do it:

Why it's safe: Dokploy references the network exclusively by the string name "dokploy-network" everywhere — in Traefik setup [1], in compose service injection , and in network validation [2]. No network ID is cached in the database or configuration. Docker resolves the name to the actual network at runtime, so a recreated network with the same name is transparent to Dokploy.

The install script itself demonstrates this pattern — it does docker network rm -f dokploy-network followed by docker network create --driver overlay --attachable dokploy-network [3].

Suggested procedure for your Swarm cluster:

1. Scale down / stop all user services that are connected to dokploy-network (you can do this from the Dokploy UI or via docker service scale).

2. Stop Traefik: docker stop dokploy-traefik && docker rm dokploy-traefik — Traefik runs as a standalone container, not a Swarm service [4].

3. Remove the Dokploy core Swarm services (or at least scale them to 0): dokploy, dokploy-postgres, and dokploy-redis if present.

4. Remove the old network: docker network rm dokploy-network

5. Create the new network with your desired subnet:

   docker network create --driver overlay --attachable \
     --subnet 10.0.0.0/16 \
     dokploy-network

6. Restart core services — scale dokploy-postgres and dokploy back up. They reference the network by name in their service specs and will reconnect automatically.

7. Let Dokploy recreate Traefik — restarting the Dokploy app service should trigger Traefik provisioning, or you can use the Traefik settings in the UI. Alternatively, manually recreate it and run docker network connect dokploy-network dokploy-traefik.

8. Redeploy user services through the Dokploy UI — this is needed because each service/stack needs to rejoin the new network.

Things to be aware of:

• Traefik's static config hardcodes network: "dokploy-network" for its Docker provider [5], so as long as the name stays the same, routing will work.
• Compose services in shared mode get dokploy-network injected automatically on deploy [6], so redeploying from the UI is sufficient to reconnect them.
• There is no Dokploy-level "reconnect all services" button — each service needs a redeploy to rejoin the new network.

This is not an officially documented procedure, but the architecture supports it cleanly since everything is name-based. Definitely validate on your test Swarm first as you planned.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.