Skip to main content

Prepare to run a node

info

If you’re interested in accessing an Arbitrum chain but don’t want to set up your own node, see our Node Providers to get RPC access to fully managed nodes hosted by a third-party provider.

This how-to provides step-by-step instructions for preparing the information you will need to run a full node for Arbitrum on your local machine.

Prerequisites​

In addition to the hardware requirements, the following prerequisites will be necessary when initially setting up your node. It is essential not to skip over these items. You would benefit by copying and pasting them into a notepad or text editor, as you will need to combine them with other commands and configuration/parameter options when you initially run your Arbitrum node.

Minimum hardware configuration​

The following are the minimum hardware requirements to set up a Nitro full node (not archival):

ResourceMinimum requirementsRecommended
RAM (DDR5)64 GB128 GB or more
CPU8 core 3rd generation CPUs (for AWS, a i4i.2xlarge instance)16 core CPU or higher and more recent/newer generation of CPUs
Storage typeNVMe SSD drives with locally attached drives strongly recommendedSame
Storage sizeDepends on the chain and its traffic over time, but ideally several terabytes (TB)Same, but higher if possible

Please note that:

  • The minimum requirements for RAM and CPU listed here are recommended for nodes that handle a limited number of RPC requests. For nodes that need to process multiple simultaneous requests, both the RAM size and the number of CPU cores should be increased to accommodate higher levels of traffic.
  • Single core performance is important. If the node is falling behind and a single core is 100% busy, the recommendation is to upgrade to a faster processor.
  • The minimum storage requirements will change over time as the chain grows. Using more than the minimum requirements to run a robust full node is recommended. Note that snapshot extraction requires approximately 2x the snapshot size in temporary disk space, so plan accordingly during initial setup.
  • Nitro stores its state trie using either HashDB (the default) or PathDB. The choice affects which snapshot you can use, so make it before you initialize the database. Both schemes have published full node snapshots; PathDB prunes automatically but cannot validate blocks. See Choose a state scheme.

Parent chain (L1) client​

Your Arbitrum node requires a connection to a parent chain RPC endpoint (e.g., an Ethereum execution client for Arbitrum One or Nova). Keep your parent chain client up to date—incompatible L1 client versions can cause your Arbitrum node to crash or fail to sync. When upgrading your L1 client, check the Nitro release notes for any noted compatibility requirements.

caution

Although there are beta and release candidate versions of the Arbitrum Nitro software, use only the release version when running your node. Running beta or RC versions is not supported and might lead to unexpected behaviors and/or database corruption.

Latest Docker image: offchainlabs/nitro-node:v3.11.3-beb2108

Database snapshots​

Snapshots availability

Database snapshots for Arbitrum One, Arbitrum Nova, and Arbitrum Sepolia are available in the snapshot explorer.

Snapshots are published per state scheme, and a snapshot only works with a node using the same scheme:

Snapshot kindNode typeState schemeAvailable for
prunedFull nodeHashDBArbitrum One, Nova, Sepolia
full-pathFull nodePathDBArbitrum One, Nova, Sepolia
archiveArchiveHashDBArbitrum One, Nova, Sepolia
archive-pathArchivePathDBArbitrum One, Sepolia

Only the HashDB kinds distinguish pruned from unpruned. PathDB prunes as it runs, so every PathDB snapshot is already pruned to its state-history window — there is no separate unpruned variant to publish. The pruned kind exists because a HashDB database is pruned manually, and the published HashDB full node snapshots happen to be pruned ones.

--init.latest cannot download the PathDB kinds. See PathDB snapshots.

Database snapshots for other Arbitrum chains may be available at the discretion of the chain's team. Get in touch with them if you're interested in using a database snapshot for their chains.

Supplying a database snapshot when starting your node for the first time is required for Arbitrum One (to provide information from the Classic era) but is optional for other chains. Supplying a database snapshot on the first run will provide the state and data for that chain up to a specific block, allowing the node to sync faster to the head of the chain.

We provide a summary of the available parameters here, but we recommend reading the complete guide if you plan to use snapshots.

  • Use the parameter --init.latest <snapshot type> (accepted values: archive, pruned, genesis) to instruct your node to download the corresponding snapshot from the configured URL
  • Optionally, use the parameter --init.latest-base to set the base URL when searching for the latest snapshot
  • Note that these parameters get ignored if a database already exists
  • When running more than one node, it's easier to manually download the different parts of the snapshot, join them into a single archive, and host it locally for your nodes. Please see Downloading the snapshot manually for instructions on how to do that.
  • Only snapshots formatted with your node's specified state scheme are compatible. In other words, a PathDB snapshot won't work for a node using HashDB, and vice versa. Each snapshot directory publishes a metadata.json file naming its state_scheme; check it before downloading.
Which initialization mode should I use?
ScenarioRecommended Parameter
Setting up a new full node on HashDB--init.latest pruned
Setting up a new full node on PathDBThe full-path snapshot with --init.url. --init.latest does not accept this kind.
Setting up a new archive node on HashDB--init.latest archive (note: the publicly hosted archive snapshot is outdated on Arbitrum One and Sepolia)
Setting up a new archive node on PathDBThe archive-path snapshot with --init.url, on Arbitrum One and Sepolia. It is smaller and more current than the HashDB archive snapshot. Nova has no archive-path snapshot.
Reducing disk usage on an existing node--init.prune full (or minimal) — only applicable to HashDB; PathDB handles state trie pruning automatically
Hosting one snapshot for multiple nodesDownload manually, then use --init.url file:///path/to/archive.tar on each node
Using a custom snapshot URL--init.url https://your-snapshot-url/archive.tar

For more details on snapshot downloading and initialization, see the complete snapshot guide.

Fusaka upgrade: historical blobs

If you're running a beacon node, historical data will now be in blobs. To make this transition to using historical blobs, refer to the Historical Blobs for Beacon Nodes guide.

Required parameters​

The following list contains all the parameters needed to configure your node. Select the appropriate option depending on the chain you want to run your node for.

1. Parent chain (Ethereum) parameters​

The --parent-chain.connection.url parameter needs to provide a standard RPC endpoint for an Ethereum node, whether self-hosted or obtained from a node service provider:

--parent-chain.connection.url=<Ethereum RPC URL>

Additionally, use the parameter --parent-chain.blob-client.beacon-url to provide a beacon chain RPC endpoint:

--parent-chain.blob-client.beacon-url=<Ethereum beacon chain RPC URL>
Try it out

If you choose to self-host an EVM node, the Prysm client software is a great choice. It's straightforward, efficient, and effective—ensuring your setup runs smoothly!

You can also consult our list of Ethereum beacon chain RPC providers. Note that historical blob data is required for these chains to properly sync up if they are new or have been offline for more than 18 days. The beacon chain RPC endpoint you use may also need to provide historical blob data. Please see Special notes on ArbOS 20: Atlas support for EIP-4844 for more details.

2. Arbitrum chain parameters​

Use the parameter --chain.id to specify the chain you're running this node for. See RPC endpoints and providers to find the IDs of these chains.

--chain.id=<Arbitrum chain ID>

Alternatively, you can use the parameter --chain.name to specify the chain you're running this node for. Use arb1 for Arbitrum One, nova for Arbitrum Nova, or sepolia-rollup for Arbitrum Sepolia.

--chain.name=<Child chain name>

Run a full node​

Now that you have all the prerequisite information prepared—it's time to run your node. Follow the instructions on the Run a full node page.