Cutter 16
- vCPU
- 6 × dedicated
- RAM
- 16 GB
- Storage
- 320 GB NVMe SSD
- Transfer
- 15 TB
- IPv4 / IPv6
- 1 / /64 routed
Solution
Blockchain nodes are storage and IO monsters. A Bitcoin full node needs about 700 GB and grows; an Ethereum archive node needs several terabytes. Validators additionally need uptime, because downtime is slashable. Use NVMe without exception — HDD cannot keep up with chain sync — and pick a jurisdiction that will not compel you to identify yourself as an operator.
| Resource | What you actually need |
|---|---|
| CPU | 4–8 dedicated cores |
| RAM | 16 GB for most full nodes, 32 GB for Ethereum with a full mempool |
| Disk | NVMe only. 1 TB for Bitcoin with headroom, 2 TB+ for Ethereum |
| Uptime | 99.99% SLA — validator downtime is a direct financial penalty |
Location is usually the decision that matters most for this workload — either because latency dominates, or because jurisdiction does.
Check the chain's current size, then double it — chains only grow.
Never run a node on HDD; initial sync will not finish in a reasonable time.
And monitor peer count, not just process liveness.
RPC should never face the internet without authentication and an IP allowlist.
A failed upgrade on a validator is expensive; a snapshot makes it a five-minute rollback.
A full node needs 4 cores, 16 GB of RAM and at least 2 TB of NVMe with room to grow. An archive node needs several times that storage. HDD is not viable for either.
Yes, and many do. Uptime and disk latency are what matter; use a location with a published SLA and never share the withdrawal key with the box.
Proof-of-work mining is not permitted on shared infrastructure — it degrades every neighbour on the host. Validators, full nodes and RPC endpoints are all welcome.