bsc-geth client — BNB Chain’s fork of go-ethereum, listed under that name in the deploy wizard. On first start the node downloads the genesis, then bootstraps its chaindata from an official BSC snapshot so it doesn’t have to sync from genesis — after that it stays in sync on its own.
Pick BSC, a network, and a client version in the deploy wizard — it offers exactly the versions your executor supports (currently 1.7.3).
Networks and resources
chapel is the BSC testnet. Defaults are pre-filled in the deploy wizard; lower with caution. BSC mainnet is storage-heavy — provision the full disk before deploying.
Node types
Full and Pruned are both offered in the deploy wizard’s Node type selector.- Full keeps the complete recent state and is the default. On
mainnetit asks for 7 TiB. - Pruned trims historical state to cut disk — 3 TiB on
mainnet, 500 GiB onchapel— at the cost of not serving the full historical state. Pick it when you only need a current-state RPC node.
Ports
Ports are managed for you and aren’t user-overridable.
Config overrides
Novacula manages the network ID, sync mode, RPC/WS bindings, P2P, the data directory, and the metrics endpoint for you. These flags are rejected if you try to override them:--config, --datadir, --metrics, --metrics.addr, --metrics.port.
To tune bsc-geth, add command-line flags when you deploy — for example --cache=8192 or --txlookuplimit=0. Any flag outside the managed list above is passed straight through to the client. See Edit a running node for what can change afterwards.
Snapshot bootstrap
On the first deploy, the node downloads the genesis and then seeds its chaindata from an official BSC snapshot to cut sync time. The download surfaces as the Downloading snapshot state with live progress — see Node lifecycle. The platform checks the host has room for the resolved snapshot size before downloading, and if the snapshot bootstrap fails the node falls back to initializing from genesis. If the data directory already holds usable chaindata, the snapshot step is skipped.Metrics
Block height, sync progress, and peer count are collected automatically — see Node monitoring. BSC nodes also report client-side detail worth watching during a long initial sync and under load:
A rising throttle count or header timeouts alongside flat header intake usually points at peers rather than at the host.
bsc-geth 1.7.x advances its head and header block together during snap sync, which makes the Prometheus-derived sync ratio read as fully synced too early, so Novacula falls back to the client’s eth_syncing RPC to report an honest sync state.