How to run an archive node

An Arbitrum archive node is a full node that maintains an archive of historical chain states. This how-to walks you through the process of configuring an archive node on your local machine so that you can query both pre-Nitro and post-Nitro state data.

For how archive mode relates to the other Nitro node roles, see How to assign roles to a Nitro node.

caution

Most users won't need to configure an archive node. This node type is great for a small number of use cases––for example if you need to process historical data.

Before we begin

Before the Nitro upgrade, Arbitrum One ran on the Classic stack for about one year (before block height 22207817). Although the Nitro chain uses the latest snapshot of the Classic chain's state as its genesis state, the Nitro stack can serve all but six RPC requests for pre-Nitro blocks. Full details are outlined in Do you need to run a Classic node?.

Running an Arbitrum One full node in archive mode lets you access both pre-Nitro and post-Nitro blocks, but it requires you to run both Classic and Nitro nodes together. You may not need to do this, depending on your use case:

Use case	Required node type(s)	Docs
Access the Arbitrum network without running your own node	Fully managed by third-parties, exposed via RPC endpoints	RPC endpoints and providers
Run an archive node for Arbitrum Sepolia (testnet) or Arbitrum Nova	Full node (Nitro)	How to run a full node (Nitro)
Send post-Nitro archive requests	Full node (Nitro)	How to run a full node (Nitro)
Send pre-Nitro archive requests	Full node (Classic)	How to run a full node (Classic, pre-Nitro)
Send post-Nitro and pre-Nitro archive requests	Full node (Nitro) and full node (Classic)	That's what this how-to is for; you're in the right place.

Use PathDB for archive nodes

We recommend PathDB for archive nodes on Nitro v3.9.x or later. PathDB is a path-based state scheme. It cuts archive disk use substantially, and while syncing and serving RPC calls a PathDB archive node performs about the same as, or slightly better than, a HashDB one.

Benefits:

• Lower disk usage. The Arbitrum One archive-path snapshot is about 3.7 TB. The equivalent HashDB archive snapshot is considerably larger — Nova's is about 8 TB, for a chain whose full node database is a quarter the size of Arbitrum One's.
• Automatic, online pruning. PathDB removes old state as the node runs, without your intervention. You never schedule a prune, and the node never goes offline to run one. On HashDB you prune manually, and the node stops serving RPC requests until it finishes — days, on a chain the size of Arbitrum One. This benefit applies to full nodes on PathDB too.
• Configurable retention. You choose how much state history to keep with --execution.caching.state-history.

Limitations:

• PathDB cannot validate blocks. If a node requires the block validator, Nitro exits at startup with path cannot be used as execution.caching.state-scheme when validator is required.
• Fast, local NVMe SSD storage is required for reasonable sync speed.
• --init.latest cannot download a PathDB snapshot. Use --init.url, as described in Initialize a PathDB archive node.

To enable PathDB on your archive node, start it with these flags:

Flag	Purpose
--execution.caching.archive	Enables archive mode; under PathDB, builds the state-history index so RPC can serve historical state
--execution.caching.state-scheme=path	Selects PathDB instead of the default HashDB

On Nitro before v3.10.0, also set `--execution.caching.state-history=0`

--execution.caching.state-history controls how many blocks of state history PathDB retains. From v3.10.0 onward, setting --execution.caching.archive makes it default to 0, which keeps the entire chain, so you can leave it unset.

Before v3.10.0 it defaulted to 24 hours' worth of blocks even in archive mode. Nitro logs a warning — Path scheme archive mode enabled, but state-history is not zero — and then silently retains only recent history, leaving you with an archive node that cannot serve older state. Pass --execution.caching.state-history=0 explicitly on those versions.

For cache sizing and memory tuning that applies to archive nodes generally, see node tuning and monitoring.

Initialize a PathDB archive node

A snapshot only works with a node whose state scheme matches the snapshot's. --init.latest accepts only archive, pruned, and genesis, and all three resolve to HashDB snapshots, so it cannot bootstrap a PathDB node.

Instead, pass the archive-path snapshot URL to --init.url. These snapshots are published for Arbitrum One and Arbitrum Sepolia only; Arbitrum Nova has no archive-path snapshot.

Each chain publishes a pointer file naming its current archive-path snapshot directory. Read that file to find the URL:

