Which Besu node roles does a private network need before go-live?
A permissioned Besu network needs at least three kinds of node before go-live: validators that sign and propose blocks, RPC nodes that serve applications, and bootnodes that help peers find each other. Read-only nodes, which follow the chain without taking part in consensus, are optional but common for auditors, reporting or disaster recovery. Besu does not ship these as separate products. Each role is set by configuration on the same Apache 2.0 licensed client, and the LF Decentralized Trust Besu project page is the next read for the project's status as a Graduated project.
The reason to keep the roles separate is exposure and recovery. A validator holds the node key that signs blocks, so it should accept connections only from the network's own nodes and should never be the endpoint an application calls. RPC nodes are the opposite: they face applications and may need to be load balanced, so their JSON-RPC access controls and transport protection need planning. Bootnodes are reachable by peers during discovery and should not sit behind a load balancer. Before go-live, ask each organization to confirm which of its nodes are validators, which are bootnodes, and which are exposed to applications, and to document how each role would be replaced if its host failed.
Confirm two points with your Besu version and the validator documentation before you fix the topology. First, a validator can also act as a bootnode without extra configuration, so removing such a node later can leave too few bootnodes for peers to discover the network, and you should plan enough bootnodes to survive that removal. Second, read-only nodes can run on lower performance storage than validators and RPC nodes, which affects the hardware you budget for each role. Write these decisions into the network design record so that the validator set, bootnode list and RPC endpoints are reviewed together, not one by one.
Which role fits which job in a private Besu topology
This table compares validators, RPC nodes, bootnodes and read-only nodes on purpose, application exposure, storage tier, peer exposure and what breaks when each one is lost. Read each row across to decide which roles must be built and which can be added later. The main takeaway is that a validator can also serve as a bootnode, but the roles still differ in what they expose and how much storage they need.
| Role | Purpose and application exposure | Storage and exposure notes | What breaks if the node is lost |
|---|---|---|---|
| Validator | Proposes and votes on blocks. Keep private, with no application traffic reaching it directly. | Needs the higher-performance storage tier. Holds the node key that identifies it to the network. | Consensus weakens. Losing enough validators to drop below quorum halts block production. |
| RPC node | Serves JSON-RPC and WebSocket requests from applications. This is the node class that faces applications, usually behind a controlled gateway. | Needs the higher-performance storage tier, sized for query load as well as sync. Expose only authenticated endpoints. | Applications lose access to that endpoint. Other synchronized RPC nodes can keep serving if clients fail over. |
| Bootnode | Helps new and restarting nodes find peers. Keep private and reachable only by known participants. | Light workload. Validators can act as bootnodes without extra configuration, so a separate bootnode is optional. | New or restarted nodes may struggle to find peers. Enough bootnodes must remain if one is removed. |
| Read-only node | Syncs chain data without taking part in consensus. Used for analytics, reporting or archive-style reads. | Can use lower-performance storage than validators and RPC nodes, according to Besu system requirements documentation. | Reporting or analytics pipelines lose a data source. Consensus and applications are unaffected. |
| Bootnode behind a load balancer | Not recommended. Bootnodes should be addressed directly so peers can reach known endpoints. | Keep the address stable and reachable by known participants only. | Load balancer routing errors can break peer discovery for nodes that depend on the bootnode address. |
| Application-facing endpoint | Created by placing synchronized RPC nodes behind a load balancer for high availability. | Confirm the load balancer design with your network team and Besu high availability guidance. | Client connections drop if the balancer or its health checks fail. |
| Private key custody | Validator and node keys identify each role on the network. Confirm where each key file is stored for every node. | Besu documentation states the node private key file is not encrypted, so plan protection by role. | A compromised validator key can impersonate a validator. Confirm rotation and HSM options with your security team. |
Why validators can also act as bootnodes, and when to split them
In Besu, a validator can also serve as a bootnode without any extra configuration, which is why many small private networks start with that arrangement. The cost shows up later. Bootnodes are the entry points that new and restarting nodes use to find the rest of the network, so every bootnode you remove is a discovery path you lose. If a validator that doubles as a bootnode is retired or rotated out, enough other bootnodes must still be running and reachable to keep peer discovery working. Before any validator change, confirm which enodes are listed as bootnodes in each node's configuration and check that the remaining set is sufficient, following the guidance in the Besu validators documentation.
The trade-off is between simplicity and resilience. In a small network with a fixed validator set, combining the roles keeps the topology easy to read and the number of machines low, and it is a sound choice when membership changes are rare and well planned. Once validators rotate, or when several organizations each run their own nodes, coupling bootnode duties to validator membership makes peer discovery depend on the governance of the validator set. A separate, always-on bootnode owned by the operator who keeps the network reachable lets validators come and go without touching the discovery path. Because bootnodes should not sit behind a load balancer, a split also means deciding how each bootnode is addressed and kept stable.
Splitting roles is a decision to make before go-live, not after. Ask who owns each bootnode, how its enode will stay stable through host replacements, and how new bootnodes will be added without restarting the network. Those questions connect to the bootnode and static node topic and to the validator count decision, which determines how much failure tolerance the validator set already provides. Write the chosen arrangement into your network runbook and rehearse removing one validator-bootnode in a non-production network so the procedure is proven before it is needed.
How to build the role layout step by step
This sequence turns a list of organizations and workloads into a tested Besu topology where validators seal blocks, bootnodes stay reachable, and RPC and read-only nodes serve applications and reporting without touching consensus.
Confirm the validator set and its owners
Agree in writing which organization runs each validator, how many validators the network starts with, and who approves changes to the set. Each validator should have a named operator, a documented key custody method and a clear path for replacing the node. Done means every validator has an owner, a host and a key record that the consortium has signed off. Ask your Besu contact to confirm how the initial validator addresses are recorded in the genesis configuration, since that choice is hard to reverse later.
Decide bootnode placement across operators
Choose which nodes act as bootnodes and where they run. Besu allows validators to double as bootnodes without extra configuration, but removing one that is also a bootnode requires enough bootnodes to remain. Spread bootnodes across operators and failure domains, and keep them reachable on a stable address. Besu's high availability guidance does not recommend placing bootnodes behind a load balancer, so give each bootnode its own reachable endpoint. Done means you have a written list of bootnode enodes, their hosts and the replacement procedure.
Size the RPC tier for application load
Estimate the read and write traffic from your applications, then decide how many RPC nodes you need. For JSON-RPC and WebSocket high availability, run more than one synchronized node behind a load balancer. Keep RPC nodes off the validator hosts so API load cannot slow block production. Measure request rates and resource use in a dev environment before buying hardware. Done means the RPC count, the load balancer design and the per-node resource targets are recorded, and each RPC node is confirmed to be syncing to the same head as the validators.
Plan read-only nodes for reporting
Add read-only nodes for analytics, reconciliation and audit queries that do not need to submit transactions. Besu's system requirements indicate read-only nodes can use lower performance storage than validators and RPC nodes, which makes them a cost-effective place for heavy reporting. Keep them off the path of application writes, and decide which teams can reach them. Done means each reporting consumer is mapped to a read-only node and the storage tier for each is set in your hardware plan.
Set node and account permissions
Configure the permissions file on each node so it only accepts connections from known participants, and set account permissioning rules according to your onboarding process. Apply the same policy across all operators, because each node enforces its own rules locally. Restrict which nodes can expose JSON-RPC, and confirm that RPC endpoints require authentication before they face applications. Done means each node's permissions file is version controlled, matches the agreed allowlist, and a test connection from an unlisted node is refused.
Verify peering on every role
Start the bootnodes first, then validators, RPC nodes and read-only nodes. Confirm each enode resolves from the others, that peer counts match the expected topology, and that no node is connected to a peer that should be blocked. Check the logs and metrics that show peer connections. Done means every node reports the expected peers, and a restart of one bootnode does not break connectivity for the rest of the network.
Verify block production and RPC sync
Confirm that validators are sealing blocks in the agreed rotation and that the chain head advances on every validator. Then check that each RPC and read-only node is in sync with the validators and returns the same block height and state for a sample query. Stop one validator in a test environment and confirm the network behaves as your validator count predicts. Done means the head advances, RPC nodes match the validators, and the result of the failure test is written down for the go-live record.
Which nodes face applications and which stay private
In a private Besu topology, each node role has a different exposure level. Validators stay off application and public paths, RPC nodes carry all application traffic, and bootnodes serve only peer discovery. Read-only nodes give analytics a copy of the chain without touching consensus.
Keep validators off application networks
Validators sign and propose blocks, so their JSON-RPC and peer ports should be reachable only from other validators and the bootnodes that serve them. Place them on a segment with no route from application subnets, and confirm that no load balancer, gateway or monitoring job points at a validator's API port. Review firewall rules after every topology change, because a convenient RPC endpoint on a validator is the most common way it gets exposed.
RPC nodes as the application entry point
RPC nodes are the only nodes that applications, wallets and integration services should call. Run more than one synchronized RPC node behind a load balancer when you need high availability for JSON-RPC or WebSocket traffic. Each RPC node also needs enough storage and CPU to serve query load, so size them for read traffic rather than treating them as spare validators.
Bootnodes reachable by peers only
Bootnodes help new and restarting nodes find the network, so they must be reachable from other Besu nodes but never from application networks. Besu does not recommend placing bootnodes behind a load balancer. Confirm that enough bootnodes remain after any single removal, because a validator that doubles as a bootnode takes that role with it when it is retired.
Read-only nodes for analytics
Read-only nodes follow the chain and serve data to analytics, reporting and audit consumers without taking part in consensus. The Besu system requirements allow them a lower performance storage setup than validators and RPC nodes. Keep them on a separate network path from validators, and confirm which query patterns they must serve before choosing their disk and memory.
Authenticate every JSON-RPC request
Enable JSON-RPC authentication on every node that accepts API calls. Besu supports a username and password credentials file, or JWTs validated against a public key using RS256, RS384, RS512, ES256, ES384 or ES512. Decide which identity provider issues the tokens, who rotates the public key, and how credentials files are stored and distributed before go-live.
Terminate HTTPS outside Besu
Besu does not terminate HTTPS natively, so TLS must be handled by a reverse proxy or API gateway placed in front of each RPC node. That component owns certificates, cipher policy, client certificate checks if used, and request logging. Confirm that nothing reaches the Besu HTTP port without passing through it, and test that the proxy forwards authentication headers as the node expects.
What each role needs in storage and networking
Validators and RPC nodes sit on the higher-performance storage tier, while read-only nodes can run on a lower-performance setup, according to Besu's system requirements for private networks. That split is the first decision to make per role. A validator that falls behind on block import or an RPC node that serves slow reads will show up as application latency or missed block production, so the disk you give a validator is not interchangeable with the disk you give an archive-style reader. Confirm the current storage guidance against the system requirements page for the exact Besu release you plan to deploy, since those requirements change between releases.
Network paths fall into three groups, and each needs its own rule. Validator-to-validator traffic carries consensus messages and must stay reachable among all validators at all times, so it belongs on a private segment with firewall rules that allow only the peer ports your validators use. RPC-to-application traffic is the only path your business applications should reach, and it should terminate behind a load balancer or gateway you control, since Besu does not terminate HTTPS natively. Bootnode reachability is the path new and restarting nodes use to find peers. Keep bootnodes off the load balancer, because Besu's high availability guidance does not recommend that placement, and make sure each bootnode is reachable from every network segment where nodes will join.
Before go-live, map each path to a firewall rule, a monitoring check and an owner, then test a node restart from each segment. Ask your team to confirm which ports the RPC and peer-to-peer listeners use in your Besu release, and whether any validator or bootnode will sit in a different cloud account, data center or closed network, because that changes the route and the failure modes you need to rehearse. Sizing figures for CPU, memory and disk belong to the node sizing guidance, so use this section to decide placement and reachability, then size each role separately.
Questions teams ask before designing Besu node roles
Can an RPC node also be a validator in a Besu network?
Technically a validator can also serve JSON-RPC, but most teams keep the two roles on separate nodes. Validators sign and propose blocks, and application traffic on the RPC endpoint competes with that work for CPU, memory and disk. Separating them lets you expose RPC endpoints to applications, scale or replace them, and restrict their settings without touching the validator. Besu documents that validators can also act as bootnodes without extra configuration, so role overlap is possible, but the trade-off for RPC should be decided on load and exposure, then confirmed with a test in your environment. Ask your engineering team to document the decision per node.
How many RPC nodes does high availability need?
High availability for JSON-RPC and WebSocket access requires more than one node behind a load balancer, and the nodes must stay synchronized with the chain. Two RPC nodes is the minimum that removes a single point of failure, but the right count depends on application load, the number of client applications and how quickly you need failover. Confirm the sizing with load tests against your own workloads. If one node falls behind, applications can read stale state or submit transactions that are later dropped, so monitor block height on every RPC node from the start.
Can bootnodes sit behind a load balancer?
No. Besu guidance does not recommend placing bootnodes behind a load balancer. Bootnodes are how other nodes find peers when they start, and their identity and address need to be stable and reachable directly. Load balancers add an intermediate hop that can change addresses, hide the real peer identity and complicate failover. Instead, run several bootnodes with fixed addresses in separate failure domains, and keep the list of bootnodes in each node's configuration so the network still has an entry point when one fails.
How much effort does a Besu role layout take, and what drives it?
Effort depends on how many organizations share the network, how many applications read or write through RPC, what reporting needs exist, and how many security zones the nodes must span. A single-organization network with one application is a smaller exercise than a consortium with separate reporting nodes and a private zone for validators. Each additional organization adds ownership, key handling and access agreements. Ask any partner for a fixed scope that lists the node count, environments, network paths and handover items, then compare quotes against that same list rather than against a headline number.
Can our team set up the node roles ourselves?
Yes, if your engineers have operated Linux servers, container or Kubernetes platforms, TLS-terminating load balancers and Prometheus-based monitoring, and they have time to rehearse failures. The hard parts are not the first start but the ongoing discipline: keeping peer lists consistent, rotating keys, testing failover and planning upgrades so that all nodes move in step. Many teams split the work, keeping the design and day-two operations in-house while using a partner for an initial review, hardening or a documented build. Decide which part your team will own before the build starts.
What do you need from us to design the node roles?
Prepare a network diagram that shows each organization, planned validator, RPC, bootnode and read-only node, and the zones they sit in. Provide an IP address and DNS plan with ranges for each environment, firewall and proxy rules you already enforce, and a named owner for every node, including who can change its configuration and who responds to alerts. You will also need the list of applications that will call RPC endpoints, expected traffic patterns and any reporting systems that read from the chain. Missing owners are the most common gap, so confirm them early.
How do role changes affect a running network?
Changing a role on a running network is a controlled operation, not a configuration edit. Adding a bootnode or RPC node is generally lower risk, but removing a validator that is also a bootnode can leave too few bootnodes for peers to find the network, so the remaining set must be confirmed first. Moving a validator, changing its key or altering the validator set may require a coordinated transition across all operators. Plan each change in a dev cluster, record the rollback path and confirm the current Besu release notes for any behavior that affects upgrades or backup before you touch production.
Security and operational risks in node role design
Each Besu role carries different exposure. Validators hold signing keys, RPC nodes face applications and metrics endpoints reveal node internals, and upgrades can change the database in ways older versions cannot reverse. The cards below set out the controls to decide before go-live.
Unencrypted validator key files
The local node private key file that a validator uses is not encrypted by Besu. Anyone who can read that file on the host can take the validator identity. Decide before go-live where the key lives, who can read it, and whether the validator needs hardware-backed storage through the security module plugin option, --security-module, provided by the Besu HSM plugin. Confirm the plugin's support status for your Besu version with the maintainers before you plan around it.
Metrics endpoint exposure
Besu can expose Prometheus metrics with --metrics-enabled, and the default endpoint port is 9545. Metrics reveal peer counts, sync state and block production, which is useful to an attacker mapping your topology. Keep the metrics port on an internal monitoring network, allow only your Prometheus servers to reach it, and do not publish it through the same load balancer that serves application traffic.
RPC authentication and segmentation
Only RPC nodes should face applications, and Besu supports username and password credentials or JWTs validated against a public key. Besu does not terminate HTTPS natively, so a reverse proxy or gateway must handle TLS and enforce who can call which methods. Keep validators off the application network, and confirm that the authentication design and network paths meet your own access policy before go-live.
Rollback needs a pre-upgrade backup
The Bonsai database upgrades automatically on first start, and older Besu versions cannot open an upgraded database. A failed upgrade on a validator or RPC node therefore cannot be undone by installing the previous binary alone. Take and verify a backup of node data before each upgrade, and rehearse the restore in a non-production environment so the recovery steps are known before they are needed.
Monitoring each role separately
A validator, an RPC node and a bootnode fail in different ways, so one shared dashboard hides the signal you need. Track validator participation and block production for validators, request latency and sync lag for RPC nodes, and peer connectivity for bootnodes. Build separate Prometheus alert rules per role and confirm which alerts page an on-call engineer from day one.
How DeployOpen scopes and delivers Besu node topology
DeployOpen plans, builds and hands over the node topology of a permissioned Besu network inside infrastructure you control. Each validator, RPC, bootnode and read-only role is scoped in writing, deployed, tested and documented so your team can operate it after handover.
How we scope
- Map which organization owns each validator, bootnode and RPC node before any build starts
- Record storage, networking and exposure requirements for every node role in the written scope
- Confirm which RPC endpoints face applications and which stay on private networks
- Agree in writing how many bootnodes and validators must remain available during failures
How we build
- Deploy validators, RPC nodes, bootnodes and read-only nodes with separate storage and network profiles
- Keep validator and bootnode placement isolated from application traffic and load balancers
- Configure JSON-RPC authentication and HTTPS termination at the layer you operate
- Test peer discovery, failover of a single validator and RPC node behavior before go-live
How we hand over
- Deliver a topology document listing each node role, its owner, network path and storage class
- Store node configuration under source control with change records for each role
- Run a handover session where your operators restart, replace and monitor each node type
- Provide monitoring dashboards for each role with Prometheus metrics and alerting rules
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing first
- Ongoing support, upgrades and topology changes are available as a retainer
- Review topology changes for each Besu release before your operators apply them
- Quotes follow from the written scope, and we confirm the support model with you before work starts
