How to size a VPS for a Docker app: measure before you choose

An app built with AI might turn into a static website, an API, several containers, or a database with background jobs. Its framework name and the number of services in Docker Compose do not tell you which server to buy. Test a workload that resembles production, then use the result to choose RAM, CPU and disk. There is no universal size for “a Docker app”.

If you still need to prepare the stack and reverse proxy, start with the Docker Compose deployment guide for a VPS. This guide focuses on sizing the machine.

If your project is a conventional Django app using Gunicorn and Nginx, follow the Django VPS deployment guide for its Python environment, systemd service and production checks. For a Flask application, see the Flask guide for Gunicorn and Nginx; for an ASGI API, see the FastAPI and Uvicorn guide.

Inventory what will run

List every persistent service: app, workers, proxy, database, queue, cache and monitoring. Include the operating system, Docker, maintenance jobs and one-off tasks such as a build or database migration. A Next.js build, for example, can peak differently from the server handling requests; measure both if they will run on the same VPS.

Separate a static output from a service that needs a running process. If your output is static, compare Hostbrid Projects before taking on VPS administration. A VPS gives you root and system control; it also makes you responsible for Docker, updates, firewall, backups and recovery.

A Discord bot that must stay connected also needs a persistent process; see this guide to run a Discord bot 24/7 on a VPS.

Measure a representative test

Start a test deployment and exercise the important work: expected traffic, database queries, file uploads, workers, scheduled jobs and an update. An idle reading does not represent a peak. Record usage at startup, during the load and after jobs finish; check response times and errors too.

docker compose ps
docker stats --no-stream
free -h
df -h
docker system df -v

docker stats --no-stream takes one sample; docker stats streams updates while you run the test. On Linux, Docker’s CLI memory figure subtracts some cache, so it is not a replacement for observing the host. Compare the system’s available memory with the whole stack. docker system df -v helps inspect Docker objects; df -h reports filesystem space. Docker explains the fields in its stats reference and its resource-constraints guide.

Choose RAM, CPU and disk separately

For RAM, watch concurrent peaks across the machine, not only each container’s average. Leave capacity for the host and changing load. Docker does not automatically limit each container’s memory: if you set Compose limits, keep their combined ceiling below total VPS RAM so the host has room, and do not set a service limit below its actual needs. A limit that is too low can end a process under memory pressure; swap does not turn disk into fast RAM.

For CPU, look at sustained use alongside latency and queued work. A build may need CPU for a few minutes even when the idle app does not. For disk, account for the OS, images that coexist during updates, persistent data, uploads, logs and temporary space. A backup stored on the same VPS is not protection against losing that server.

Do not map “three containers” to a plan size. The database may dominate RAM; automation executions may fill disk; and an app calling an external AI API has different needs from one running a model locally. Choose after measuring and repeat the test when traffic, data or architecture changes.

Compare your results with the catalogue

Once you have a useful test, compare CPU, RAM, storage and traffic with the available VPS sizes. Confirm the final price, IPv4, availability and current terms on the order page. If you expect to need a larger size later, ask support which changes your service allows and under what terms before relying on them in production.

If you are comparing provider prices and extras, also see the guide to calculating the total cost of a low-cost VPS.

If your project is an always-on agent such as OpenClaw, also check its VPS requirements and private access model; hosting it does not mean exposing the Gateway to the internet.

If you cannot reproduce the workload or tell a temporary build from a persistent service, note the framework, containers, database and measured usage, then ask us before choosing. Do not send keys, passwords or real user data.