What a node costs
Measured requirements for every role — cores per gigabit, CPU per gigabyte, RAM and disk — with a calculator that turns a workload into a VPS size.
The answer
Measured on Linux, stated per one core at 2 GHz — deliberately the pessimistic end, because a shared vCPU is time-sliced and you do not get a whole core anyway. Real VPS cores today run 2.4 GHz (a shared AMD EPYC plan) to 3.0 GHz (Ampere, or a dedicated core), and the high-frequency tiers go above that. A faster core does proportionally more: divide by 2, multiply by your own clock.
| What the node does | RAM: floor → buy | CPU | Disk |
|---|---|---|---|
| Relay for other peers | 256 MB → 512 MB | one 2 GHz core per 440 Mbit/s relayed | 2 GB |
| Tunnel or VPN exit | 256 MB → 512 MB 0.3 MB per simultaneous session on top |
one 2 GHz core per 680 Mbit/s through it | 2 GB |
| Storage, receiving copies | 512 MB → 1 GB | one 2 GHz core per 69 MB/s, or per 150 files/s — whichever runs out first | 1× the data, +2 GB per million files, +10 GB the cycle keeps free, +the largest few files while they are in flight |
| Storage, ingesting and serving | 512 MB → 1 GB | one 2 GHz core per 25 MB/s, or per 250 files/s | as above |
| On top of any of the above | |||
| Antivirus scanning | +1 GB | one 2 GHz core per 3.6 MB/s scanned | +112 MB of signatures |
| Document conversion | +256 MB per conversion at a time | 2.2 seconds of a 2 GHz core per document | +600 MB |
Version history (keep_history) |
— | — | 2× the data instead of 1× |
Four notes, and then the tables below are just these numbers with their working shown. A relay costs more than an exit because it handles every byte twice, once arriving and once leaving. Small files, not bytes, size a storage node — the same gigabyte costs six times more CPU as 25 000 small files than as one large one. RAM does not grow with the size of the vault: one file and twenty-five thousand both land in the same band. And the RAM column is two numbers because there are two questions. The floor is what the node needs to not die — it clears the ~250 MB the daemon briefly wants while starting, which is why a relay says 256 MB and not the 70 MB it settles at. The second is what to buy: the sustained figure with 1.5× headroom, rounded to a size somebody sells. The calculator answers the second one, and will say the first if you set headroom to 1.2×.
The same numbers, per gigabyte and per gigabit
If you are sizing something the table above does not name, these are the raw costs it was built from — one core of the processor they were measured on, which held 4.49 GHz across all eight of them under load.
| Work | Cost | Per 2 GHz core |
|---|---|---|
| Tunnel entry or exit | 0.65 core per Gbit/s | 680 Mbit/s |
| Relay hop | 1.02 core per Gbit/s | 440 Mbit/s |
| Receiving vault data | 6.4 CPU-s per GB | 69 MB/s |
| Ingesting and serving it | 18 CPU-s per GB | 25 MB/s |
| Each file received, on top | 2.9 ms | 150 files/s |
| Each file ingested, on top | 1.8 ms | 250 files/s |
| Antivirus | 122 CPU-s per GB | 3.6 MB/s |
| One document conversion | 1 CPU-s | 2.2 s |
| A node doing nothing | 0.7 % of a core | — |
| Each concurrent tunnel session | 0.3 MB of RAM | no CPU per byte |
Two warnings about that conversion, and they point opposite ways. Clock is not performance across architectures: these numbers came off a Skylake-generation core, and a current AMD Genoa core does appreciably more per cycle at the same clock while an Ampere core does somewhat less, so the same 2 GHz can be worth ±30 %. And a shared vCPU is not a core — it is a slice of one, so on a burstable plan the sustained figure is lower than any clock suggests. Size for the class of machine, not the decimal. Separately: a processor without SHA extensions (most Raspberry Pi class hardware) hashes far slower than clock predicts, and hashing is what caps a storage node there.
Size your node
Every coefficient below is a number from the tables above. Open the breakdown at the bottom of the result to see which one, and how it was applied.
Where these came from
Where these came from
Measured on 30 August 2026, MeshHold 0.7.411 on Linux, on an Intel i7-9700K — nominally 3.6 GHz, and measured holding 4.49 GHz across all eight cores under load, which is the figure everything here is normalised against. Each role ran on its own two cores in its own container, so a relay's CPU is the relay's and not its neighbour's, and the traffic generator sat outside all of them.
These are single runs on a container bridge. Two runs of the same binary moved the same gigabyte at 56 and 78 MB/s, so read the figures as ±30 % — the right size of machine, not a specification. A VPN exit is not measured separately: it shares the transport and crypto with the tunnel exit and adds a TUN device on top, so that row is a floor.
The harness and the raw results are in bench/reqs/ in the source tree.
If your numbers disagree with these, yours are the ones that size your machine.