Running an Ethereum Node After the Latest Network Upgrade: A Hosting Checklist

If you run an Ethereum node, you’ve probably noticed that upgrades are coming faster than they used to. Fusaka reshaped node workloads in December 2025, and Glamsterdam is already being tested on Sepolia. Each fork changes what it means to have enough storage, bandwidth, and CPU.

A few checks now can save you a scramble before the next fork. Whether you’re running a full node, an RPC endpoint, or a validator, here’s what to review on your server.

How the Fusaka Upgrade Changed Ethereum Node Requirements

Fusaka changed the day-to-day workload of the machines running the network. Here's what matters most for hosting:

• PeerDAS (EIP-7594). Before Fusaka, every node downloaded every blob that rollups posted. Now blob data is split across the network, and a typical full node stores only a portion of it and samples the rest. That lowers the baseline load, but there's a catch: the more stake a node carries, the more data it has to keep. Large operators (2,048 ETH or more) and supernodes (4,096 ETH and up) store and serve far more blob data than a hobby node does.

• Blob Parameter Only (BPO) Forks. Fusaka made it possible to raise blob capacity through small, focused forks instead of waiting for a full upgrade. That's great for scaling, but it means bandwidth and storage needs can rise between major upgrades, not just at them.

• History Expiry (EIP-7642). Clients can now drop pre-merge history, saving roughly 530 GB of bandwidth on a fresh sync and keeping disk growth in check.

• A Higher Default Gas Limit. The default moved to 60 million gas, so blocks carry more work, and your CPU and disk have more to process in each slot.

So some pressures went down, and others got heavier, especially for operators running many validators.

Glamsterdam Upgrade: What Ethereum Node Operators Should Prepare For

Glamsterdam is Ethereum's next hard fork, and it makes three main changes. Enshrined proposer-builder separation (ePBS) builds the split between block builders and block proposers into the protocol itself. Block-level access lists tell clients upfront which accounts and storage a block will touch, so they can process more of it in parallel.

And new gas pricing rules charge more accurately for execution and for adding data to Ethereum's state. Glamsterdam has been live on the Sepolia testnet since 6 October 2026, where it runs with a 200 million gas limit.

The timeline is still moving, though. Core developers postponed the Hoodi testnet fork in late October while they work through how the new gas rules interact with existing smart contracts, and as of early November, they still haven't set a mainnet date.

The takeaway is that you shouldn’t wait for the announcement to plan capacity. A much higher gas limit means heavier blocks and faster state growth, and you don't want to discover your server can't cope the week before a fork.

Ethereum Node Hosting Checklist: 8 Things to Review

1. Check Your Storage, and Leave Room to Grow

Disk is still the most common bottleneck for Ethereum nodes. A full node needs at least 2 TB of fast storage, but 4 TB is safer so you don't have to migrate data in a hurry later. Archive nodes can need several terabytes or far more depending on the client, so check current numbers before sizing a server.

Use NVMe drives. Ethereum clients constantly read and write small pieces of data, and slower drives can’t keep up, so your node falls behind the latest block. For help choosing the right size, this guide to Ethereum node server requirements outlines what each node type needs.

2. Plan for Bandwidth, Not Just Speed

PeerDAS changed how data moves between nodes, and future BPO forks will add more blob capacity over time. A 1 Gbps port is a sensible baseline, but the monthly transfer allowance matters just as much. A full node can easily move 30 to 40 TB a month. If you run larger validator sets, check both your upload and download headroom, because higher-stake nodes custody and serve more data.

3. Give Your Clients The CPU And Memory They Need

Higher gas limits mean more execution work per block. Aim for a modern CPU with strong single-core speed, and at least 16 GB of RAM, with 32 GB recommended if you run both execution and consensus clients on the same machine, which most people do. If you're shopping for hardware, Dedicated Servers for Running Ethereum Nodes 2026 compares setups for full, archive, and light nodes.

4. Choose The Right Kind Of Server

A VPS is fine for testnet experiments, light workloads, or tools that sit around your node. A Crypto VPS can be a cheap, flexible place to start. For production nodes, though, dedicated hardware is usually the better fit. You get consistent disk performance, no noisy neighbors, and no hypervisor overhead.

5. Build an Upgrade Routine Before You Need It

Every hard fork requires updating both execution and consensus clients before activation. Nodes that miss the deadline end up on the wrong side of the fork. A few habits make this painless:

• Follow the Ethereum Foundation blog and your clients' release channels.

• Test new releases on a testnet node or a second server first.

• Use the eth_config RPC method added in Fusaka to confirm your fork settings are correct.

• Upgrade well before the fork, rather than in a last-minute rush.

6. Lock Down the Network

Only open the peer-to-peer ports your clients need. Keep JSON-RPC and admin APIs off the public internet unless you've put a proxy, rate limiting, and authentication in front of them. Use SSH keys instead of passwords, and pick a host that filters DDoS traffic before it reaches your server. This Blockchain Server Hosting plan includes hardware firewalls and DDoS protection, which takes a lot of this work off your plate.

7. Protect Validator Keys and Slashing Data

If you're staking, never run the same validator keys on two machines at once. That's the fastest way to get slashed. Back up your keystores and slashing protection database, encrypt them, and store copies off-server. When you move hosts, migrate the slashing protection data along with the keys. The Ultimate Guide to Crypto Staking and Server Requirements cover these practices in more detail.

8. Monitor Everything That Can Drift

Track sync status, peer count, disk usage, CPU load, and missed attestations, and set alerts so you hear about problems before they cost you. Prometheus and Grafana are the usual pairing. See BaCloud's roundup of the best open-source monitoring tools for dedicated servers for other options.

The Bottom Line

Fusaka made running a node easier in some ways and more demanding in others, and Glamsterdam will push execution and state growth further. Operators who glide through upgrades are the ones who planned for headroom, kept clients current, and saw problems coming.

If your current setup feels tight, it's a good moment to look at a crypto-dedicated server with NVMe storage and room to scale before the next fork makes the decision for you.