Most DeFi teams start out renting blockchain access from an RPC provider — we covered how to pick one in our buyer's guide to blockchain RPC and node infrastructure. But there's a second path that guide only touched on: running your own Ethereum node. No per-request billing, no rate limits, no provider outage taking your product down at the worst moment.
Self-hosting is a real option, not just an ideology. It's also real work, with real hardware costs and a real on-call burden. This guide lays out what a node actually requires in 2026 — the hardware, the client software choices, the ongoing maintenance — and, more importantly, who should and shouldn't take it on. It's written for teams making an infrastructure decision, not for hobbyists who already know they want to tinker.
What "Running a Node" Actually Means
An Ethereum node is a computer that keeps a synced copy of the chain and verifies every new block itself. Since Ethereum's move to proof of stake, "a node" is actually two pieces of software running together: an execution client (which processes transactions and holds the chain's state) and a consensus client (which follows the proof-of-stake protocol and tells the execution client which chain to follow). You need one of each. They talk to each other locally, and together they give you the same JSON-RPC interface a commercial provider sells you.
That last part is the point. Once your node is synced, your own applications point their RPC URL at your own machine instead of a provider's endpoint. Every eth_call, every balance check, every event subscription runs against hardware you control, with no metering and no third party seeing your traffic.
There are also different depths of node. A full node keeps current state and recent history — enough for almost all live application traffic. An archive node keeps every historical state the chain has ever had, which is what you need for deep historical queries, and its disk footprint is several times larger. If your product only reads current balances and recent events, a full node covers you; if you're building analytics that reach back years, archive requirements change the hardware math significantly.
Why do it at all? The Ethereum Foundation's own run-a-node documentation lists the core benefits plainly: privacy (no third party logs your queries), censorship resistance, sovereignty over verification, and a direct contribution to network decentralization (ethereum.org, "Spin up your own Ethereum node," accessed August 29, 2026). For a business, the practical draws are the first one and a fourth the docs undersell: predictable cost. A node costs the same in a quiet month and in a traffic spike.
Hardware You Actually Need (and What It Costs)
The ethereum.org run-a-node documentation puts the floor at 4–8 GB of RAM and a 2 TB SSD, and it's explicit that the SSD is not optional — a spinning hard drive cannot keep up with the write speeds a synced node requires (ethereum.org, accessed August 29, 2026). Treat those numbers as the minimum to participate, not a comfortable production target.
A more realistic 2026 build for a node that serves real application traffic looks like this:
| Component | Minimum (per ethereum.org) | Comfortable production target |
|---|---|---|
| CPU | Modern x86 (Intel NUC 7th gen+ class) | 4–8 fast cores |
| RAM | 4–8 GB | 16–32 GB |
| Disk | 2 TB SSD | 2–4 TB NVMe SSD |
| Network | Stable broadband | Wired, generous or unmetered data cap |
| Power | Always on | Always on, ideally with battery backup |
Three cost notes worth internalizing before you price this out:
- The disk is the budget item that grows. Chain state grows continuously, so a 2 TB drive that fits today is a drive you will replace. NVMe drives in the 2–4 TB range are the recurring capital cost of self-hosting.
- Bandwidth is not free. A node uploads and downloads constantly to stay in sync and serve peers. On a metered home or office connection, this shows up on the bill; ethereum.org recommends a wired connection for consistency.
- The machine must stay on. A node that shuts down overnight resyncs every morning. Factor in electricity for an always-on machine and, ideally, a battery backup so a brief power cut doesn't turn into hours of catch-up syncing.
All in, a serious self-hosted setup lands roughly in the $600–$1,500 range up front for a dedicated small-form-factor machine with a quality NVMe drive, plus electricity and bandwidth monthly. Compare that with the provider pricing we broke down in the RPC buyer's guide — where entry paid plans cluster around $49–$50 a month — and the crossover math becomes concrete: hardware pays for itself somewhere between one and three years of a mid-tier provider subscription, before you count your own time. That last clause is doing a lot of work in this sentence, and the maintenance section below is about exactly that.
If you want the always-on box without assembling it yourself, plug-and-play node hardware exists: the ethereum.org documentation points to Dappnode, a free and open-source node operating system that also ships on pre-configured hardware, as the app-like route to the same result. You still own the machine and the node; you skip the OS assembly.
There's a middle path between your own hardware and a shared RPC provider, and it's worth naming so you can price it honestly: renting a bare-metal or virtual server from a hosting company and running your node software on that. You avoid the up-front hardware purchase and get datacenter power and bandwidth, but a server with node-grade NVMe storage typically rents for a meaningful monthly fee — often comparable to or above a mid-tier RPC plan — and you keep all of the operational duties described below. Cloud-hosting a node makes the most sense when you need the node's privacy or unmetered-query benefits but can't physically host a machine; it makes the least sense as a pure cost play, because you're paying rent on the exact hardware self-hosting would let you own.
One more disk-planning note: the 2 TB figure is for a full node. If your product needs deep historical state — the archive-node use case flagged earlier — expect a multiple of that footprint and look at clients optimized for it (Erigon built its reputation here) before assuming your provider's archive tier is the only option. Archive self-hosting is a bigger commitment on every axis: more disk, longer initial sync, more to monitor.
More in Guides
Choosing Your Execution and Consensus Clients
Because a post-merge node is two programs, you make two software choices. All the major clients are free and open source; they differ in language, resource appetite, and maturity.
On the execution side, the widely used options are Geth (the original Go implementation), Nethermind (.NET), Besu (Java), Erigon (Go, optimized for archive nodes), and Reth (Rust, the newest of the group). On the consensus side: Lighthouse (Rust), Prysm (Go), Teku (Java), Nimbus (Nim, designed for lighter hardware), and Lodestar (TypeScript).
Which ones does the network actually run? Per the client diversity tracker at clientdiversity.org, execution-layer usage as surveyed by supermajority.info puts Geth and Nethermind at roughly 43% each, with Besu near 8% and Erigon and Reth around 3% apiece; on the consensus layer, Rated Network's daily data shows Teku at about 54%, with Prysm and Lighthouse each near 21% (clientdiversity.org, accessed August 29, 2026; the site notes the execution-layer survey data is manually updated and can be stale).
Those percentages matter for a reason beyond trivia. Ethereum's finality rules mean a client running on more than two-thirds of the network can finalize a broken chain if it has a bug — and validators who followed it cannot return to the correct chain without being slashed. A client above one-third of the network can stall finality outright. That's why clientdiversity.org's stated goal is every client below 33% market share. For you as an operator, the practical reading is simpler: picking a minority client is not a compromise — it's mildly good for the network, and every client listed above is production-grade. Pick based on your team's language comfort (you will eventually read logs and file issues) and your hardware budget; Nimbus, for example, is explicitly designed for smaller machines.
A note on getting synced in the first place, because this is where most first attempts stall. Modern consensus clients support checkpoint sync: instead of replaying the chain's entire history from the very first block, your client starts from a recent finalized checkpoint fetched from a source you trust, and is following the live chain within minutes. The execution client still has to build its state database, which is the part that takes hours to days depending on your disk and connection — this is why the SSD requirement is non-negotiable, and why the first number to watch on a new node is sync progress, not query latency. Plan the initial sync for a day when nobody is waiting on the node.
One habit worth stealing from professional operators regardless of which pair you pick: note which client versions you run, and read release notes before upgrading. Client teams ship hard-fork-critical updates on a schedule the network does not wait on.
It's also worth saying explicitly that you don't have to feel locked into your first choice. Because every client implements the same protocol, you can switch execution or consensus clients later without touching your applications — the JSON-RPC interface your code talks to stays the same. Switching costs you a resync, not a rewrite. That freedom is exactly what you give up in reverse with a commercial provider, where changing vendors means changing endpoints, API keys, and sometimes billing math mid-contract.
Who Should Self-Host: Three Real Situations
Situation 1: A privacy-sensitive team that cannot leak query patterns. If your product's RPC traffic itself reveals strategy — a trading desk polling specific pools, a fund checking positions before rebalancing — every query you send a commercial provider is data someone else holds. A self-hosted node removes that third party entirely. This is the one situation where self-hosting is close to mandatory rather than a cost tradeoff, because no provider plan, at any price, changes who sees your traffic.
Situation 2: A product with heavy, steady read traffic and a predictable budget. Per-request billing punishes exactly the workloads that are cheapest to self-serve: constant polling, dashboards, indexers that re-read state all day. If your monthly provider invoice is consistently in the hundreds of dollars and your traffic is steady rather than spiky, a node you own converts a variable cost into a fixed one. Run the crossover math against your actual invoice, not a hypothetical one — and remember the hybrid option: many teams keep a provider as a fallback while serving baseline traffic from their own node, which also answers the redundancy concern raised in our provider guide.
Situation 3: A solo staker or a team that wants to validate. Staking raises the hardware bar — ethereum.org recommends 16 GB of RAM minimum (32 GB better) and a CPU scoring 6667+ on cpubenchmark.net for validator duty — but it also changes the reason you're running a node. A validator must run its own node anyway; the RPC endpoint you get out of it is effectively free once the staking hardware exists. If you're already committed to staking, pointing your applications at your validator's node is the easy second win.
And who shouldn't self-host? A team shipping its first prototype. Every hour spent syncing a node is an hour not spent on the product, and free provider tiers — compared in detail in the buyer's guide — are generous enough to carry a prototype indefinitely. Start rented; revisit when the invoice or the privacy question forces the issue.
The Ongoing Work Nobody Budgets For
The hardware is the visible cost. The recurring cost is operational, and it's the reason "just run a node" is glib advice.
An initial sync takes somewhere between hours and days depending on your client, disk speed, and connection — and until it finishes, your node answers nothing. After that, the work is periodic but permanent: applying client updates (some of which are mandatory before network upgrades and have deadlines), watching disk usage as state grows, monitoring that both clients are actually synced rather than silently stalled, and diagnosing the occasional peer-connectivity or database-corruption issue that every long-running node eventually hits.
None of this is hard for a team that already runs servers. All of it is new work for a team that doesn't. The honest framing: a self-hosted node is a small production service with an uptime requirement, owned by you. If nobody on the team wants to own it, that's a complete answer — stay with a provider, and spend the energy negotiating a better plan instead.
Monitoring deserves one concrete tip. The failure mode that bites application teams is not the node crashing — crashes are loud. It's the node quietly falling behind the chain head while still answering queries, so your app serves data that's minutes or hours stale. Whatever monitoring you use, alert on sync distance (how far your node lags the newest block), not just on whether the process is running.
Common Mistakes When Running Your Own Ethereum Node
- Buying the minimum hardware. The 4–8 GB RAM / 2 TB floor from the documentation keeps a node alive; it does not keep a node fast under your application's query load, and it leaves no headroom for state growth. Production nodes should start at the comfortable column of the table above.
- Skipping the SSD requirement. A cheap high-capacity spinning drive looks tempting at 2 TB prices. It will not sync. The write-speed requirement is real, and NVMe is the safe default in 2026.
- Running the node and the application on the same overloaded box. A node under sync load competes for disk and CPU with whatever else shares the machine. Give it its own hardware or its own well-provisioned VM.
- Treating the node as done once it syncs. Client updates with hard deadlines, disk growth, and stale-sync monitoring are permanent duties. A node without an owner degrades on a timescale of months.
- Cutting over all traffic on day one. Keep your existing provider endpoint configured as a fallback while your node earns trust. The two-provider redundancy argument from the RPC buyer's guide applies unchanged when one of the two "providers" is your own machine.
Self-hosting an Ethereum node is neither the badge of seriousness its advocates suggest nor the ops nightmare its detractors suggest. It's a straightforward tradeoff: roughly $600–$1,500 of hardware plus a permanent, modest operational duty, in exchange for unmetered queries, privacy, and independence from any provider's outages and pricing changes.
The decision rule that falls out of the three situations above: self-host when query privacy is non-negotiable, when steady traffic makes the crossover math clearly favorable against your real invoices, or when staking means you're running the hardware anyway. Rent when you're prototyping, when nobody on the team can own an always-on service, or when your traffic is too spiky for fixed hardware to absorb. And whichever side you land on, don't run on a single point of failure — pair your node with a provider fallback, or your provider with a second provider, as covered in the buyer's guide.
Hardware figures and client market-share numbers in this guide reflect the cited public documentation as of late August 2026 and will drift; check current requirements and release notes before buying hardware or choosing clients.
Sources
- ethereum.org, "Spin up your own Ethereum node," accessed August 29, 2026 — minimum and staking hardware requirements, SSD requirement, and stated benefits of self-hosting.
- clientdiversity.org, client market-share data via supermajority.info (execution layer, manually updated) and Rated Network (consensus layer, daily), accessed August 29, 2026 — usage percentages and the 33%/66% finality-risk thresholds.
- Ethereum Foundation run-a-node documentation on plug-and-play hardware (Dappnode), accessed August 29, 2026 — pre-configured node hardware and software options.