Size the containers, not the engine
The single most common mistake with a Docker VPS is asking "how much does Docker need?" when the honest question is "how much do my containers need?" The Docker engine and its background daemon use a modest slice of memory. The weight comes from what you stack on top: a database holding a working set in RAM, a cache that grows to fill what you give it, a reverse proxy, a couple of application services and maybe a queue. Each is a tenant, and the VPS is the building.
So the right way to plan is to open your Compose file and add the containers up. A Postgres instance might be comfortable at 512 MB to 1 GB for a small project. An app runtime often wants another 256 to 512 MB. A cache, a proxy and a metrics agent each take a bite. Sum the realistic figures, then add roughly a quarter on top for the host, log buffers and short spikes. That total is your RAM target — and it is why 2 to 4 GB is the sweet spot for a typical self-hosted stack rather than the 1 GB people first reach for.
Disk is the resource that ambushes beginners
Storage on a Docker host behaves differently from a plain application server because Docker keeps history. Every pulled image, every build layer, every stopped container and every log file lingers until something removes it. A stack that fits neatly in 10 GB on day one can quietly double over a few months of updates, because each rebuild leaves the old layers behind. People discover this when a deploy fails with "no space left on device," not before.
| What eats disk | Why it grows | Habit that keeps it in check |
|---|---|---|
| Images and build layers | Old versions stay after each pull or build | Run a scheduled prune of unused images. |
| Container and app logs | Default JSON logs have no size limit | Set log rotation limits in the daemon or Compose. |
| Named volumes and databases | Real data accumulates over time | Buy disk with headroom and monitor volume size. |
When one core stops being enough
CPU is usually the calmest of the three resources for a self-hosted stack, but it has sharp edges. A single vCPU is fine while services idle and handle occasional requests. It becomes the bottleneck in three situations: building images on the box, several containers getting busy at the same moment, and a database doing heavy queries while the app also serves traffic. Two vCPUs remove most of that friction and are the reason the recommended baseline is not a single core.
A short buying checklist for Docker
- Add up each container's realistic memory, then add 25 percent for the host and spikes.
- Buy at least double the disk your images and volumes need today.
- Prefer two vCPUs unless the stack is tiny and mostly idle.
- Confirm the plan uses NVMe or SSD; container I/O is sensitive to slow disks.
- Decide in advance whether you will build on the server or pull finished images.
Operating a Compose stack without surprises
Build here or build elsewhere
Building images on a small VPS is convenient but expensive: it competes with running containers for CPU and memory and it fills the disk with intermediate layers. If your workflow allows, build images somewhere else and pull the finished result, which turns a deploy into a quick download. When you must build on the server, do it during a quiet window, add temporary swap to survive the memory peak, and prune afterward.
Swap as a safety net, not a plan
A small swap file can save a stack from being killed during a brief memory spike, such as a build or a migration. It is a seatbelt, not an upgrade: if containers rely on swap during normal operation, the server is undersized and disk-speed latency will show up as sluggish responses. Use swap to survive rare peaks, then size the plan so day-to-day work stays in real RAM.
Persistence and backups
The containers are disposable; the volumes are not. Know exactly which named volumes and bind mounts hold real data — databases, uploaded files, configuration — and back those up on their own schedule. A snapshot of the whole disk is convenient for fast recovery, but a tested database dump is what actually protects the data you would miss. Keep the Compose file and environment files in version control so the stack itself is reproducible.
Scaling the honest way
When a Compose host feels tight, resist the urge to keep piling services onto it. Move the heaviest tenant — usually the database — to its own plan, or split unrelated projects across separate small servers. A single overloaded box with ten containers is harder to reason about and riskier than two focused ones. Upgrade when memory pressure, disk growth or CPU contention are consistent, not after the first busy afternoon.
Ready to size your stack?
Pick a plan with the RAM and disk headroom your Compose file actually needs.