1 year PowerDedi turns 1: −20% on every server with code Ends in 14 h Claim offer

PowerDedi

Guides

Arbitrum node requirements in 2026: Nitro full and archive nodes

What an Arbitrum One full or archive node needs in 2026, from Offchain Labs’ Nitro documentation: RAM, CPU, NVMe sizing, HashDB versus PathDB, current snapshot sizes, the Ethereum RPC and beacon requirement, ports and memory tuning.

By PowerDedi Engineering · · 7 min read

On this page 9 sections
  1. The official Nitro hardware requirements
  2. HashDB or PathDB: choose before the first sync
  3. Arbitrum archive node size and full node disk
  4. Why 64 to 128 GB of RAM, and which CPU
  5. The L1 requirement: Ethereum RPC and beacon with historical blobs
  6. Ports and bandwidth
  7. Which PowerDedi server for an Arbitrum node
  8. How to run an Arbitrum node: setup outline
  9. Sources

An Arbitrum Nitro full node needs 64 GB of DDR5 RAM at minimum and 128 GB recommended, an 8-core CPU (16 cores recommended) with fast single cores, and local NVMe, per Offchain Labs’ documentation. In October 2026, Arbitrum One’s full-node snapshot was 2.67 TB and its PathDB archive 4.23 TB. You also need Ethereum RPC and beacon endpoints.

The official Nitro hardware requirements

Offchain Labs publishes one hardware table for Nitro full nodes on its Prepare to run a node page and repeats it unchanged for archive nodes. Verified on October 15, 2026:

ResourceMinimumRecommended
RAM (DDR5)64 GB128 GB or more
CPU8-core, 3rd-generation CPU (on AWS, an i4i.2xlarge)16 cores or more, of a newer generation
Storage typeNVMe SSD; locally attached drives strongly recommendedSame
Storage sizeDepends on the chain and its traffic; ideally several terabytesSame, but higher if possible

The notes under the table matter as much as the table. The minimums assume a node that handles a limited number of RPC requests; for concurrent traffic, add RAM and cores. Single-core performance is important: if the node falls behind while one core sits at 100%, Offchain Labs recommends a faster processor. And snapshot extraction needs about twice the snapshot’s size in temporary disk space. For reference, AWS lists the i4i.2xlarge with 8 vCPUs and 64 GiB of memory. The current release is Nitro v3.12.1, published on October 2, 2026; Offchain Labs supports only release versions, not betas or release candidates.

HashDB or PathDB: choose before the first sync

Nitro stores its state trie with one of two schemes, and an existing database cannot be converted; switching means re-initializing from a snapshot of the other kind.

  • HashDB is the default. It supports block validation and can be initialized with --init.latest pruned, but pruning is manual and offline: --init.prune full can take multiple days on NVMe for Arbitrum One, during which the node serves no RPC.
  • PathDB, enabled with --execution.caching.state-scheme=path from Nitro v3.9, prunes automatically while the node runs, keeping 345,600 blocks of state history by default, 24 hours at Arbitrum’s 250 ms block time. It cannot validate blocks, and its snapshots must be passed with --init.url.

A default full node runs in watchtower mode, which does not need the block validator, so PathDB is an option for most RPC nodes. For archive nodes, Offchain Labs recommends it outright.

Arbitrum archive node size and full node disk

An Arbitrum One node must start from a snapshot, because Nitro cannot replay the Classic era. The Arbitrum Foundation’s snapshot metadata, checked on October 15, 2026:

Chain and kindSchemeSnapshot dateSize
Arbitrum One, pruned (full node)HashDBOct 5, 20262.67 TB
Arbitrum One, full-path (full node)PathDBOct 7, 20262.72 TB
Arbitrum One, archive-pathPathDBOct 7, 20264.23 TB
Arbitrum One, archiveHashDBAug 11, 2023 (outdated)4.96 TB
Arbitrum Nova, pruned / archiveHashDBSep 8 / Sep 9, 20260.62 TB / 8.74 TB

