How much VPS do you actually need?

For most new projects, 2 vCPU and 4 GB of RAM is a sensible starting point. In the Virtuaal.com range that is the C-S plan, which also has 80 GB of disk. It is usually enough for one moderate WordPress installation, n8n or a few smaller containers.

The more useful question is not the total user count, but what the server does at the same time. A cached website can serve a large audience with little memory, while one heavy automation run or modded game server can fill the same machine quickly.

These sizes are starting points, not promises for every software combination. WordPress and n8n are often memory-bound, Docker depends on the services inside its containers, an API agent on the external API, a local model on model and context size, a game server on single-core speed, and several projects on shared headroom.

A simple WordPress site, blog, portfolio or brochure site often fits within 1–2 vCPU and 2–4 GB of RAM. Caching, plugin count, PHP processes and database size matter more than the number of pages. A plugin-heavy shop should usually start closer to 4 GB.

Adding cPanel or Plesk creates a control-panel RAM trap: the panel can consume 1–2 GB before the first website is served. That makes 2 vCPU, 4 GB of RAM and 80 GB of disk the practical starting point for WordPress with a panel, rather than a 2 GB plan.

RAM is usually the bottleneck for n8n. Every concurrent execution keeps its payload in memory, and a workflow carrying a large JSON document can consume 150–300 MB. When several webhooks, requests or file operations overlap, memory use rises much faster than the workflow count initially suggests.

2 GB can suit development and a few light sequential workflows, but 4 GB is a more practical start. Move n8n from SQLite to PostgreSQL before production: a separate database is better suited to concurrent executions, recovery and growing execution history.

Docker itself does not demand a large server; the container count and the software inside them determine the size. Nextcloud, Gitea and Vaultwarden may each be modest, but together with a database, reverse proxy, workers and monitoring they form one shared memory budget.

Add the documented CPU, RAM and disk requirements of every service, then add at least 25% headroom. A few small services can start at 2–4 vCPU, 4–8 GB of RAM and 80–160 GB of disk; the final choice depends on container data and concurrent work.

An AI agent calling an external API is an ordinary Node.js or Python process from the server’s perspective. 2 vCPU and 2–4 GB of RAM is normally enough because the heavier computation happens at the API provider. The external API and the number of concurrent agents are more likely to constrain this setup than local compute.

A local model needs RAM for both model weights and context. Our VPS plans are CPU-based and have no GPU, so the realistic choice is a smaller quantised model with 4+ vCPU and 8+ GB of RAM. The related “AI on your own server” guide covers model, Ollama and RAG stack choices in more detail.

For a game server, single-core speed often matters more than total core count. Java-based servers in particular do much of their main work on one thread, so adding many vCPUs does not automatically make a slow main thread faster.

Mod packs, world size, active players and supporting services can multiply the memory requirement. A sensible starting point is 4+ vCPU, 8+ GB of RAM and 160 GB of disk, but follow the pack’s documented requirements and measure the process’s actual memory use for a large modded server.

When websites, databases, CI jobs and internal services share one VPS, headroom is worth more than on a single-purpose server. One project’s peak should not force the others into swap or cause their processes to be killed.

A useful starting point is 4–6 vCPU, 8–16 GB of RAM and 160–250 GB of disk. Give services memory limits, monitor them separately and leave enough free capacity that maintenance, a backup job or temporary work cannot consume the whole server.

Most OS images arrive without swap. A 2 GB swap file added with root access does not replace RAM, but it can give a process time to finish during a short memory peak. If the server is swapping continuously, fix the memory shortage instead of endlessly enlarging the swap file.

Plan disk growth six months ahead: logs, the database and local backups grow even when the application code does not. The difference between NVMe and SATA appears in real response times under database-heavy work; our storage is NVMe SSD RAID in the CITIC Telecom data centre in Tallinn, on AS205930.

On our hypervisor, vCPU time is shared across AMD EPYC cores, while each VPS has separate RAM. A sustained load is not the same as a short burst: observe CPU use over time and choose headroom for the measured need.

Do not buy the largest plan simply “just in case.” Start with the documented requirements of today’s workload, add sensible headroom around the real bottleneck, then observe actual RAM, CPU and disk use after launch.

When usage regularly approaches a limit, choose a larger plan in VirtFusion. This keeps the initial size tied to evidence rather than a guess. Virtuaal.com plans range from C-XS (1 vCPU, 2 GB RAM, 50 GB disk) to C-XXL (16 vCPU, 32 GB RAM, 480 GB disk); pricing starts at EUR 7.64 per month with annual billing, excluding VAT.