Nodes and validators.
Peers pull, nothing counts it.
A node is an egress machine with an appetite for IOPS: peers sync from you around the clock, and the state only grows. Neither of those becomes a line on the invoice here.
- port
- 1, 10, 25, 40, 100 Gbps
- egress
- unmetered
- disks
- nvme available
- locations
- AMS · MEP · IAD · PHX
Constant traffic, a database that only grows.
A node keeps a full or partial copy of a blockchain and answers other nodes that ask for it. It downloads new blocks, checks them and serves blocks and state to its peers. A validator does the same and also takes part in producing blocks.
Two things dominate the load: steady traffic to and from peers, and a state database that does many small reads and writes and only gets bigger. So the disks come first when you size the machine, and the port second.
How to choose.
- 01 ─ footprint
Look up the client's footprint. Its own documentation lists current disk size and growth for your chain and node type.
- 02 ─ growth
Add room for the months you plan to run it. The calculator further down shows how long a given array lasts.
- 03 ─ disks
Choose NVMe. Sync is random reads and writes, and sync time is mostly disk time.
- 04 ─ scope
We give you the machine, not the node: no snapshots, no RPC endpoint, no watching your chain.
- 01 ─
Peers never stop pulling
on a meter or a shared hostSync traffic runs around the clock and counts against any allowance.
hereIngress and egress unmetered.
- 02 ─
State only grows
on a meter or a shared hostAn archive node keeps every historical state, and the footprint climbs with each client release.
hereThe NVMe array is sized to your chain and node type, with room to grow.
- 03 ─
Throughput is the wrong number
on a meter or a shared hostSync is small random reads and writes; a Gbps figure does not predict it.
hereNVMe chosen for IOPS, because sync time is mostly the disks.
What to look for in the machine.
Small random reads and writes are the whole load.
Check the footprint against the client's own documentation; it changes with releases.
A port moves what a port moves; the counter is gone, the disks set the pace.
What the client caches in RAM it does not ask the disks for.
The servers that fit this today are marked under the processor on the price list. The shelf changes; what to look for in the machine does not.
How long the array lasts.
Set the state today and how fast it grows. Each row is an NVMe array from the build options, and the months until it is full.
pick an array above to carry it over
Questions to settle before ordering.
- 01 ─
Do you accept cryptocurrency?
No. We take card (Visa or Mastercard), bank transfer or PayPal, from an account in your own name (Terms, section 5).
- 02 ─
Can I add disks when the state outgrows the array?
By agreement, and it depends on the server: sometimes disks go into the same machine, sometimes the answer is a new machine with a bigger array. Timing is agreed case by case.
The rest, for every machine: all questions and the terms.
- We do not run the node. No snapshots, no fast sync, no RPC endpoint, no watching your chain for you.[no]
- One page, not one per chain: the machine is the same, only the array size changes with the chain.[limit]
- Lawful use only. The acceptable use section applies here as it does everywhere else.[limit]
Tell us what it serves.
The workload, the working set, where the users are. We come back with a machine sized to it, a price and a date.
alsounmetered servers · CDN origins · streaming servers · game servers · storage servers · download servers · database & compute · virtualisation hosts