curl https://snapshot.arbitrum.foundation/arb1/latest-archive-path.txt

The file contains a directory path, such as arb1/2026-08-02-291ce8d7/. Pass the full URL to that directory, including the trailing slash:

--init.url https://snapshot.arbitrum.foundation/arb1/2026-08-02-291ce8d7/

Nitro reads the .manifest.txt file in that directory to enumerate the snapshot parts, downloads each one, and verifies its checksum. The directory also holds a metadata.json naming the snapshot's state_scheme, snapshot_kind, and total size, so you can confirm you have the right snapshot before downloading terabytes.

For Arbitrum Sepolia, substitute sepolia-rollup for arb1 in both URLs.

System requirements

The minimum storage requirements will change as the Nitro chains grow (see the growth rates below). We recommend exceeding the minimum requirements as much as you can to minimize risk and maintenance overhead. The disk size for archive nodes is expected to grow over time. Carefully monitor your node's disk requirements and disk growth rates to ensure your node has adequate resources.

Resource	Minimum requirements	Recommended
RAM (DDR5)	64 GB	128 GB or more
CPU	8 core 3rd generation CPUs (for AWS, a i4i.2xlarge instance)	16 core CPU or higher and more recent/newer generation of CPUs
Storage type	NVMe SSD drives with locally attached drives strongly recommended	Same
Storage size	Depends on the chain and its traffic over time, but ideally several terabytes (TB)	Same, but higher if possible

1. Docker images: We'll specify these in the below commands; you don't need to download them manually.
   • Latest Docker image for Arbitrum One Nitro: offchainlabs/nitro-node:v3.11.3-beb2108
   • Latest Docker image for Arbitrum One Classic: offchainlabs/arb-node:v1.4.6-551a39b3
2. Database snapshots:
   • Nitro database snapshot
     • Use the parameter --init.url= on the first startup to initialize the Nitro database (you can find a list of snapshots here). Example: --init.url="https://snapshot.arbitrum.foundation/arb1/nitro-archive.tar"
   • Arbitrum One Classic database snapshot
     • Download the latest Arbitrum One Classic database snapshot at https://snapshot.arbitrum.foundation/arb1/classic-archive.tar and place it in the mounted point directory
     • Note that other chains don't have Classic blocks and thus don't require an initial genesis database.
   • Snapshot Explorer
     • You can find more snapshots on our snapshot explorer
   • Archive-Path section of the snapshot explorer

Review and configure ports

• RPC: 8547
• Sequencer Feed: 9642
• WebSocket: 8548

Review and configure parameters

Arbitrum Nitro	Arbitrum Classic	Description
--parent-chain.connection.url=<Layer 1 Ethereum RPC URL>	--l1.url=<Layer 1 Ethereum RPC URL>	Provide a standard L1 node RPC endpoint that you run yourself or from a third-party node provider (see RPC endpoints and providers)
--chain.id=<L2 chain ID>	--l2.chain-id=<L2 Chain ID>	See RPC endpoints and providers for a list of Arbitrum chains and the respective child chain IDs
--execution.caching.archive	--node.caching.archive	Required for running an Arbitrum One Nitro archival node and retains past block state
--execution.caching.state-scheme	-	Default: hash. Sets the scheme Nitro uses to store its state trie, inherited from Geth. Set it to path to enable PathDB. PathDB cannot validate blocks.
--execution.caching.state-history	-	PathDB only. Number of recent blocks of state history to retain on disk. On an archive node, leave it unset: from Nitro v3.10.0 onward, --execution.caching.archive makes it default to 0, which retains the entire chain. Before v3.10.0, the default was 345,600 blocks (24 hours), so set --execution.caching.state-history=0 explicitly.
--execution.caching.pathdb-max-diff-layers	-	Default: 128 layers. Maximum number of diff layers kept in the node's memory before flushing to disk. Increasing the number of diff layers may cause the node to fall behind the chain head during busy periods since doing so slows down block processing speed and reduces sync speed. This configuration is primarily used to improve performance of shallow re-orgs (which are a concern on Ethereum but not on Arbitrum chains) and for efficient access to recent state.
-	--node.cache.allow-slow-lookup	Required for running an Arbitrum One Classic archival node. When this option is present, it will load old blocks from disk if not in memory cache.
-	--core.checkpoint-gas-frequency=156250000	Required for running an Arbitrum One Classic archival node.

