How Much RAM Do I Need for a VPS? We Measured 34 Self-Hosted Apps

Most self-hosted setups need 2 GB of RAM on a VPS, including Nextcloud for a family, n8n, Mattermost and Paperless-ngx. One or two light apps, such as a password manager or a DNS filter, fit in 1 GB; Mastodon, Immich and Odoo want 4 GB, and a full mail server like mailcow needs 8 GB. That is our answer to "how much RAM do I need for a VPS?" after measuring 34 self-hosted apps, most of them under load as well as idle, 10 of them new for this article. One more number decides the small plans: a fresh Debian 13 server with 1 GB of RAM had about 700 MB available after boot, and about 640 MB once Docker was running. Specs and availability by city are on our VPS hosting plans page.

Key facts, checked on 18 October 2026:

• Debian 13 needs at least 512 MB of RAM and recommends 1 GB for a server without a desktop (Debian installation guide).
• docker stats subtracts only the inactive part of the file cache from a container's memory use (Docker docs). That is why a fresh Nextcloud app container showed 1.02 GiB in our lab, although 897 MB of it was file cache.
• The "available" column of free comes from the kernel's MemAvailable figure, which the kernel docs define as "an estimate of how much memory is available for starting new applications, without swapping" (kernel /proc docs).
• Vendor minimums differ widely: Pi-hole lists 512 MB (Pi-hole), Mattermost 2 GB for up to 1,000 users (Mattermost), Nextcloud recommends 512 MB per PHP process with 128 MB as the minimum (Nextcloud), and Jellyfin recommends 8 GB, though 4 GB "may be enough" on a Linux server without a desktop (Jellyfin).
• Steal time, the st column of vmstat, is "time stolen from a virtual machine" (vmstat(8)): CPU time your server wanted while the host ran other work.

How much RAM do I need for a VPS? What fits in 1, 2, 4 and 8 GB

RAM is the working memory your programs run in. When it is full, Linux either moves memory out to much slower disk (swap) or ends a process.

The table shows what fits on each of our plans. "Left for apps" is what Debian 13 and the Docker engine leave free. We measured it on the 1 GB size; the other rows subtract the same 310 MB plus a little for the kernel, so they are estimates.

All plans are KVM servers with NVMe storage, unmetered traffic and their own IPv4 and IPv6. You can move up a size later from the client area with a short reboot, so you don't need to buy for next year's load today. Compare them on the VPS plans page.

Is 1 GB of RAM enough for a VPS?

Yes for one or two light apps, no for a stack of six. To see where the memory goes, we booted a Debian 13 KVM virtual machine with 1 GiB of RAM and 1 vCPU, the size of VPS Nano, and read free -m at each step.

"Available" is the kernel's estimate of what new programs can still get without swapping. So a 1 GB VPS leaves your apps about 700 MB, or about 640 MB with Docker.

That is plenty for Vaultwarden, Pi-hole, wg-easy for WireGuard or Uptime Kuma, which used between 9 and 170 MB each in our tests, or for one WordPress site with a page cache. It is not enough for Nextcloud, Mastodon or Immich.

Six small apps together are too much. We ran Nginx Proxy Manager, Portainer, Vaultwarden, Uptime Kuma, Umami with PostgreSQL and Pi-hole as one stack; idle, their containers held 365 to 403 MB outside the file cache. Squeezed into a container with a 1 GiB limit and swap off, all seven containers kept running, and 1,000 analytics events plus a DNS test pushed memory use to 745 MB without a crash. But the kernel hit the limit and had to reclaim memory 863 times during that short test. A real 1 GB VPS also carries its own kernel and system services: with Docker idle, our 1 GB virtual machine showed 306 MB in use, against 60 MB in the container. That stack belongs on VPS Micro, with 2 GB and 2 shared vCPUs.

VPS size calculator: work out your RAM in a minute

Five steps give you a plan size:

1. Write down the busy figure of each app from the tables below, or measure your own as shown under "Signs your VPS needs more RAM".
2. Add about 310 MB for Debian 13 and the Docker engine.
3. Add 15 MB for each container. Nextcloud with MariaDB, Redis and cron counts as four.
4. Multiply by 1.25. The extra quarter covers file cache and spikes.
5. Pick the first plan with at least that much RAM.

Here is the sum for a family cloud that we later ran as one stack:

