Ethereum Node: What It Actually Takes to Run One
Sourced hardware requirements, sync mechanics and maintenance load for a self-hosted Ethereum node — and the REST API that replaces it for sending transactions and watching deposits.
An Ethereum node is the software that keeps a full copy of the chain's state and lets you query it or broadcast transactions directly, without going through someone else's server. Searching for "ethereum node" usually means one of two things: you want to understand what running one involves before you commit server budget to it, or you assumed a node was the only way to read and send Ethereum data and want to check that assumption. This page answers both. The numbers below come from Ethereum's own node-running documentation, checked in August 2026, not from a sales page.
What is an Ethereum node?
An Ethereum node is a running instance of client software that stores the chain, validates new blocks and relays transactions to the rest of the peer-to-peer network. Since the Merge, a full setup pairs two programs: an execution client (Geth, Nethermind, Besu, Erigon or Reth) that handles state and transactions, and a consensus client (Lighthouse, Prysm, Teku, Nimbus or Lodestar) that handles proof-of-stake attestations. Both run continuously and talk to each other over a local RPC connection. Ethereum nodes come in a few storage profiles: full nodes keep recent state and prune old data, archive nodes keep every historical state ever written, and light nodes fetch only headers — a mode Ethereum's own docs note has too few serving peers on mainnet to be practical.
Ethereum node requirements
Ethereum.org's node-running guide (checked August 2026) lists the following as the baseline for a full node running one execution and one consensus client:
| Component | Minimum | Recommended |
|---|---|---|
| CPU | 2+ cores | Fast CPU, 4+ cores |
| RAM | 8 GB | 16 GB+ |
| Storage | 2 TB SSD | Fast SSD, 2+ TB |
| Bandwidth | 10+ Mbit/s | 25+ Mbit/s, unmetered |
Two details from the same source are easy to miss when sizing a server. First, storage is client-dependent: with snap sync, Geth, Nethermind and Besu each need roughly 500 GB or more just for execution data, while an archive node — every historical state, not just current — runs 12 TB or more on those same clients, or in the 2–2.5 TB range on Erigon and Reth, which store state differently. Second, the consensus client is a separate budget line: plan for another 200 GB for beacon-chain data on top of the execution client's footprint. None of this is a one-time cost either — an Ethereum node's disk usage grows for as long as the node stays online, because the chain keeps producing blocks. Sync time itself depends on hardware, network speed and the sync mode chosen; the official docs don't publish a fixed duration, and neither will we, so treat any specific day-count you see elsewhere as a guess rather than a spec.
How to run an Ethereum node, at a high level
Running an Ethereum node breaks down into a handful of ongoing responsibilities, not a single install step. Pick and install a matched execution/consensus client pair. Provision the hardware from the table above — undersizing storage is the most common mistake, because the safety margin shrinks every month the node stays synced. Start both clients, point them at each other's local RPC endpoints, and let the initial sync run to completion before you rely on the node for anything. After that, the job becomes operational: apply client updates promptly (hard forks require it), monitor peer count and disk headroom, and keep the machine reachable 24/7, because a node that goes offline for an extended period has to catch back up before it's useful again. None of this is unusual for infrastructure — it's the same maintenance profile as running any other stateful service, just with less room for the state to get corrected after the fact.
For a step-by-step build with copy-paste commands, Geth and Lighthouse configuration, and systemd units, see the Ethereum node setup guide on the blog.
Ethereum on ARM: possible, not free of the same limits
Client teams do publish ARM64 builds, and Raspberry Pi 5-class boards can run a full node. That's real, but it doesn't change the requirements table above — a Pi still needs an external NVMe drive sized for the same 2 TB-plus footprint, RAM stays a hard floor for the client software, and the slower CPU tends to stretch initial sync further than on a comparable x86 machine. ARM is a way to run a node more cheaply and quietly at home, not a way to run it with fewer resources.
Self-hosted node vs. Chaingateway API
Both give you Ethereum data and the ability to send transactions. What differs is who carries the operational load.
| Your own Ethereum node | Chaingateway API | |
|---|---|---|
| Setup | Install, configure and sync two clients | Register and get an API key |
| Storage | 2 TB+ SSD, growing every month | None on your side |
| Sync | Hours to days, hardware-dependent, one time and after any downtime | Not applicable — always synced |
| Uptime | Your responsibility, 24/7 | Covered by the service |
| Client upgrades | Applied by you, on the hard-fork schedule | Handled centrally |
| What you get | Full JSON-RPC surface, including archive queries if configured | REST endpoints for addresses, ERC-20/721/1155 transfers and deposit webhooks |
The API doesn't have to reimplement the entire JSON-RPC surface to cover the job most integrations actually hire a node for: create an address, send a token, get notified when a deposit arrives. That's the Ethereum API in one sentence.
When you actually need your own node
A self-hosted node is the right call when you're running a validator, indexing the full chain for analytics, need archive-level historical state, or have a compliance requirement that your infrastructure never depend on a third party for chain access. None of that is a fit better replaced by an API — it's a genuinely different job. If your requirement is narrower — generate deposit addresses, send ETH or ERC-20 tokens, get told when money arrives — that's the exact surface a payments API is built for, without the storage and uptime commitment attached to it.
If your actual requirement is sending ERC-20 tokens and watching deposits, create a free account and try the same job over REST before you provision 2 TB of SSD.
The node-free version: create an address and send an ERC-20 token
No RPC endpoint, no client pair to keep synced — one Bearer token in the Authorization header.
curl -X POST https://app.chaingateway.io/api/v2/ethereum/addresses \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json"
curl -X POST https://app.chaingateway.io/api/v2/ethereum/transactions/erc20 \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"contractaddress": "0xdAC17F958D2ee523a2206206994597C13D831ec7",
"from": "0xYourHotWallet",
"to": "0xRecipient",
"amount": 100,
"password": "YourWalletPassword"
}'FAQ: Ethereum nodes
Skip the node, keep the data
Create an account and send a testnet ERC-20 transfer in minutes — 7-day trial, no card, no KYC. The full endpoint set is in the Ethereum API reference, and every chain is covered by the multi-chain blockchain API.