How much RAM do I need for a VPS? The rule, workload by workload

The rule: add up what stays in memory

A server does not use memory "in general": every running program holds on to its share for as long as it runs. So the calculation starts from the list of processes that will always be there, then adds the peak and some headroom:

RAM to plan for = (OS + always-on services + peak of occasional jobs) × 1.25

• The operating system: a minimal Linux install (Debian, Ubuntu) uses around 150 to 300 MB once booted, SSH and logging included.
• Always-on services: web server, application processes, database, cache, job queue. What they use depends on the technology, detailed in the next section.
• The peak: what comes on top from time to time, such as building the application, a backup, an import or a heavy scheduled job. A server sized on its average falls over at exactly these moments.
• Headroom: 25% above the total, for growing data and traffic. It does not sit idle: Linux uses free memory as file cache, which makes the database faster.

What each component uses

The figures below hold for a typical application, measured in production. They are a starting point; measuring your own application, as described further down, always has the final word.

One peak catches JavaScript projects again and again: the build. npm run build on a Next.js, Nuxt or Angular project commonly needs 1 to 2 GB on its own for a few minutes, on top of everything already running. Building on the server means sizing for that peak; building on your machine or in CI and shipping only the output avoids it.

The same reasoning applies to Docker containers: each container is a set of ordinary processes, and the Docker daemon adds its own share. docker stats shows what each one takes.

Typical profiles

These profiles add up the components above, peak and headroom included. They assume an application of ordinary size and launch-day traffic; a large database or sustained traffic pushes the figure up.

An application that calls an AI model through an API (OpenAI, Anthropic, Mistral) is sized like any web application: the model runs at its provider and your server waits for the answer. Running the model on the server itself is what changes the scale.

Measuring a live server

On a server in production, measurement replaces estimates. Three commands tell you where you stand:

free -h
ps aux --sort=-rss | head -n 15
vmstat 5 5

• free -h: read the available column, the memory actually available to start new programs. The free column is almost always low, and that is normal: Linux fills unused memory with file cache (buff/cache) and hands it back as soon as a program needs it.
• ps aux --sort=-rss: processes ranked by the memory they hold (the RSS column, in kilobytes). This is where you see what each PHP or Node.js worker weighs.
• vmstat 5 5: five readings five seconds apart. Non-zero values in the si and so columns, reading after reading, mean the server is swapping: it is short of memory.

Measure at the busiest time of day, and during occasional jobs: builds, backups, imports. The peak is what counts.

When memory runs out

A server that runs out of memory does not degrade gradually. When there is nothing left to reclaim, the Linux kernel calls the OOM killer (out of memory): it picks a process, usually the one holding the most memory, and kills it outright. On an application server, that is often the database.

The symptoms: intermittent 502 or 503 errors, a service that restarts for no visible reason, a build that dies with Killed. The logs confirm it:

journalctl -k | grep -i "out of memory"
systemctl status your-service

In the output of systemctl status, Failed with result 'oom-kill' marks a service stopped for lack of memory.

Swap, when the server has it, delays that moment by moving the least used memory to disk. It is a safety net, not capacity: a server that leans on swap all the time responds several times slower, even on an NVMe SSD.

The fixes, from quickest to most lasting: fewer application processes (pm.max_children, Gunicorn workers), builds moved off the server, a memory cap on the database, then a larger size.

Choosing a size, and planning ahead

1. List what will run: web server, application and its number of processes, database, cache, scheduled jobs.
2. Add them up with the component table, add the heaviest peak (often the build), then 25% headroom.
3. Pick the size that covers that total. Between two neighbouring sizes, the smaller one is fine as long as moving up does not mean reinstalling.
4. Measure after launch, at the daily peak, then again at each growth step of the application.

Memory is not the only resource: CPU matters for anything that computes (builds, image processing, running an AI model) and disk for the database and files. For a web application, though, it is almost always memory that sets the size.