How to choose a VPS for Docker without losing container data
Docker makes delivery repeatable, but it does not remove the need to plan memory, persistent storage, backups and host security. Use this guide to choose a server that remains manageable after the first deployment.
Which virtualisation works for Docker
A KVM virtual machine is the safest default because it provides a normal kernel and predictable support for namespaces, cgroups, firewall rules and storage drivers. Container-based VPS products may work, but can restrict nested container features or kernel modules. Ask the provider explicitly and never assume that the word “Linux VPS” guarantees Docker support.
How many resources containers need
| Scenario | Starting point | Likely bottleneck |
|---|---|---|
| Small API and proxy | 1–2 vCPU, 2 GB RAM, 20–30 GB SSD | Application memory and logs |
| App, PostgreSQL and Redis | 2 vCPU, 4 GB RAM, 40+ GB NVMe | RAM and disk latency |
| Several web projects | 2–4 vCPU, 4–8 GB RAM | Isolation, CPU bursts and backups |
| CI runner or image builds | 4+ vCPU, 8+ GB RAM, fast storage | CPU and temporary disk space |
Set memory and CPU limits for every service. Otherwise one runaway worker can evict the database or reverse proxy. Leave capacity for the operating system, Docker daemon and a rolling update that briefly runs old and new containers together.
Why Docker silently fills a disk
- Keep mutable data in named volumes or bind mounts, not the writable container layer.
- Limit and rotate stdout/stderr logs.
- Monitor free inodes as well as gigabytes.
- Allow room for both old and new images during deployment.
- Move media, build artefacts and backups to external storage.
NVMe helps databases, registries and workloads with many small files. For a simple stateless API, capacity and predictable latency may matter more than headline throughput.
A practical deployment layout
Expose only a reverse proxy on ports 80 and 443. Keep application and database networks private, pin image versions, store Compose configuration in version control and inject secrets at runtime. Health checks should verify readiness, not merely that a process exists.
Build images in CI or on a dedicated builder when possible. Before an update, create a compatible database backup; deploy the new version; run smoke tests; and retain a tested rollback path. Database schema changes require particular care because reverting code may not revert data.
Backing up volumes and databases
Copying a live database directory is not a reliable logical backup. Use the database's dump or physical backup tool, verify exit codes and transfer the result off the VPS. Back up required volumes and the deployment configuration too. Encrypt sensitive archives and test restoration regularly.
Docker host security
Do not expose the Docker socket or database ports to the internet. Restrict SSH, apply host and image updates, use non-root containers where practical, and scan public images before production. An application compromise should not automatically grant host control.
Frequently asked questions
Is 1 GB RAM enough for Docker?
Sometimes for one very small stateless service, but it leaves little room for the OS and updates. A working web stack normally starts around 2 GB.
Does every container need a public IPv4?
No. One VPS address and a reverse proxy can route several domains to private container networks.
Should I install Kubernetes on one VPS?
Usually Docker Compose is simpler. Kubernetes is justified when multiple nodes, its deployment model and team expertise provide real value.
Can PostgreSQL run in Docker?
Yes, with a persistent volume, pinned version, resource limits and tested backups. The operational discipline matters more than whether the process is containerised.
Related: how to design reliable VPS backups.