Run the verification yourself
Dedicated resources for blockchain nodes and authorised validator operations.
Content revised · English
- Architecture to evaluate
- Full node / archive / validator / RPC
- Prepared starting points
- 6 plans
- Responsibilities
- Application, rights and recovery
A fit shortlist, not installed software or live inventory.
Keep these in view.
- Full node / archive / validator / RPC.
- Separate signing from serving.
- Plan updates and recovery without earnings promises.
Full node / archive / validator / RPC
A verifying full node, an archive database, a validator and a public RPC endpoint have different storage and security requirements. Chain size changes, so check the maintained client’s current requirements and growth before buying disk. For Ethereum, distinguish execution and consensus clients rather than treating one binary as the whole system.
Separate signing from serving
Do not put a seed phrase into a launch script or support ticket. A public RPC service needs authentication, request limits and monitoring; a signing key deserves a narrower access boundary. A machine that serves queries need not hold every credential associated with the project.
Plan updates and recovery without earnings promises
Test database recovery, upgrades and a replacement route. Validators have chain-specific rules and economic risks; hosting uptime is only one component. No staking yield, validator continuity or routing profit is claimed by the catalogue.
Match the chain
Different networks have different storage growth, memory and connectivity needs. Check the chain's current hardware and pruning requirements rather than selecting a server only by CPU count.
Protect the keys
A node can often operate without spendable wallet keys. Keep validator, signing and wallet credentials separated where the protocol allows, and use protected backups with a tested recovery procedure.
Plan for continuous operation
Track peer connectivity, sync progress, disk headroom and software updates. Validator uptime or staking outcomes cannot be guaranteed by the hosting plan; understand the protocol's own rules and risks.
The client pair is an operating choice
An Ethereum node combines execution and consensus clients. Execution examples include Geth, Erigon and Reth; consensus examples include Lighthouse and Prysm. Validator software adds a signing role. Choose from current client documentation, synchronisation mode and database growth rather than an old fixed chain-size figure.
- Allow disk headroom for state growth, maintenance and recovery.
- No pre-staged client pair, validator signing service, Slasher or MEV-Boost integration is supplied by this configuration and account workflows.
Capacity to consider.
Match these starting points to the representative application. Software installation and live inventory are not connected; the exact specification and period total come from the catalogue.
Umbra 2
Give web applications, containers or a private tunnel two AMD EPYC virtual CPUs, 4 GB of ECC memory and 60 GB of NVMe storage. Root access on KVM, a 1 Gbps port and 3 TB of monthly transfer provide more room than the entry configuration without moving to dedicated hardware.
- Compute
- 2 vCPU (AMD EPYC)
- Memory
- 4 GB DDR4 ECC
- Storage
- 60 GB NVMe SSD
- Transfer
- 3 TB / month
billed monthly
Umbra 4
Balance four AMD EPYC virtual CPUs and 8 GB of ECC memory with 120 GB of NVMe storage for several services or a growing application. This KVM configuration includes a weekly snapshot, 6 TB of monthly transfer on a 1 Gbps port and a 20 Gbps network mitigation tier.
- Compute
- 4 vCPU (AMD EPYC)
- Memory
- 8 GB DDR4 ECC
- Storage
- 120 GB NVMe SSD
- Transfer
- 6 TB / month
billed monthly
Umbra 8
Allocate eight AMD EPYC virtual CPUs, 16 GB of ECC memory and 240 GB of NVMe storage to busier applications, workers and databases. Daily snapshots complement root access on KVM, with 10 TB of monthly transfer on a 1 Gbps port and a 40 Gbps network mitigation tier.
- Compute
- 8 vCPU (AMD EPYC)
- Memory
- 16 GB DDR4 ECC
- Storage
- 240 GB NVMe SSD
- Transfer
- 10 TB / month
billed monthly
Vault 2
Store backups, archives or authorised media on a 2 TB HDD configuration with two virtual CPUs and 4 GB of memory. The 10 TB monthly transfer allowance and 1 Gbps port suit scheduled file movement, with rTorrent and Jellyfin as the listed software stack choices.
- Compute
- 2 vCPU
- Memory
- 4 GB DDR4
- Storage
- 2 TB HDD
- Transfer
- 10 TB / month
billed monthly
Eclipse Ryzen
Use a dedicated Ryzen 9 5950X with 16 physical cores, 32 threads and 64 GB of ECC memory for compute-intensive services. Two 1 TB NVMe drives in RAID-1 provide mirrored storage, with IPMI access, a 1 Gbps port and 50 TB of monthly transfer.
- Compute
- AMD Ryzen 9 5950X (16c / 32t @ 3.4 GHz)
- Memory
- 64 GB DDR4 ECC
- Storage
- 2× 1 TB NVMe (RAID-1)
- Transfer
- 50 TB / month
billed monthly
Eclipse EPYC
Consolidate larger workloads on a physical EPYC 7443P server with 24 cores, 48 threads and 128 GB of ECC memory. Two 2 TB NVMe drives in RAID-1 pair with a 10 Gbps uplink, 100 TB of monthly transfer and a 200 Gbps network mitigation tier.
- Compute
- AMD EPYC 7443P (24c / 48t @ 2.85 GHz)
- Memory
- 128 GB DDR4 ECC
- Storage
- 2× 2 TB NVMe (RAID-1)
- Transfer
- 100 TB / month
billed monthly
Before this workload goes live.
- Check the exact plan’s CPU, memory, disk, transfer and port.
- Choose a listed region and verify the workload’s permitted use.
- Test the representative application and an independent restore.
Questions, answered.
Which Ethereum component needs the disk?
Execution and consensus clients have different roles; archive mode adds substantial storage needs. Use current client requirements and growth measurements rather than a fixed historical chain-size estimate.
Does a Lightning node imply Lightning checkout support?
No. A customer application and the hosting merchant’s payment methods are separate. Lightning is outside the prepared Ombra checkout.
Is a hardware wallet safely usable through any SSH session?
Remote administration is not a universal signing design. Evaluate the wallet’s supported workflow, key exposure and a separate signing boundary; no hardware-wallet integration is supplied.
Can a validator be guaranteed uninterrupted operation?
A validator needs chain-specific monitoring, recovery and update procedures. No uptime or earnings outcome is established by an unconnected catalogue.
What is kept in my account workspace?
Your configuration, selected plan, image, location and billing term are kept with the order and payment request references. Quotes, payment-state reads and support conversations remain linked to your account. Read fulfilment details separately from payment status.