Join the network

The simplest way to join is to run a follower. It downloads and verifies the history you choose, keeps it current, and serves it from your machine. Running a follower also strengthens the network by increasing replication of blob data and adding to the swarm's bandwidth.

Run a follower

You do not need another Ethereum node. Choose a chain-specific profile for your L2, or follow the all profile for every historical blob.

# Release source archive: compose file and starter config.
curl -fsSL -o bloar-v0.1.0.tar.gz \
  https://github.com/blobarchive/bloar/archive/refs/tags/v0.1.0.tar.gz
tar xzf bloar-v0.1.0.tar.gz
cd bloar-0.1.0/deploy/quickstart/follower

# Small text file naming the image digest, not the image itself.
curl -fsSL -O \
  https://github.com/blobarchive/bloar/releases/download/v0.1.0/bloar-v0.1.0-image.env
set -a
. ./bloar-v0.1.0-image.env
set +a

# Data dir and API token, owned by the container's user 65532.
sudo install -d -m 0750 -o 65532 -g 65532 data
sudo install -m 0400 -o 65532 -g 65532 /dev/null token
openssl rand -base64 32 | sudo tee token >/dev/null

docker compose pull
docker compose up -d

Point your L2 node at http://127.0.0.1:8550/live, then choose the profile you want in bloard.yaml: a chain-specific archive or the full archive. The L2 operator guide covers profile selection, trust, monitoring, and production integration.

TCP 4001 is published by default. We strongly recommend allowing it through the host firewall and forwarding it through your router so other nodes can connect directly. See the follower guide for configuration, updates, and troubleshooting; add the monitoring and alerting checks before production; or read how discovery and transfer work.

Other ways to join

Use an existing IPFS node

A Kubo replica attaches BlobArchive to an existing IPFS node instead of creating another block store or swarm identity. Read the Kubo replica guide and its monitoring table.

Publish an independent archive

Writers derive blob history from their own Ethereum inputs and publish signed heads. Public deployments keep the signer and mutable archive private behind a separate read-only edge. Read the independent writer FAQ and writer monitoring table.

Follower requirements

• OS / arch: Linux on amd64 (container images; static Go binaries, no cgo). Other platforms may build from source but are untested.
• Storage: the full archive is around ≈2.8 TB today. A chain-filtered head or a windowed retention policy is a small fraction of that. SSD strongly recommended for the blockstore for now.
• Memory: 4 GB comfortable. The daemon idles around ~120 MB; verification and sync bursts use more.
• CPU: any modern multi-core. Initial sync KZG-verifies every blob on the way in, which is CPU-bursty; steady-state is light.
• Network: forwarding the swarm TCP port is strongly recommended for reliable inbound peers and bulk archive transfer. Initial sync downloads your selected head; steady-state traffic follows chain pace.
• Expect reconnects. Sync resumes where it left off; a disconnect does not restart the archive download.

Questions before you commit hardware? Ask on Discussions.