Does adding up work? Run together, with Nextcloud and Jellyfin busy at once, the five apps peaked at 1,297 MiB (1,360 MB), within 3% of the 1,337 their busy figures add up to. The table mixes MiB and MB, which differ by 5%; the quarter on top covers that.

The same stack also ran in a container limited to 2 GiB without an out-of-memory kill. A real 2 GB VPS gives a few hundred MB more to its own kernel and system services, so VPS Micro would hold it with nothing to spare. The calculation points to VPS Mini because the headroom matters, and because two vCPUs were the real bottleneck in that test, as shown further down. Mini has four.

Count disk the same way. Debian 13 took 708 MB of disk on our test machine, Docker's packages another 708 MB, and the six small apps from the 1 GB test pulled about 7 GB of images. The Disk column in the tables lists each app's share; compare the total with the plan's NVMe size.

VPS RAM requirements for 34 self-hosted apps

Idle means 2 to 3 minutes after setup with nothing happening. Busy is the peak during the load test named in the row. Rows marked "new" were measured for this article; the others link to the article where we tested the app. "Smallest comfortable plan" leaves room for the system, Docker and the busy figure.

Websites, automation and business apps

Files, photos and media

Chat, social, mail and calls

Developer and admin tools

Network, security and home

Games and AI

From this month's game tests, FiveM's txAdmin idled at about 225 MB (FiveM setup guide) and a Project Zomboid Build 42 server used 3.2 to 3.7 GiB with nobody online (Project Zomboid guide). AI agents have their own AI agent sizing guide. RAM for more AI apps is measured in our tests of Dify self-hosted, VoiceStudio voice cloning and the Odysseus AI workspace.

How we measured

New numbers come from our Amsterdam lab on 18 October 2026, an AMD EPYC 7742 test server shared with other test labs.

• Each app ran alone in one Debian 13 container with 2 vCPUs and a 3 GiB limit, on Docker 29.9.1, and we deleted it before installing the next.
• New figures are the sum of docker stats for the app's containers, in MiB (1 MiB is 1.05 MB). Figures from earlier articles are as published there, some for the whole server.
• Web load tests used one account or session with 5 to 20 parallel clients sending requests nonstop, so "clients" means parallel connections, not separate people.
• The operating system's share comes from a Debian 13 KVM virtual machine with 1 GiB and 1 vCPU, because a container can't show a virtual machine's kernel memory.
• Our Jellyfin films were generated 1080p clips, easier to encode than real films, so the transcoding speeds are best cases.

Why docker stats and free -m disagree

Linux keeps recently used files in spare RAM and hands that memory back when a program needs it. docker stats leaves out only the inactive part of that cache, so a container can look huge right after an install.

Our first Nextcloud showed 1.02 GiB, and the kernel's per-container statistics put 897 MB of it down to cache; in a second run Docker showed 156 MiB for the same app. Six small apps added up to 876 MiB in docker stats while their processes held about 400 MB.

The opposite also happens. Five idle nginx containers showed 2.5 MiB each, yet the server's available memory fell by 70 MB, about 14 MB per container, for runtime and kernel structures Docker doesn't count. So compare containers with docker stats, and judge the server by the "available" column of free -m, not the "free" one, which the cache keeps small on any healthy server.

Running several apps on one server: RAM adds up, CPU doesn't

Memory from several apps adds up almost exactly. CPU doesn't, because busy apps take turns on the same vCPUs. We tested a family cloud on 2 vCPUs with swap switched off, so nothing could hide in it: Nextcloud with MariaDB and Redis, Jellyfin, Vaultwarden, Uptime Kuma and Nginx Proxy Manager.

Memory was never the problem: inside 2 GiB the stack ran as fast as with 3 GiB. The two vCPUs were. With both apps busy, Nextcloud lost 48% of its throughput and the transcode 57% of its speed. That is the case for VPS Mini's 4 vCPUs, or a VDS with vCPUs dedicated to you.

Put a ceiling on one app

A memory limit stops one app from taking what the others need. In Docker Compose, add two lines to a service:

# in compose.yaml under one service; then, as root: docker compose up -d
    mem_limit: 256m
    cpus: 0.5

Set limits from the busy figure, not the idle one. When a capped container goes over, the kernel ends a process inside it: our test container stopped with exit code 137, and docker inspect showed OOMKilled=true. Docker's resource constraints page notes that container processes are, by default, more likely to be killed than the Docker daemon.

