On this page 9 sections
- The official Nitro hardware requirements
- HashDB or PathDB: choose before the first sync
- Arbitrum archive node size and full node disk
- Why 64 to 128 GB of RAM, and which CPU
- The L1 requirement: Ethereum RPC and beacon with historical blobs
- Ports and bandwidth
- Which PowerDedi server for an Arbitrum node
- How to run an Arbitrum node: setup outline
- 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:
| Resource | Minimum | Recommended |
|---|---|---|
| RAM (DDR5) | 64 GB | 128 GB or more |
| CPU | 8-core, 3rd-generation CPU (on AWS, an i4i.2xlarge) | 16 cores or more, of a newer generation |
| Storage type | NVMe SSD; locally attached drives strongly recommended | Same |
| Storage size | Depends on the chain and its traffic; ideally several terabytes | Same, 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 fullcan take multiple days on NVMe for Arbitrum One, during which the node serves no RPC. - PathDB, enabled with
--execution.caching.state-scheme=pathfrom 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 kind | Scheme | Snapshot date | Size |
|---|---|---|---|
Arbitrum One, pruned (full node) | HashDB | Oct 5, 2026 | 2.67 TB |
Arbitrum One, full-path (full node) | PathDB | Oct 7, 2026 | 2.72 TB |
Arbitrum One, archive-path | PathDB | Oct 7, 2026 | 4.23 TB |
Arbitrum One, archive | HashDB | Aug 11, 2023 (outdated) | 4.96 TB |
Arbitrum Nova, pruned / archive | HashDB | Sep 8 / Sep 9, 2026 | 0.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-pathgrew 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
| Port | Protocol | Use |
|---|---|---|
| 8547 | RPC over HTTP | Your applications; firewall it |
| 8548 | RPC over WebSocket | Needs --ws.port, --ws.addr and --ws.origins |
| 9642 | Sequencer feed | Feed 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
| Use | Configuration | Fit | Price |
|---|---|---|---|
| Arbitrum Nova or a smaller Arbitrum chain | Ryzen 9 9950X: 16 cores at up to 5.7 GHz, 128 GB DDR5, 2 × 1.92 TB NVMe | Meets the recommended RAM and cores; 3.84 TB cannot hold an Arbitrum One snapshot during extraction | $159/mo |
| Arbitrum One full node | Ryzen 9 9950X3D: 16 cores at up to 5.7 GHz, 192 GB DDR5, 2 × 3.84 TB NVMe | Above 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 node | EPYC 9355P: 32 cores at 3.55 GHz base, 384 GB ECC, 2 × 3.84 TB NVMe Gen5 | Cores 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 Gen5 | 15.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
- Prepare to run a node — Arbitrum documentation
- How to run a full node for an Arbitrum chain — Arbitrum documentation
- How to run an archive node — Arbitrum documentation
- Nitro database snapshots — Arbitrum documentation
- Node tuning and monitoring — Arbitrum documentation
- Beacon Nodes: Historical Blobs and Ethereum beacon chain RPC providers — Arbitrum documentation
- Arbitrum Snapshots — snapshot explorer and metadata (checked October 15, 2026)
- Arbitrum Nitro v3.12.1 — Offchain Labs on GitHub, October 2, 2026
- Amazon EC2 I4i Instances — Amazon Web Services




