> ## Documentation Index
> Fetch the complete documentation index at: https://docs.novacula.io/llms.txt
> Use this file to discover all available pages before exploring further.

# BSC

> BNB Smart Chain (BSC `geth`) — networks, resource defaults, and config overrides

BSC nodes run a single `geth` client (BNB Chain's build). 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

| Network   | Chain ID | CPU      | RAM    | Disk (Full) | Disk (Pruned) |
| --------- | -------- | -------- | ------ | ----------- | ------------- |
| `mainnet` | 56       | 16 cores | 64 GiB | 7 TiB       | 3 TiB         |
| `chapel`  | 97       | 8 cores  | 32 GiB | 1 TiB       | 500 GiB       |

`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 `mainnet` it asks for **7 TiB**.
* **Pruned** trims historical state to cut disk — **3 TiB** on `mainnet`, **500 GiB** on `chapel` — at the cost of not serving the full historical state. Pick it when you only need a current-state RPC node.

Select the node type in the deploy wizard and the disk request is pre-filled accordingly.

## Ports

| Name                 | Port    | Notes                    |
| -------------------- | ------- | ------------------------ |
| JSON-RPC (HTTP)      | `8545`  | Consume this for RPC     |
| JSON-RPC (WebSocket) | `8546`  |                          |
| P2P                  | `30311` | Peer-to-peer (TCP + UDP) |
| Metrics              | `6060`  | Prometheus exporter      |

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 `geth`, add command-line flags — for example `--cache=8192` or `--txlookuplimit=0`. Any flag outside the managed list above is passed straight through to `geth`. See [Edit configuration](/docs/nodes/edit-configuration).

## 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](/docs/nodes/node-lifecycle#snapshot-bootstrap). 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](/docs/nodes/monitoring).

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.

## Provisioning

To stand up an executor that can run BSC, follow [Provision on bare metal](/recipes/provision-on-bare-metal) or [Provision on Kubernetes](/recipes/provision-on-kubernetes).