Skip to main content
A Berachain node consists of two clients running together: a consensus client (BeaconKit) and an execution client (Bera-Reth). This guide walks you through setting up both on a Linux or Mac computer.

Prerequisites

Hardware

Software

Check EVM Execution Clients for the current recommended Beacon Kit and Bera-Reth releases for your network, then download each binary from its GitHub release page:
  1. BeaconKit — on the Beacon Kit releases page, open the tagged release for your network and download the build for your OS and architecture. Make it executable and place it in your PATH (e.g., ~/.local/bin/).
  2. Bera-Reth — on the Bera-Reth releases page, open the matching tagged release and download the build for your OS and architecture. Make it executable and place it in your PATH.
Verify installation:
Both commands should report the release listed for your network on EVM Execution Clients.

What you’ll do

  1. Download scripts — clone helper scripts that automate configuration
  2. Configure environment — set environment variables for your network (mainnet or bepolia) and node identity
  3. Fetch parameters — download consensus-layer genesis and network configuration
  4. Set up BeaconKit — initialize the consensus client and generate keys
  5. Set up execution client — initialize the Reth datadir for your chain
  6. Fetch snapshots (optional) — restore snapshots to speed up initial sync
  7. Run both clients — launch them in separate terminals; they communicate via JWT auth
Optional step 8 covers testing your node’s RPC endpoints.
For production deployments, consider docker images or community-maintained Ansible playbooks that deploy docker containers. For local experimentation with validator mechanics, see Local Devnet with Kurtosis.

Step 1 - Download scripts

Make an area to work in, then clone the Berachain node scripts. These scripts handle configuration, parameter fetching, and client startup.
If you’re a Unix traditionalist, use /opt/beranode as your working directory.
The file env.sh contains environment variables used in the other scripts. fetch-berachain-params.sh downloads consensus-layer configuration files. setup- and run- scripts start the execution client and beacond.

Step 2 - Configure environment

Edit env.sh to set your node’s configuration. Open the file and modify these values:
env.sh
You need to set these constants:
  1. CHAIN: Set to mainnet or bepolia.
  2. MONIKER_NAME: A name of your choice for your node.
  3. WALLET_ADDRESS_FEE_RECIPIENT: The address that receives priority fees for blocks sealed by your node. If your node will not be a validator, this won’t matter.
  4. EL_ARCHIVE_NODE: Set to true if you want the execution client to be a full archive node.
  5. MY_IP: Sets the IP address your chain clients advertise to other peers on the network. In a cloud environment such as AWS or GCP where you are behind a NAT gateway, you must specify this address or allow the default curl canhazip.com to auto-detect it.
You should verify these constants:
  • LOG_DIR: This directory stores log files.
  • BEACOND_BIN: Set this to the full path where you installed beacond. The expression provided finds it in your $PATH.
  • BEACOND_DATA: Set this to where the consensus data and config should be kept.
  • RETH_BIN: Set this to the full path where you installed bera-reth. The expression provided finds it in your $PATH.

Step 3 - Fetch parameters

The fetch-berachain-params.sh script downloads consensus-layer network parameters for the chain you configured:
Verify that the checksums for genesis.json and kzg-trusted-setup.json match the values above for your chosen network.

Step 4 - Set up BeaconKit

The script setup-beacond.sh invokes beacond init and beacond jwt generate. This script:
  1. Runs beacond init to create the file var/beacond/config/priv_validator_key.json. This contains your node’s private key. Especially if you intend to become a validator, keep this file safe. It cannot be regenerated, and losing it means you will not be able to participate in the consensus process.
  2. Runs beacond jwt generate to create the file jwt.hex. This contains a secret shared between the consensus client and execution client so they can securely communicate. If you suspect it has been leaked, delete it then generate a new one with beacond jwt generate -o $JWT_PATH.
  3. Rewrites the beacond configuration files to reflect settings chosen in env.sh.
  4. Places network parameters where BeaconKit expects them and shows you an important hash from the genesis file.
Your validator state root must agree with the value shown above for your chosen chain.

Step 5 - Set up the execution client

The setup-reth.sh script creates the Reth datadir and initializes it with --chain set to your configured network (mainnet or bepolia). Pruning follows the EL_ARCHIVE_NODE setting in env.sh.

Step 6 - Fetch snapshots (optional)

Restoring a snapshot is much faster than syncing from genesis. Do this before Step 7. Official Berachain snapshots are available for Mainnet and Bepolia. Full restore commands and documentation are available on Snapshots.

Step 7 - Run both clients

Launch two terminal windows. In the first, run the consensus client:
In the second, run the execution client:
Initially this will not appear to respond, but within a minute blocks should begin flowing. There should not be a significant number of error messages, except for occasional minor complaints about disconnecting or slow peers.
Both clients are running and will begin syncing with the network. The node will continue syncing in the background. You can proceed to the optional testing steps below, or leave the clients running to complete their sync.

Step 8 - Testing your node (optional)

Now that your RPC is running, verify that the network is working by performing a few RPC requests.
Make sure that your node is fully synced before proceeding with these steps.

Check sync status

To check the sync status of the consensus layer, in another terminal run the following to retrieve the current block height from the consensus client:
If catching_up is set to true, it is still syncing.

EL block number

CL block number

Next steps

Your node is now running and syncing. For production deployments, see: