Dokploy Server Requirements: How Much RAM, CPU and Disk per App, with Sizing for 1 to 20 Applications

Dokploy's installation docs state the minimum plainly: "your server should have at least 2GB of RAM and 30GB of disk space", a tested Linux distribution, and ports 80, 443 and 3000 free. That is the requirement to install Dokploy. The requirement to run things on it is set by the applications, databases and builds you add, and that is what this guide quantifies, ending in four sizes you can order as presets on the MassiveGRID Dokploy hosting page.

What the installer requires

• Operating system: the installer is tested on Ubuntu 24.04, 22.04 and 20.04 LTS, Debian 12, 11 and 10, Fedora 40 and CentOS 9 and 8. Use Ubuntu 24.04 or Debian 12; the project's hardening guide notes that its automated security checks target Ubuntu and Debian LTS only.
• Memory and disk: 2 GB of RAM and 30 GB of disk. A CPU count is not specified.
• Ports: 80 and 443 for Traefik, 3000 for the dashboard; the install fails if any is in use.
• A fresh server with root. The script installs Docker, initialises Swarm mode and starts the Dokploy, PostgreSQL and Traefik services.

After installation the platform itself uses roughly 350 to 450 MB of RAM and a few percent of one core at idle. Everything else below is your workload.

RAM: add up the services

Memory is the resource that runs out first on a Dokploy server, because every container keeps its share whether or not it is busy. Typical steady-state figures:

Worked example: Dokploy (400 MB) plus a Next.js app (150 MB), an API (120 MB), PostgreSQL (512 MB) and Redis (100 MB) is about 1.3 GB at rest. Add a build and you are at 2 to 3 GB. That is why the smallest sensible production server has 4 GB, and why a second project stack usually means another gigabyte. Swap is a warning sign on a Dokploy server, not a plan.

CPU: builds set the size, not traffic

Serving web traffic rarely troubles a modern vCPU: Dokploy, Traefik and a handful of containers idle below 15 percent of a core. Docker builds are the opposite, pinning every core for the length of a dependency install and a compile. A Next.js build takes 45 to 90 seconds on two cores and several minutes for a monorepo; while it runs, the apps on the same server slow down.

Two decisions follow. First, how many cores: two is enough while you deploy a few times a day; four once several people push regularly. Second, shared or dedicated: on shared infrastructure a build that takes 35 seconds on a quiet host can take four minutes when neighbours are busy, and the st (steal) column in top shows why. For production, dedicated cores remove that variance. Dokploy also runs one build at a time per server by default (Settings, Deployments lets you raise it), and can move builds to a separate build server entirely, which is the right answer when a team outgrows a single machine.

Disk: images accumulate

Thirty gigabytes is tight the moment you build regularly. Every deployment creates image layers, every base-image bump stores a whole new image, and old layers stay until pruned. A busy Dokploy server after three months typically holds 5 to 15 GB of images and build cache, 2 to 10 GB of volumes (databases, uploads), 3 to 5 GB of system and Dokploy files, and a few gigabytes of logs. A full disk is also the first cause the Dokploy troubleshooting docs list for a dashboard that stops loading: the Dokploy database goes into recovery mode.

Start at 64 GB for one or two projects and 128 GB beyond that, switch on Dokploy's Docker cleanup or schedule docker system prune, and keep database backups off the server on S3-compatible storage so disk pressure never threatens data.

Four sizes, from one app to twenty

Prices per month in New York, London or Frankfurt with 1 TB of traffic and one IPv4, before billing-cycle discounts; the Dokploy hosting page has the same rows with a Configure button that presets the configurator. A heavy single application, Supabase for instance, sits in the Growth row despite being one stack, because PostgreSQL wants the memory.

Requirements for multi-server setups

Two Dokploy features change the arithmetic. A build server (Remote Servers, type Build Server) takes the CPU spike off the production machine; it needs Docker, an SSH key and a container registry, and is for Applications only at the time of writing, not Compose. A Swarm cluster adds worker nodes of the same architecture as the manager, again through a registry, with ports 2377, 7946 and 4789 open between nodes only. Remote deployment servers need only Docker and Traefik, which Dokploy installs; monitoring on remote servers is not supported. Size each node for its role: cores for the build server, memory for the database node, and keep the manager on the most reliable machine you have, because it holds the control plane. Our multi-node guide has reference configurations.

Frequently Asked Questions

Can Dokploy run on 1 GB of RAM?

Not reliably. The installer requires 2 GB, the platform itself uses about 350 to 450 MB, and the first application and database push past a gigabyte before any build runs. Two gigabytes runs the dashboard and a small app for evaluation; 4 GB is the realistic floor for anything you depend on.

How many vCPUs does Dokploy need?

Dokploy does not state a CPU minimum. Two cores cover the dashboard and light production; builds are what saturate CPU, so move to four cores, or to dedicated cores, when deploys are frequent or build times start to vary from run to run. A separate build server removes the problem from the production machine altogether.

Does Dokploy need a GPU or ARM support?

No GPU. Dokploy runs on amd64 servers (the standard for MassiveGRID VPS) and the Docker images it deploys must match the server architecture; in a Swarm cluster the docs require every node to share the manager’s architecture.