The short table
| Workload | RAM to start with | What actually limits it |
|---|---|---|
| WireGuard VPN, a few devices | 1 GB | Monthly traffic |
| Discord or Telegram bot | 1 GB | CPU, if it touches audio |
| SearXNG | 1–2 GB | RAM, if you co-host anything |
| Static site or small API | 1 GB | Nothing, for a long time |
| k3s single node | 2 GB | RAM, immediately |
| 7B LLM, 4-bit quantised | 8 GB | RAM, then patience |
| Nextcloud for a household | 2–4 GB | Disk |
Every number above is a starting point that leaves headroom for the operating system, not a measured floor. You can go lower on all of them and regret it in different ways.
WireGuard: the answer is not RAM
WireGuard lives in the kernel and is remarkably cheap per packet. A single modern vCPU will saturate a gigabit link before the CPU becomes the constraint, and the daemon's memory use is measured in tens of megabytes regardless of how much traffic passes through it.
So the smallest plan is genuinely correct for a personal VPN — with one catch that catches people out. Every byte you pull through the tunnel counts twice: once inbound to the server, once outbound to you. Our entry plan includes 500 GB of traffic a month, which sounds like a lot until you route a household's video through it and discover you have 250 GB of usable throughput.
If the tunnel is for privacy on public networks and occasional browsing, 500 GB is plenty. If it is going to carry streaming for more than one person, start one tier up, where the included traffic is 2 TB. That is the plan comparison, and the WireGuard setup walkthrough is separate.
Discord and Telegram bots: watch the audio
A text bot written in Python or Node idles somewhere around 80–200 MB depending on library and cache. That fits the smallest plan several times over, and most bot hosting questions end there.
The exception is audio. The moment a Discord bot starts playing music it is running ffmpeg, transcoding a stream per voice channel, and that is CPU work rather than memory work. One or two concurrent streams are fine on a single core; a bot serving several busy servers at once is not, and the symptom is stuttering audio rather than an out-of-memory kill.
SearXNG: fine alone, tight with company
A SearXNG instance with its Redis cache settles at roughly 300–500 MB in normal use. On paper that fits 1 GB.
In practice, people do not run SearXNG on its own. They run it next to a reverse proxy, a monitoring agent, sometimes a Pi-hole, and the sum is what matters. On 1 GB the instance works and the box has no margin for a burst; at 2 GB it stops being something you think about. If SearXNG is the only thing on the machine, the smaller plan is real.
k3s: 2 GB is the honest minimum
k3s advertises a very small footprint, and the binary genuinely is small. What is not small is everything a usable cluster carries: the control plane, CoreDNS, the ingress controller, the metrics server, and whatever you deployed.
A server node will start on 1 GB and spend its life close to the edge, where the first thing to go is usually containerd during an image pull. 2 GB is the point at which a single-node k3s stops being an experiment. If you plan to actually deploy things onto it rather than admire it, 4 GB is a better place to begin.
Local LLMs: RAM is the whole story
This is the one workload where memory is exactly the constraint, and the arithmetic is simple. A 4-bit quantised model needs roughly half its parameter count in gigabytes, plus room for context and the operating system:
- 7B at 4-bit — about 4–5 GB of weights. Run it on 8 GB.
- 13B at 4-bit — about 8 GB of weights. 16 GB.
- 7B at fp16 — about 14 GB of weights. 16 GB, with nothing else on the box.
On CPU it will work and it will be slow — several tokens per second, fine for batch jobs and frustrating for chat. If you want it to feel responsive, that is what GPU instances are for, and they are billed by the hour so an afternoon of experimenting costs very little.
The thing that actually breaks first
Across all of these, the resource that runs out before RAM on a cheap server is one of two things.
Included traffic, which is why the entry plan carries 500 GB rather than the terabyte people assume. Go over it and you are paying for overage on a $10 server.
Disk, quietly, through logs and Docker. An unattended docker system prune habit and a logrotate config are worth more than an extra gigabyte of memory on most small servers.
df -h on a server you have owned for a month. It is the most common unpleasant surprise on a small VPS, and the cheapest one to prevent.Picking one here
Plans run from 1 GB to 16 GB, all billed by the hour from a prepaid crypto balance, across four clouds, in every city we offer. Because billing is hourly and destroying a server stops it, the sensible move with an unfamiliar workload is not to calculate — it is to deploy the cheap tier, watch free -h and your traffic counter for a day, and resize by redeploying if you were wrong. That costs a few cents.