A cache server is the easiest machine to size and the easiest one to size wrong. Easy, because there is essentially one number that matters: how much data you intend to hold in memory. Wrong, because the default configuration has no memory limit at all, so the first time your key space grows faster than you expected, the kernel kills the process — or worse, kills the database sitting next to it.
This is how to size a VPS for Redis or Valkey as a cache, queue or session store, what to set before it goes anywhere near production, and what each shape costs in our five European locations.
One number, then three adjustments
Start with the size of the data you want resident: the number of keys times their average size, plus the per-key overhead (tens of bytes each — significant when you have millions of small keys). Then adjust:
- Add 25–30% for memory fragmentation and copy-on-write. The allocator does not pack perfectly, and if you enable snapshots the fork doubles pages that are being written during the save.
- Add the client buffers. Each connection has an output buffer; a slow consumer on a pub/sub channel or a large pipeline can hold a lot. With hundreds of clients this is not a rounding error.
- Leave the OS 500 MB–1 GB. Plus whatever else runs on the machine.
So a cache holding 1.2 GB of actual data wants roughly 2 GB for the process and around 3 GB on the machine. That is the 4 GB shape, not the 2 GB one.
Shapes for cache work
| Resident data | Shape | RAM / vCPU / disk | Bucharest | Warsaw · Amsterdam | Frankfurt · Vienna |
|---|---|---|---|---|---|
| Up to ~700 MB — sessions, small fragment cache | VPS I KVM | 2 GB / 1 / 20 GB | €4.00 | €5.00 | €5.50 |
| Up to ~2 GB — typical application cache + queue | VPS II KVM | 4 GB / 2 / 40 GB | €6.00 | €8.00 | €9.00 |
| Up to ~5 GB — hot data set for a busy app | VPS III KVM | 8 GB / 2 / 60 GB | €10.00 | €14.00 | €16.00 |
| Up to ~11 GB — large cache, several databases | VPS IV KVM | 16 GB / 4 / 80 GB | €16.00 | €24.00 | €26.00 |
| Up to ~18 GB — cache as a primary data store | VPS V KVM | 24 GB / 6 / 100 GB | €30.00 | €42.00 | €44.00 |
| Up to ~24 GB | VPS VI KVM | 32 GB / 8 / 120 GB | €58.00 | €74.00 | €78.00 |
Two notes on the hardware side. Redis and Valkey are single-threaded for command execution, so extra vCPU buys you background saves, I/O threads and room for other processes — not faster GETs. And we put no IOPS ceiling and no CPU percentage cap on VPS plans, which matters when a background save is writing while the cache keeps serving.
Set these four things before production
maxmemory — always
Give the process a hard ceiling with room left for the OS: on a 4 GB machine running only the cache, 2.5–3 GB is sensible. Without it the process will grow until something dies, and the thing that dies is chosen by the kernel.
maxmemory-policy — match the job
- Pure cache:
allkeys-lruorallkeys-lfu. Evicting the least useful key is exactly what you want. - Sessions or a queue you cannot lose:
noeviction, and then you must alarm on memory, because writes start failing instead of silently dropping data. Choosingallkeys-lrufor a job queue is how jobs quietly disappear. - Mixed: split them into separate instances rather than gambling on one policy that fits both.
Persistence — decide deliberately
A pure cache needs none: turn snapshots and the append-only log off and your restart is a cold cache, which is fine. A session store or queue wants the append-only file with everysec fsync, which costs disk and a little latency. Do not enable both a frequent snapshot schedule and AOF on a small machine without checking the disk; the fork for a save can briefly need a lot more memory on a write-heavy instance.
Bind to the private path, never the world
An exposed cache with no password is one of the most reliably exploited things on the internet. Bind to localhost if the app is on the same machine. If the cache is on its own VPS, restrict it with the firewall to the application server's address and set a strong password — and be aware that between two of our machines the traffic crosses the network, so use a private interface or a WireGuard tunnel rather than the public port. Our WireGuard write-up covers building that tunnel.
Same machine or its own?
Same machine as the app is right for most small deployments: no network hop, no extra bill, and the cache is trivially reachable over a Unix socket. Budget the memory for both — our 4 GB budget post has the arithmetic.
Its own machine earns its keep when several application servers share the cache, when you need to size cache memory independently of the app, or when you want to restart the app without losing the cache. At €4–6 a month for a small dedicated cache box in Bucharest, that separation is cheap.
What you should not do is put the cache in a different country from the application. Cache lookups are supposed to be sub-millisecond; a cross-border round trip on every lookup makes the cache slower than the database it was protecting. Keep both in the same location — all five of ours carry every shape, and the price list shows the difference between them.
Measure the real thing for pennies
The estimate above is a starting point; your key space is the truth. Every shape is available on hourly billing:
- Order the candidate shape — a VPS II is €0.0083 an hour in Bucharest, a VPS III €0.0139.
- Load a realistic key set, or mirror a portion of production traffic at it.
- Read
INFO memory:used_memory,used_memory_rssand the fragmentation ratio. A ratio much above 1.5 means you are paying for fragmentation and should recheck your value sizes. - Check the eviction and hit statistics. A cache evicting constantly at a hit rate below 80% is undersized; a cache at 99% with no evictions may be oversized.
- Destroy the machine — three hours of a VPS III is about €0.04.
Hourly services need €5 of account credit to create and bill from that balance each hour. A stopped machine keeps billing; destroy it to stop the meter.
How Noded Can Help
Work out your resident data, add a third for overhead, and pick the shape above it from the hourly VPS page — in the same location as the application it serves. If the cache is fronting a database, our PostgreSQL sizing guide covers the other half, and the two together usually cost less than people expect. Want a check on your maxmemory and eviction choice before it goes live? Open a ticket — that decision is easier to get right before the queue starts losing jobs.
FAQ
How much RAM does Redis need?
Your resident data plus about 25–30% for fragmentation and copy-on-write, plus client buffers, plus 500 MB–1 GB for the OS. A 1.2 GB data set is a 4 GB machine, not a 2 GB one.
Does more vCPU make Redis or Valkey faster?
Not for command throughput — execution is single-threaded. Extra cores help background saves, I/O threads and anything else sharing the machine.
Should I use eviction or no-eviction?
LRU or LFU eviction for a pure cache. noeviction for sessions and queues, with an alert on memory — otherwise you are silently deleting data you needed.
Can the cache live on the same VPS as my app?
Yes, and for small deployments it should: no network hop and no second bill. Give it a separate machine when several app servers share it or when you want to size it independently.
Can I put the cache in a cheaper location than my app?
You can, and you should not. Every lookup would pay the round trip between countries, which defeats the purpose of a cache. Keep them in the same location and take the cheaper location for both if price matters.