Skip to main content

Run with Bazel

Run the beacon node and validator client straight from your checkout, so every code change is one command away from running. bazel run builds the target if needed, then starts it with the arguments you put after --.

Network

The flags are the same as for a normal install, so this page shows only what differs; see the Quickstart for the full walkthrough and Common flags and config file for the flags.

Before you begin​

Use a separate data directory

Without it--datadir, a development build uses the default data directory (~/.eth2 on Linux, ~/Library/Eth2 on macOS), the same one an installed Prysm uses. Always pass your own data directory so a test build can't change the database of a node you rely on.

Run a beacon node​

  1. Start the beacon node. Everything after -- goes to the binary:

    bazel run //cmd/beacon-chain -- \
    --mainnet \
    --accept-terms-of-use \
    --datadir=$HOME/prysm-dev/beacon \
    --execution-endpoint=http://localhost:8551 \
    --jwt-secret=$HOME/ethereum/jwt.hex \
    --checkpoint-sync-url=https://sync-mainnet.beaconcha.in \
    --genesis-beacon-api-url=https://sync-mainnet.beaconcha.in
  2. Watch the logs. Bazel first builds anything that changed, then the node starts:

    INFO db: Opening Bolt DB path=/home/<USER>/prysm-dev/beacon/beaconchaindata/beaconchain.db
    INFO httprest: Starting HTTP server address=127.0.0.1:3500
  3. Stop the node with Ctrl+C, change the code, and run the same command again. Bazel rebuilds only the packages you changed.

Use absolute paths

bazel run starts the binary inside Bazel's runfiles directory, not your shell's current directory. A relative path such as --datadir=./data ends up under bazel-bin. Use absolute paths, $HOME, or a leading ~/, which Prysm expands itself.

Long flag lists are easier to keep in a YAML file passed with --config-file (refer to the Use a config file page for the format). Flags on the command line override the same keys in the file:

bazel run //cmd/beacon-chain -- --config-file=$HOME/prysm-dev/beacon.yaml

Run a validator client​

Pick a testnet above. Never run a development build with mainnet keys.

Never run development builds with mainnet keys

A development build can contain bugs that make a validator sign conflicting messages. Use testnet keys that aren't active anywhere else, and never run the same keys in two validator clients at once. See Avoid slashing.

Run the built binary directly​

bazel run checks the build graph and holds the Bazel server while it builds. When you restart often without changing code, or want to run tests in another terminal, build once and run the output directly:

bazel build //cmd/beacon-chain
bazel-bin/cmd/beacon-chain/beacon-chain_/beacon-chain --config-file=$HOME/prysm-dev/beacon.yaml

Build options go before the target, as usual: bazel run --config=release //cmd/beacon-chain -- … runs an optimized build. See Build with Bazel for the configs.

Check that it works​

Ask the beacon node for its version and sync status:

curl -s http://127.0.0.1:3500/eth/v1/node/version
curl -s http://127.0.0.1:3500/eth/v1/node/syncing

The version starts with Prysm/, and is_syncing turns false once the node has caught up.