Run the Docker image(s)

When running a Docker image, an external volume should be mounted to persist the database across restarts. The mount point should be /home/user/.arbitrum/mainnet.

To run both Arbitrum Nitro and/or Arbitrum Classic in archive mode, follow one or more of the below examples:

• Arbitrum One Nitro archive node:

  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.11.3-beb2108 --parent-chain.connection.url https://l1-node:8545 --chain.id=42161 --http.api=net,web3,eth --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* --execution.caching.archive

• Arbitrum One Classic archive node:

  docker run --rm -it -v /some/local/dir/arbitrum-mainnet/:/home/user/.arbitrum/mainnet -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 offchainlabs/arb-node:v1.4.6-551a39b3 --l1.url=https://l1-node:8545/ --node.chain-id=42161 --l2.disable-upstream --node.cache.allow-slow-lookup --core.checkpoint-gas-frequency=156250000 --core.lazy-load-core-machine

• Arbitrum One Nitro archive node with forwarding classic execution support:

  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.11.3-beb2108 --parent-chain.connection.url https://l1-node:8545 --chain.id=42161 --execution.rpc.classic-redirect=<classic node RPC> --http.api=net,web3,eth --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* --execution.caching.archive

Note that the above commands both map to port 8547 on their hosts. To run both on the same host, you should edit those mapping to different ports and specify your Classic node RPC URL as <classic node RPC> in your Nitro start command. To verify the connection health of your node(s), see Docker network between containers - Docker Networking Example.

A note on permissions

The Docker image is configured to run as non-root UID 1000. If you're running in Linux and you're getting permission errors when trying to run the Docker image, run this command to allow all users to update the persistent folders, replacing arbitrum-mainnet as needed:

mkdir /some/local/dir/arbitrum-mainnet
chmod -fR 777 /some/local/dir/arbitrum-mainnet

Optional parameters

Both Nitro and Classic have multiple other parameters that can be used to configure your node. For a full comprehensive list of the available parameters, use the flag --help.

PathDB configuration reference

These flags apply only when you set --execution.caching.state-scheme=path.

--execution.caching.state-scheme

Selects the TrieDB implementation Nitro uses to store its state trie. Set it to path to enable PathDB; the default is hash.

The two schemes are not interchangeable. A node can only start from a snapshot created with the same state scheme, so you cannot convert an existing database. To move to PathDB, either start from a path-scheme snapshot or sync from genesis. On Arbitrum One, syncing from genesis also requires a Classic state import.

--execution.caching.state-history

Sets how many blocks of state history Nitro retains, counting back from the chain head. 0 means the entire chain, and is therefore required — but not enough on its own — to run an archive node on PathDB. You also need --execution.caching.archive, described below.

When you leave --execution.caching.state-history unset, Nitro chooses the default at startup:

Node type	Default state-history
Full node (--execution.caching.archive=false)	345,600 blocks — 24 hours at the default 250 ms block speed
Archive node (--execution.caching.archive=true)	0, meaning the entire chain

From v3.10.0, Nitro derives this default from the archive flag. On earlier versions the default was always 24 hours' worth of blocks, so an archive node needs an explicit --execution.caching.state-history=0.

Nitro stores state history as reverse diffs in the cold database, also called the state freezer or ancients. State history lets the node recover historical state, which should allow a reorg to a historical block. Offchain Labs has not tested that reorg path.

State history alone does not let RPC calls read historical state. For that, see --execution.caching.archive below. Here, historical state means state older than pathdb-max-diff-layers + 1 blocks — 129 by default — from the node's current head.

--execution.caching.archive

Enables archive mode. Under PathDB, archive mode also builds the state history index, an extra dataset Nitro persists in the hot database (Pebble). That index is what allows RPC calls to read state older than pathdb-max-diff-layers + 1 blocks from the head.

--execution.caching.pathdb-max-diff-layers

Sets the maximum number of diff layers Nitro keeps in memory before flushing to disk. Default: 128.

Raising it can make the node fall behind the chain head during busy periods, because it slows block processing and reduces sync speed. It mainly improves performance for shallow reorgs, which matter on Ethereum but not on Arbitrum chains, and for efficient access to recent state.

Troubleshooting

If you run into any issues, visit the node-running troubleshooting guide.