Installing Networks

Deploy blockchain networks on your local Obol Stack

The Obol Stack supports installing multiple blockchain networks on your local Kubernetes cluster. Each network installation creates a unique deployment with its own namespace, allowing you to run multiple instances simultaneously.

Available networks

View all available networks:

obol network list

Currently supported networks:

Network
Description

ethereum

Full Ethereum node (execution + consensus clients)

helios

Ethereum light client for RPC access

aztec

Aztec Layer 2 sequencer node

Network installation workflow

Installing a network follows a two-step process:

  1. Install - Generate configuration and save to disk

  2. Sync - Deploy the configuration to the cluster

This separation allows you to review and modify configuration before deployment.

Install command

obol network install <network> [flags]

This creates a deployment directory at ~/.config/obol/networks/<network>/<id>/ containing:

  • values.yaml - Configuration values (editable)

  • helmfile.yaml.gotmpl - Deployment definition

Sync command

This deploys the configuration to your Kubernetes cluster using Helmfile.

Delete command

This removes both the Kubernetes resources and local configuration.

Ethereum network

Deploy a full Ethereum node with configurable execution and consensus clients.

Configuration options

Flag
Description
Options
Default

--id

Deployment identifier

Any string

Auto-generated

--network

Ethereum network

mainnet, sepolia, hoodi

mainnet

--execution-client

Execution layer client

reth, geth, nethermind, besu, erigon, ethereumjs

reth

--consensus-client

Consensus layer client

lighthouse, prysm, teku, nimbus, lodestar, grandine

lighthouse

Examples

Deploy an Ethereum node on Hoodi testnet with default clients:

Check sync status

Monitor your Ethereum node sync progress:

Helios light client

Deploy a Helios Ethereum light client for fast RPC access without syncing a full node.

Configuration options

Flag
Description
Options
Default

--id

Deployment identifier

Any string

Auto-generated

--network

Ethereum network

mainnet

mainnet

--consensus-rpc

Consensus RPC endpoint

URL

Public endpoint

--execution-rpc

Execution RPC endpoint

URL

Public endpoint

Example

Helios provides a local RPC endpoint that verifies data against the consensus layer, giving you trustless Ethereum access without running a full node.

Aztec network

Deploy an Aztec Layer 2 sequencer node for the privacy-focused Ethereum rollup.

Configuration options

Flag
Description
Options
Default

--id

Deployment identifier

Any string

Auto-generated

--network

Aztec network

mainnet

mainnet

--attester-private-key

Attester private key (hex)

Required

None

--l1-execution-url

L1 execution RPC URL

URL

ERPC endpoint

--l1-consensus-url

L1 consensus RPC URL

URL

Public endpoint

Example

What this does:

  • Deploys an Aztec sequencer node in your local Kubernetes cluster.

  • Connects to Ethereum mainnet using the specified RPC endpoints.

  • Configures your node as an attester using the provided private key.

Default L1 RPC endpoints:

  • Execution Layer: https://geth-prysm-mainnet-1.gcp.obol.tech/ (Geth)

  • Consensus Layer: https://prysm-geth-mainnet-1.gcp.obol.tech/ (Prysm)

These are production-grade, publicly accessible Ethereum nodes provided by Obol.

You can use your own Ethereum node endpoints by changing the --l1-execution-url and --l1-consensus-url flags.

Deploy to the cluster:

Resource requirements

The Aztec sequencer requires significant resources:

Resource
Request
Limit

CPU

4 cores

8 cores

Memory

16 GB

32 GB

Storage

1 TB

-

Managing deployments

List installed networks

View configuration directories:

View deployment status

Check running deployments:

Modify configuration

Edit the values file before syncing:

Delete a deployment

Remove a network deployment:

This deletes:

  • Kubernetes namespace and all resources

  • Local configuration directory

  • Persistent volume claims (data)

Last updated

Was this helpful?