Sizes are in decimal terabytes; the metadata’s own “TB” labels are binary units (2.43, 2.48 and 3.85 TiB for the first three rows). The guides quote lower, rounder figures: about 2.3 TB for pruned, 2.4 TB for full-path and 3.7 TB for archive-path. Size disks from the current metadata.

  • Plan twice the snapshot during setup. A full node needs about 5.4 TB free while it initializes and an archive node about 8.5 TB, because the downloaded archive and the extracted database coexist until Nitro deletes the archive. The snapshots are uncompressed, so the database ends up roughly the snapshot’s size.
  • Expect steady growth. Between the September 26 and October 7 snapshots, archive-path grew by about 32 GB, or 2.9 GB a day. A HashDB full node also grows between manual prunes, while PathDB stays within its window.
  • Pre-Nitro history needs a second node. Nitro serves all but six RPC methods for blocks before 22,207,817; archive queries on those need an Arbitrum Classic node, whose archive snapshot is 657 GB.

Offchain Labs notes that most users won’t need an archive node: it serves a small number of use cases, such as processing historical data.

Why 64 to 128 GB of RAM, and which CPU

Nitro is a Go program that, in Offchain Labs’ words, “can use significantly more memory than Go’s runtime reports”. Its Pebble database cache (2,048 MB by default), up to half as much again in memtables, trie and snapshot caches of 1,024, 600 and 400 MB, and a 256 MB Stylus cache sit partly outside Go’s garbage collector. Heavy RPC load and large debug_traceBlockByNumber calls add more on top. The tuning guide suggests three guards:

  • GOMEMLIMIT, a soft limit for the Go heap: 48 GiB on a 64 GB machine in the docs’ example.
  • --node.resource-mgmt.mem-free-limit=4GiB, which declines new RPC requests when free memory runs low.
  • MALLOC_ARENA_MAX=2, which caps glibc at two memory arenas; unchecked arena growth is, per the docs, the most common cause of unexplained memory growth in long-running Nitro nodes.

For the CPU, the single-core advice above outweighs core count: the docs’ sign of an undersized processor is one core at 100% while the node falls behind a chain that produces a block every 250 ms, not a shortage of cores. Extra cores pay off for concurrent RPC traffic.

The L1 requirement: Ethereum RPC and beacon with historical blobs

Every Arbitrum One node needs --parent-chain.connection.url, an Ethereum execution RPC, and --parent-chain.blob-client.beacon-url, a beacon chain endpoint, because batches are posted to Ethereum as blobs that live on the beacon chain. A new node, or one offline for more than 18 days, also needs historical blob data from that endpoint. Since Ethereum’s Fusaka upgrade, that endpoint must be configured to keep and serve historical blobs: Offchain Labs asks external providers to subscribe to all data subnets, and for a self-hosted Prysm node recommends version 7.1.0 or newer with --semi-supernode and --enable-backfill.

Self-hosting means running both an execution and a consensus client, kept up to date, since an incompatible L1 client version can crash an Arbitrum node or stop it syncing. Size that L1 node separately with our Ethereum node hardware guide, and budget extra disk for the blob history its beacon node keeps.

Ports and bandwidth

PortProtocolUse
8547RPC over HTTPYour applications; firewall it
8548RPC over WebSocketNeeds --ws.port, --ws.addr and --ws.origins
9642Sequencer feedFeed relay output, for your own nodes

A full node connects out to the sequencer feed over WebSocket; the only listening ports the docs list for it are its own RPC ports. With more than one node, Offchain Labs strongly recommends one feed relay per data center, which serves the feed to your nodes on port 9642, reduces ingress fees and improves stability. The docs give no bandwidth figure. The largest predictable transfer is the snapshot: at a sustained 1 Gbps, the 2.67 TB pruned snapshot takes about six hours and the archive about nine and a half. The L1 node, if you host it, adds its own peer traffic, which is where an unmetered 10 Gbps port helps.

Which PowerDedi server for an Arbitrum node

