Dokploy runs fine on one VPS until it doesn’t. Once you’ve got a handful of apps, a Postgres instance, and a couple of background workers competing for the same 4GB box, the fix isn’t a bigger server. It’s more servers, managed from one place.

Why split at all

A single Dokploy instance is both the control plane and, by default, the place your apps actually run. That’s fine for a side project. It stops being fine when a memory-hungry build process on one app slows down an unrelated production site, or when you want your database physically separate from anything public-facing.

Dokploy handles this with remote servers: you keep one Dokploy instance as the dashboard, and attach additional VPS instances as deploy targets. The dashboard stays put. The workloads move.

1. Provision the second server

Spin up a plain VPS. Don’t install Dokploy on it — that’s the point. It just needs:

• A public IP reachable from your main Dokploy server
• Docker installed (Dokploy will do this for you during the add-server flow if it isn’t)
• Root SSH access, or a sudo user with a key Dokploy can use

2. Add it in Dokploy

In the dashboard, go to Settings → Servers → Add Server. You’ll paste in the IP and either generate a new SSH key pair for Dokploy to manage or supply your own. Dokploy connects, installs Docker if missing, and joins the box to a Docker Swarm cluster with your primary server as the manager node.

This step is where it usually breaks the first time: if your cloud provider’s firewall blocks inbound SSH from arbitrary IPs, or you’ve already locked port 22 down to a specific allowlist, the connection test fails silently and you get a generic “could not connect” error. Temporarily open SSH to the primary server’s IP, or add it to your allowlist, before you start the wizard.

3. Deploy to the right server

When you create or edit an application, there’s a server selector. Pick the target. From then on, that app’s containers run on that box, but you still manage it — logs, env vars, deploys — from the main dashboard.

What doesn’t follow automatically

Volumes are per-server. A bind-mounted volume on server A is not visible to a container on server B. If you’re relying on local file storage (uploaded images, SQLite files), moving an app to a new server means moving the data too, by hand. Switch to object storage (S3-compatible) before you split servers, not after.

Databases need real connection strings. If your app and its Postgres container were both on the primary server, localhost or the Docker service name worked. Once they’re on different servers, you need the database server’s actual IP or a private network address, and the database’s firewall has to allow it. Dokploy doesn’t create a private network between servers for you — you’re responsible for either opening the DB port to the app server’s IP or setting up a VPN/private network layer (most providers offer one, like Hetzner’s private networks or DigitalOcean’s VPC).

Traefik runs per-server. Each server gets its own Traefik instance handling its own domains. There’s no shared load balancer across servers unless you put one in front yourself (a separate reverse proxy, or your DNS provider’s load balancing). Don’t assume requests to one domain can land on either server interchangeably.

A split that actually works

The common, low-drama pattern: primary server runs Dokploy plus your lower-traffic apps. A second server runs your database exclusively, with its port firewalled to just the app server’s IP. A third, if you need it, takes CPU-heavy background jobs. You’re not building a cluster, you’re just keeping noisy neighbors off each other’s hardware.

flowchart LR
    D["Dashboard (primary)"] --> A["Server A: low-traffic apps"]
    D --> B["Server B: database only"]
    D --> C["Server C: background jobs"]
  

Start with two servers, not five. Every server you add is one more thing that needs its own firewall rules, its own disk monitoring, its own unattended-upgrades cron job. Multi-server Dokploy solves resource contention — it doesn’t remove the operational work of running a VPS, it just multiplies it.

---