Run an OP Stack Node | Conduit Documentation

At this time, the setup and maintenance of self-hosted nodes are not included in Conduit’s standard scope of support. The guide below provides a high-level overview for setting up an external node. Please note that, due to frequent updates to the underlying software, additional configuration steps or variables may be required.

If you’re onboarding a partner or tool, we recommend using Conduit Nodes — the managed, production-ready version of nodes for your RPC needs. Conduit RPC nodes are actively maintained, monitored, and optimized to scale with your network’s performance requirements.

If you’d like to maintain a backup RPC provider, we suggest Tenderly, an approved Conduit vendor.

To run a self-hosted node for an OP Stack rollup deployed on Conduit, please follow the steps below to configure the necessary settings and gather all required information. Afterwards, you can proceed with Conduit’s Github Repository on how to run a node.

Access settings

Navigate to your deployment dashboard. Click on Settings, then select General from the sidebar.

Enable external nodes

Activate the Enable external nodes setting. Note: If you wish to disable this setting later, please contact our Support.

Gather required information from the deployment dashboard

Navigate to the Deployment Dashboard. Go to the Overview section and click the Run a Node button on the right side.

Visit the Conduit Hub if the network is public, select the network and click on Run a Node.

Access configuration files

The popup will provide the rollup.json, genesis.json files and other required parameters.

Next steps

You should now have all the information about your Rollup that is needed to run your own self-hosted node. Follow Conduit’s Repository for the next Steps.

Snapshots

You can initialize OP Stack external nodes from Conduit snapshots. Snapshots can take up to 4 hours to become available after you enable external nodes. Conduit stores the snapshots in a requester-pays Google Cloud Storage bucket, so you need a Google Cloud project with billing enabled. You also need the roles/serviceusage.serviceUsageConsumer role on the billing project. See the requester-pays requirements.

Set NETWORK to your network slug from the Conduit dashboard or Hub. Set CLOUDSDK_BILLING_QUOTA_PROJECT to the Google Cloud project that pays for the download. Set DATADIR to the directory where you want to extract the snapshot.

(
  set -euo pipefail
  export LC_ALL=C
  export CLOUDSDK_BILLING_QUOTA_PROJECT="<billing-project-id>"
  NETWORK="<network>"
  DATADIR="<path/to/datadir>"
  PREFIX="gs://conduit-networks-snapshots/${NETWORK}"
  mkdir -p "${DATADIR}"
  WORK="$(mktemp -d "${DATADIR}/.snapshot.XXXXXX")"
  trap 'rm -rf "${WORK}"' EXIT
  if gcloud storage ls "${PREFIX}/snapshot_part_aa.tar.part" >/dev/null 2>&1; then
    gcloud storage cp "${PREFIX}/snapshot_part_*.tar.part" "${WORK}/"
  else
    gcloud storage cp "${PREFIX}/latest.tar" "${WORK}/"
  fi
  cat "${WORK}"/* | tar -xf - -C "${DATADIR}"
)

Conduit splits snapshots larger than 5 TB into files such as snapshot_part_aa.tar.part and snapshot_part_ab.tar.part. The command downloads multipart snapshots in parallel and streams the parts into tar in filename order. It doesn’t create a second assembled archive. If no multipart snapshot exists, the command downloads and extracts latest.tar instead. After extraction, it removes the downloaded archive files.

Replica Configuration and Monitoring

P2P configuration

You will find the value for OP_NODE_P2P_STATIC in the same popup. Your node follows the chain tip by receiving new blocks over consensus-layer gossip from that peer, which is the only consensus-layer connection it needs. Set OP_NODE_P2P_NO_DISCOVERY to true: there is no discovery network for external nodes, so leaving discovery on only adds failing dial attempts.

Closing a gap

If your node is stopped or falls behind, it catches up through its execution layer rather than its consensus layer. op-node v1.19.1 removed the request/response consensus-layer sync client, so a node that falls behind no longer asks a consensus-layer peer for the blocks it missed. Run op-node v1.19.2 or later and set OP_NODE_SYNCMODE to execution-layer.

Because catch-up happens at the execution layer, op-reth needs an execution-layer peer to fetch the missing range from. Conduit publishes one per network, and make setup in Conduit’s repository writes it into config/reth.toml for you. It must be configured as a trusted peer rather than a bootnode.

That peer retains a rolling window of recent blocks rather than full history, so it closes gaps but does not sync a node from genesis. Start a fresh node from a snapshot, then the peer keeps it current.

If you have previously configured OP_NODE_P2P_BOOTNODES, OP_NODE_P2P_DISCOVERY_PATH, OP_NODE_P2P_PEERSTORE_PATH, or OP_NODE_P2P_SYNC_ONLYREQTOSTATIC, remove them. The last of these controlled the sync client that v1.19.1 removed and no longer has any effect.

Submitting transactions to your node (if required)

If you plan to submit transactions to your node, set the public RPC URL of your network as the L2_REMOTE_RPC. For production usage, you can generate an API Key via Conduit Nodes. You can find the public RPC URL in the dashboard or on the hub.

Monitoring Sync Progress

Run optimism_syncStatus to check the current sync status of your node. From the output, note the block number associated with the sync status. Search for this block number on your block explorer to determine when it was processed on our end. By comparing the block’s processing time, you can estimate how far behind your node is in the synchronization process.

Sign in