UseConfigurationFitPrice
Arbitrum Nova or a smaller Arbitrum chainRyzen 9 9950X: 16 cores at up to 5.7 GHz, 128 GB DDR5, 2 × 1.92 TB NVMeMeets the recommended RAM and cores; 3.84 TB cannot hold an Arbitrum One snapshot during extraction$159/mo
Arbitrum One full nodeRyzen 9 9950X3D: 16 cores at up to 5.7 GHz, 192 GB DDR5, 2 × 3.84 TB NVMeAbove the recommended RAM; 7.68 TB striped covers the 5.4 TB setup peak with about 5 TB free afterwards$219/mo
Busy RPC full nodeEPYC 9355P: 32 cores at 3.55 GHz base, 384 GB ECC, 2 × 3.84 TB NVMe Gen5Cores and memory for concurrent requests with good clocks; built in 24 hours$519/mo
Archive node (PathDB)EPYC 9555P: 64 cores, 768 GB ECC, 4 × 3.84 TB NVMe Gen515.36 TB striped: the 8.5 TB setup peak, plus the Classic archive and years of growth at today’s pace; built in 24 hours$949/mo

The honest caveats are about disks. The 9950X and the EPYC 4585PX ($179/mo) both meet the RAM and CPU recommendations, but their 2 × 1.92 TB cannot take the roughly 5.4 TB an Arbitrum One snapshot needs during setup, so we do not suggest them for Arbitrum One. No two-drive server we sell fits the 8.5 TB archive setup peak. The in-stock EPYC 9454P ($489/mo) has the same 7.68 TB as the 9355P but a 2.75 GHz base clock, a weaker match for Nitro’s single-core sensitivity. Finally, every layout above stripes its drives: a failed drive means another snapshot download, so keep the setup scripted.

How to run an Arbitrum node: setup outline

These commands come from Offchain Labs’ documentation; replace the bracketed L1 endpoints with yours.

# 1. Create the data directory first: the container runs as UID 1000
mkdir -p /some/local/dir/arbitrum

# 2. Arbitrum One full node on HashDB, from the latest pruned snapshot
docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 offchainlabs/nitro-node:v3.12.1-70fa99a --parent-chain.connection.url=<Ethereum RPC URL> --parent-chain.blob-client.beacon-url=<Ethereum beacon chain RPC URL> --chain.id=42161 --init.latest=pruned --http.api=net,web3,eth --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=*

# PathDB instead: read the current snapshot directory, then start with
#   --execution.caching.state-scheme=path --init.url https://snapshot.arbitrum.foundation/arb1/<directory>/
curl https://snapshot.arbitrum.foundation/arb1/latest-full-path.txt
# Archive node: use latest-archive-path.txt and add --execution.caching.archive

# Memory guards, as in the docs' example for a 64 GB machine
#   docker run ... -e GOMEMLIMIT=48GiB ... --node.resource-mgmt.mem-free-limit=4GiB

# 3. Shut down gracefully so Nitro can write its state to disk
#    (the documented command stops every running container)
docker stop --time=1800 $(docker ps -aq)

The documented command publishes RPC on all interfaces, so restrict ports 8547 and 8548 with a firewall; our first-hour hardening checklist covers it. Current stock is on our blockchain node hosting page.

Sources

PowerDedi Engineering

The team that builds, racks and runs every PowerDedi server. We write about the hardware, networks and costs we deal with every day, and we cite our sources.

Related articles

All articles
Guides

Avalanche node requirements in 2026: AvalancheGo and validators

What an AvalancheGo node needs in 2026, from Avalanche’s official documentation: validator tiers by stake, disk growth and resyncs after the Helicon upgrade, C-Chain archive sizes, L1 validators after ACP-77, staking rules, ports and matching servers.

12 min read

Your next server is 15 minutes away.

From $55/month with 10 Gbps unmetered, no setup fee and no contract.

Live in ~15 minCancel anytimeBTC, ETH, XMR, USDT or SOL