How many vCPUs do I need for a VPS?

A vCPU is a virtual processor core that the host gives your server. On our VPS plans the vCPUs are shared, so they take turns with other servers on the same host; on our VDS plans they are dedicated to you.

RAM is usually the first limit, but our tests show where CPU takes over. Two vCPUs in our lab were fully busy with any one of these: 10 Nextcloud WebDAV clients sending requests nonstop, 20 parallel BookStack clients, Mastodon serving 79 profile pages a second, 216 Mattermost posts a second, or a single 1080p Jellyfin transcode. Light services barely register: the RustDesk relay used well under 1% of one vCPU while carrying remote sessions, and Pi-hole answered 4,800 DNS queries a second with less than half of one.

So count vCPUs by the heavy jobs that run at the same time, such as transcodes, OCR, builds, imports or model inference, and give each one or two. Shared vCPUs suit bursts; when heavy work runs for hours every day, a VDS with dedicated vCPUs keeps its speed. Our VPS vs VDS vs dedicated server comparison explains the difference. Our servers have no GPUs, so plan video and AI work on CPU.

Signs your VPS needs more RAM, and how to check

Your own data, users and plugins decide the rest, so measure once your apps run. These are the warning signs, each with the check below that finds it:

• "Out of memory" or "oom-kill" lines in the kernel log (check 5).
• A container that stops with exit code 137, or restarts when you didn't restart it (check 5).
• The si and so columns of vmstat above 0 for long stretches, which means the server is swapping (check 4).
• The lowest "available" of a busy day below about a quarter of your RAM (check 3).

We ran each command below on our 1 GB test virtual machine or in the lab container; the Docker ones need Docker installed (see our Docker setup guide).

1. See what is left right now

# as any user
free -m

# output on our 1 GB test server after boot
               total        used        free      shared  buff/cache   available
Mem:             946         241         732          18         103         705
Swap:              0           0           0

A 1 GB server shows 946 MB because the kernel keeps some for itself. "available", 705 MB here, is what new programs can still get.

2. Find out what uses it

# as any user: a header line, then the 7 processes with the most memory (RSS, in KB)
ps -eo pid,rss,comm --sort=-rss | head -n 8

RSS is the memory a process holds in RAM right now. Our top entries were the lab's VM agent (21,472 KB), the DNS resolver systemd-resolve (14,280 KB) and systemd (13,836 KB). RSS counts shared libraries in every process, so don't add the column up. For per-service totals, ask systemd:

# as root: memory per systemd service, one reading
systemd-cgtop -m -n 1 -b

Ours reported 238.5M in total and 100.6M for system.slice, the system services. For Docker apps:

# as root, or a user in the docker group
docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.CPUPerc}}"

# output for a small test container with a 256 MB limit
NAME              MEM USAGE / LIMIT   CPU %
limitdemo-web-1   2.758MiB / 256MiB   0.00%

3. Record a busy day

Idle numbers flatter every app, so log memory once a minute for 24 hours in the background:

# as root: one free -m sample a minute for 24 hours
nohup free -m -s 60 -c 1440 > /root/free-24h.txt 2>&1 &

The next day, print the day's highest "used" and lowest "available", in MB:

# as root
awk '/^Mem:/ {print $3}' /root/free-24h.txt | sort -n | tail -1
awk '/^Mem:/ {print $7}' /root/free-24h.txt | sort -n | head -1

If the lowest "available" stays above about a quarter of your RAM, the plan is big enough.

4. Watch for swapping and stolen CPU

# as any user: 3 samples, 5 seconds apart
vmstat 5 3

# column names and the first two samples on our test server
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 3  0      0 752592   9344  96824    0    0   939   129  181    4  2 11 86  0  0  0
 0  0      0 752576   9344  96868    0    0     0     0   27   36  0  0 100  0  0  0

The first line averages everything since boot. si and so show memory moved in from and out to swap each second; values above 0 for long stretches mean RAM is short. r counts processes running on or waiting for a CPU; if it often exceeds your vCPU count, add vCPUs. For st, steal, our VPS benchmark commands show how to test under load. Debian 13 adds a gu column for guest time, which you can ignore.

5. Check for out-of-memory kills

When RAM runs out, the kernel's OOM (out-of-memory) killer ends one process, usually the one using the most memory. We forced one on the 1 GB machine with a job that needed 1,200 MB:

# as root
journalctl -k --no-pager | grep -i -E "out of memory|oom-kill"

# output after our test (shortened, date and host name cut)
kernel: Out of memory: Killed process 670 (tail) total-vm:791736kB, anon-rss:785792kB, ...

For a container, check whether it was killed or keeps restarting, using the name from docker ps:

# as root
docker inspect CONTAINER --format 'OOMKilled={{.State.OOMKilled}} RestartCount={{.RestartCount}}'

A match in the kernel log, or restarts you didn't cause, mean the server or that container needs more memory. Our guide on why a VPS is slow covers disk and network next.

Swap: a safety net, not more RAM

Swap is disk space the kernel uses when RAM is full. Without it, our 1,200 MB job on the 1 GB machine was killed, as shown above. Then we added a 1 GB swap file:

# as root: a 1 GB swap file that stays after a reboot
fallocate -l 1G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
swapon --show

The last command printed /swapfile file 1024M 0B -2. The same job then finished, but took 53 seconds, with the vCPU waiting for the disk 46 to 73% of the time. Swap covers short peaks such as installs and updates; if si and so are busy every day, buy RAM instead.

Which VPS plan and city fit your apps

RAM needs are the same in every city, so pick the one nearest your users. The latency figures come from our own ping.pe measurements of 6 October 2026, published on our location pages.

Availability by city is on the VPS plans page.

Frequently asked questions

Is 1 GB of RAM enough for a VPS?

Yes, for one or two light apps. In our lab on 18 October 2026, a fresh Debian 13 server with 1 GB had about 700 MB available, and about 640 MB with Docker running. That fits Vaultwarden, Pi-hole, WireGuard or Uptime Kuma, which used 9 to 170 MB each, but not Nextcloud, Mastodon or Immich, and not six small apps at once.

Is 2 GB of RAM enough for a VPS?

Yes, for most self-hosted setups. In our lab, plain Nextcloud 34 with MariaDB and Redis peaked at 524 MiB with 10 WebDAV clients sending requests nonstop, Mattermost at 488 MiB, and n8n at 1,345 MB for the whole server. A family cloud of Nextcloud, Jellyfin, Vaultwarden, Uptime Kuma and Nginx Proxy Manager ran in a container limited to 2 GiB without an out-of-memory kill, but with both apps busy, its 2 vCPUs cut each one's speed roughly in half.

How much RAM do I need for a VPS with Docker?

Add about 310 MB for Debian 13 and the Docker engine, 15 MB per container and each app's busy figure, then a quarter on top. Nextcloud, Vaultwarden, Uptime Kuma and Nginx Proxy Manager come to about 1.6 GB, so 2 GB fits. Adding Jellyfin with transcoding moves you to 4 GB.

How many vCPUs do I need for a VPS?

One vCPU is enough for light services such as a password manager, DNS filter or VPN. In our tests two vCPUs were fully used by 10 busy Nextcloud WebDAV clients or one 1080p Jellyfin transcode. For transcoding, OCR or builds choose 4 vCPUs, and dedicated vCPUs if that work runs for hours every day.

What happens when a VPS runs out of RAM?

The kernel's out-of-memory (OOM) killer ends a process, usually the one using the most memory. On our 1 GB Debian 13 test server, a job that needed 1,200 MB was killed this way. With a 1 GB swap file the same job finished, but took 53 seconds with the CPU waiting for the disk up to 73% of the time. Swap is a safety net for short peaks; daily swapping means you need more RAM.

How do I check how much RAM my VPS is using?

Run free -m and read "available", not "free". docker stats --no-stream lists each container but can count file cache: a fresh Nextcloud app container showed 1.02 GiB, and 897 MB of that was cache. To size a plan, log free -m once a minute through a busy day and check the lowest "available".

Size for your busiest hour, then grow

Add up the busy figures of your apps, keep a quarter free, and pick the first plan that covers it: Nano for one or two light services, Micro for a typical self-hosted stack, Mini for Mastodon, Immich or Nextcloud with Jellyfin, and a VDS when the work needs dedicated vCPUs or 8 GB and more. RS Computers runs these as KVM servers in Amsterdam, Dublin and Prishtina, with NVMe storage, unmetered traffic and their own IPv4 and IPv6, and you can upgrade later from the client area with a short reboot. Compare sizes on our VPS hosting plans page, or send us your app list on Telegram and we will suggest a size.

← All articles