Hyperledger Besu private network production readiness checklist: what must be true before go-live
This section gives a team or consortium about to launch a permissioned Besu network a go-live gate: the conditions that should be true before any production transaction or customer-facing dependency goes live. The checklist covers validator and bootnode counts, configuration kept under source control, upgrades rehearsed in a dev cluster, monitoring running from day one, secured JSON-RPC access and downgrade protection. It matters because many of the costly failures on a private chain are decided before launch, when the genesis file, node roles and key handling are still easy to change, and become expensive to correct once several organizations depend on the network.
Besu is an open source Ethereum execution client written in Java and licensed under Apache 2.0. For private networks it supports proof-of-authority consensus through QBFT or IBFT 2.0, and the project ships calendar releases roughly monthly. Recent releases require JDK 25 to build and run, so the runtime image, build pipeline and any internal patching process must be confirmed against the release you intend to deploy. Removed features matter too: Tessera privacy, onchain permissioning, proof of work and fast sync have been sunset, and Clique is no longer supported, so a checklist should start by confirming the consensus and feature set of the chosen version rather than inherited examples from older guides.
Treat this checklist as a planning aid, not an audit, attestation or certification. It helps you record evidence for each gate, name an owner and decide whether the risk is accepted. Independent auditors and certification bodies decide whether your controls meet a given requirement, and a passed checklist does not replace their work. Each item below should be answered for your own environment, with the exact Besu version, your validator set and your governance agreement written down, so that the go-live decision is traceable to specific settings rather than to general confidence.
Which checks a private Besu network needs before production traffic
This sequence moves a permissioned Besu network from paper design to a monitored, rehearsed deployment, with a named check that closes each step before any production traffic reaches it.
Plan the network on paper first
The network architect, with input from each participating organization, writes down the validator set, bootnode placement, RPC node roles, connectivity paths, expected transaction throughput and the genesis settings that will be hard to change later. Besu's Kubernetes production guide recommends planning the network on paper before any cluster is built. The step is complete when the team has a signed-off topology document that names every node, its role, its owner and the network paths between them, and when each open question has a named owner. Confirm with the Besu documentation which genesis parameters are fixed after launch before the plan is approved.
Confirm validator and bootnode counts
The architect and the governance group check the planned validator count against the number of faulty validators the consortium agrees the network must survive. Bootnode count and placement are checked against the same availability goal, so that peer discovery does not depend on one node. The check closes when a written table maps each proposed validator count to the failures it tolerates and the bootnodes are listed with owners in different failure domains. Confirm the QBFT fault-tolerance arithmetic against the Besu documentation rather than assuming it.
Put all configuration under source control
The platform engineering team stores every Besu configuration file, genesis file, permissions file, static node list, Kubernetes manifest and secret reference in a version-controlled repository with reviewed changes. Secret values stay in a secrets manager, not in the repository. The check passes when a clean checkout can rebuild a node from scratch, a reviewer can see who changed each setting, and no node runs a configuration that is missing from the repository. Ask each organization to confirm that its node configuration is in the same review process.
Rehearse provisioning and node updates in a dev cluster
The platform team builds the full topology in a development cluster and tests connectivity and throughput there, as the Besu Kubernetes production guide recommends. The rehearsal covers provisioning, peer connections between nodes, load under the expected transaction volume and a complete node update from the old version to the new one. The step closes when the team has a written run record showing that every node reached the expected peer count, that the throughput test met the target set in step one, and that a rollback from the update was performed and recorded.
Test the backup and rollback path
Before any node is upgraded in a rehearsal or production, the operations team takes a backup of the node data and confirms it can be restored. The Besu 26.10.0 release notes state that the Bonsai database upgrades automatically on first start and that older versions cannot open an upgraded database, so rollback depends on that backup. Setting --version-compatibility-protection to true protects against starting an older version over a database it could corrupt. The check passes when a restore has been performed in the dev cluster and the flag is set in every node configuration.
Confirm monitoring and alerting from day one
The operations team enables Besu metrics for Prometheus and connects dashboards and alert rules before the first block is produced. The Besu Kubernetes production guide recommends setting up monitoring and alerting from the beginning. Metrics are enabled with --metrics-enabled, and the default endpoint port is 9545. The check closes when every validator and bootnode is scraped, alerts fire in a test, and the on-call team has received and acknowledged a test alert. Ask the vendor or your monitoring team to confirm which alerts matter for quorum loss and peer count drops.
Sign off the go-live decision
The governance group reviews the evidence from each earlier step: the signed topology, the validator table, the configuration repository, the dev cluster run record, the restore test and the monitoring test. Each organization confirms in writing that its nodes match the agreed configuration. The step is complete when the group records a go or no-go decision with named approvers, and any open risk has an owner and a date set by that group.
Configuration decisions to fix before go-live and when each fits
This table compares the configuration choices a production checklist forces before a permissioned Besu network goes live. Read each row for when the option fits and what it costs in operations or flexibility. The main takeaway is that most of these choices are hard to reverse once nodes and data exist, so settle them on paper and rehearse them in a dev cluster first.
| Decision | When it fits | Trade-off to accept |
|---|---|---|
| Validator count and consensus (QBFT) | Consortium networks that need validator management options and a current consensus protocol for a new build | Each validator adds operational load and key handling, and the network stops producing blocks below quorum |
| Bootnode layout | Private networks that need stable entry points for peers joining or reconnecting after restarts | Bootnodes become shared dependencies, so their enodes, hosting and access need an owner and a change process |
| Node permissioning (local permissions file) | Networks that must restrict connections to known participants, with each node enforcing its own allowlist | Every node's file must be kept consistent across operators, and mismatches cause peers to silently fail to connect |
| Account permissioning (local permissions file) | Networks that need onboarding rules, account suspension or restricted actions without relying on onchain contracts | Onchain permissioning was removed from Besu, so changes depend on file distribution and node restarts |
| JSON-RPC authentication with a credentials file | Internal tooling and operators that need simple username and password access to a node | Credentials sit in a file on the host, and Besu does not terminate HTTPS, so transport protection must come from outside the node |
| JSON-RPC authentication with JWTs | Organizations that already issue tokens from an identity provider and want per-caller validation | The public key and accepted algorithms (RS256 to RS512, ES256 to ES512) must be managed, rotated and tested |
| Plain node key file | Dev and test clusters, or environments where no hardware security module is available | The local node private key file is not encrypted, so host access controls and file permissions carry the full risk |
| Security module plugin (for example, the Besu HSM plugin) | Production networks where regulators or internal policy require hardware-backed key storage | Adds a plugin to build, version, test and upgrade alongside Besu, and an HSM dependency in the recovery plan |
| Version compatibility protection (--version-compatibility-protection true) | Every production node, so an older binary cannot start on a database written by a newer version | Blocks downgrades without a restore, so rollback depends on a backup taken before each upgrade |
Why rehearsed upgrades and downgrade protection belong in the go-live gate
Upgrades on a Besu network are routine, but they are not reversible without preparation, so the go-live gate should require a rehearsed upgrade and a tested rollback path before the first block is produced. Besu uses calendar version numbers and ships roughly monthly. The GitHub releases page lists 26.7.0, 26.8.0, 26.9.0 and 26.10.0 in sequence, so a network that goes live on one release will face several upgrade decisions within a few months. Recent releases have also removed features that some teams may have built around, including Tessera privacy, onchain permissioning, the EEA and PRIV privacy RPC API groups, and Clique consensus. Each removal is a change that can break a configuration or an application, and the team should check each removal against its own deployment before choosing a target release.
The rollback risk comes from the database. The Besu 26.10.0 release notes state that the Bonsai database upgrades automatically on first start, and that older Besu versions cannot open an upgraded database. In practice, a node that has started on a newer release cannot be returned to an older binary by simply swapping the image back. The only rollback path is a backup taken before the upgrade, so the go-live gate should confirm that backup and restore are scripted, that the restore has been run on a copy of the data, and that someone other than the author can execute it under time pressure. Confirm the backup procedure against the current Besu backup documentation before you rely on it.
The --version-compatibility-protection option is the guard against the most damaging mistake, which is starting a binary older than the one that last wrote the database. Setting it to true makes Besu refuse to start in that situation instead of risking corruption. Enable it in the production configuration under source control, and test that a deliberately older binary is refused in the dev cluster. The full sequence, from provisioning through node updates and a rollback drill, should be rehearsed there first, because connectivity, throughput and the upgrade steps only behave the same way once the process has been run end to end. Ask any partner to show the rehearsal record as part of the readiness evidence.
Monitoring from day one and securing RPC before launch
Monitoring and RPC access are the two areas a production Besu network can least afford to improvise at launch. The cards below cover what to enable for metrics, how to alert on health signals, how JSON-RPC is authenticated, how TLS must be provided outside the node, and how node keys are stored. Each item should be decided and tested in the dev cluster before the production network accepts traffic.
Enable Prometheus metrics at node start
Besu exposes metrics for Prometheus when the --metrics-enabled option is set, on a default endpoint port of 9545. Decide before go-live which nodes expose metrics, whether the endpoint is reachable only from your monitoring network, and whether any node needs to push to a Prometheus push gateway instead of being scraped. Confirm that scrape targets for every validator and RPC node exist in the dev cluster, so gaps are found before production traffic depends on them.
Import the sample Grafana dashboard
Besu documents a sample Grafana dashboard built on its Prometheus metrics. Use it as a starting point, then review each panel against the signals your operations team will act on. Keep the dashboard under source control with the rest of the node configuration, so changes to panels are reviewed like any other change and survive a rebuild of the monitoring stack.
Alert on peer count and block production
Two alerts matter most on a permissioned network: a drop in peer count below what your topology requires, and a stall in block production or import on a validator. Set thresholds from the peer and validator counts in your own design, not from defaults. Route both alerts to a team that can act at night, and test them by stopping a node in the dev cluster and confirming the alert fires and clears.
Choose a JSON-RPC authentication method
Besu supports two JSON-RPC authentication methods: a username and password credentials file, or JWTs issued by an external identity provider and validated against a public key using supported RS and ES algorithms. Choose the method that matches how your applications already authenticate, and confirm which RPC namespaces each caller may use. Document who holds the credentials file or signing key, and how a compromised credential is rotated.
Plan HTTPS outside the node
Besu does not terminate HTTPS natively, so TLS for RPC and any other API must be provided by a reverse proxy, load balancer or equivalent component in front of the node. Decide where certificates are issued and renewed, which hop is encrypted, and whether traffic between the proxy and the node stays on a private network. Test the full path, including authentication headers, in the dev cluster before application teams are pointed at it.
Protect the unencrypted node key file
The local node private key file is not encrypted. Anyone who can read it can impersonate that node, so file permissions, backup handling and access to the host or container image must be controlled from day one. Where policy requires hardware-backed keys, plan for a security module plugin with the --security-module option, and confirm with your security team whether validator keys need the same treatment.
Questions teams ask before going live on Besu
How much effort does a Besu production readiness review take, and what drives it?
The effort depends mainly on how many nodes the network has, how many organizations operate them, and how mature your existing monitoring and Kubernetes practices are. A single-organization network with validators already built as code and dashboards in place needs far less review than a consortium where each member runs its own nodes, keys and alert routing. Ask any provider for a written scope that lists the node roles covered, the environments reviewed, the number of organizations involved, and which deliverables you receive. No effort figure is given here because the right number depends on your topology, and you should confirm it against your own environment before agreeing a plan.
Can our internal team run the Besu readiness checklist alone?
Often yes, if the team already operates Ethereum-style nodes, Kubernetes and a Prometheus stack, and has someone who owns the genesis and validator decisions. The gaps usually appear in areas that are easy to overlook: keeping configuration under source control, rehearsing an upgrade end to end in a dev cluster, confirming that version-compatibility protection is set, and securing JSON-RPC access. Be honest about whether those skills exist in-house today. A useful self-check is to ask whether you could restore a node from backup and roll it back to the previous version without outside help.
What do we need to provide for a readiness engagement?
Expect to provide access and decisions, not just time. The usual inputs are:
- Non-production environments, such as a dev cluster with enough capacity to run the full network shape
- Read access to your Kubernetes, cloud or data center accounts, monitoring and the source repositories that hold node configuration
- Named decision owners for genesis settings, validator ownership, bootnode placement, key custody and alert routing
- Written agreement on which compliance or security requirements the review must map to
Agree in advance who signs off each decision, because unresolved ownership is the most common reason reviews stall.
How long do rehearsals take, and why does it depend on our environment?
Rehearsal length depends on how closely your dev cluster matches production, how automated your provisioning is, and how many node roles you need to exercise. Besu's Kubernetes production guide recommends testing connectivity and throughput in a dev cluster, then testing the whole process from provisioning to node updates before production. Teams with infrastructure as code can repeat those steps quickly, while teams that provision by hand need more time per cycle. Ask for a rehearsal plan that lists each upgrade path, rollback path and failure you will test, and confirm the duration against your own environment rather than a generic figure.
What is one-time work and what recurs after go-live?
The readiness review and initial hardening are one-time work: designing the topology, setting up configuration under source control, securing RPC, configuring monitoring and rehearsing the first upgrade. Recurring work continues for as long as the network runs. Besu ships roughly monthly calendar releases, so each upgrade needs review, rehearsal and coordination across operators. Monitoring, alert tuning, backup verification and key rotation also repeat. Ask any provider to separate these two categories in the quote, and to state whether ongoing upgrades and monitoring are covered by a retainer or by separate work.
Does DeployOpen certify that our Besu network is production ready?
No. DeployOpen does not issue audit reports, attestations or certifications. It plans, implements, hardens, documents and prepares systems, controls and evidence for compliance assessments that independent auditors and certification bodies perform. A readiness review gives you a documented checklist, configuration in source control, rehearsal results and monitoring in place, which are the inputs an assessor would examine. Confirm with your auditor or regulator which evidence they expect, since their requirements decide what counts as sufficient.
Which Besu version and release rules should we confirm before the review?
Confirm the Besu version you will run, the JDK it requires and your upgrade cadence before the review starts. Besu 26.6.0 release notes state that Besu requires JDK 25 to build and run, and the project uses calendar version numbers with roughly monthly releases. Check the releases page for the current list and read the release notes for any removed features, since Clique consensus, Tessera privacy and onchain permissioning are no longer available in recent versions. A review that does not account for removed features can leave you with a network that cannot be upgraded.
Limits to confirm in your own environment before launch
These are the points where a launch plan can rest on an assumption that the vendor docs, release notes or your own environment may not support. Each one needs a check against the Besu version you intend to pin, the hardware and proxies you intend to run, and the features your network depends on. Confirm them in writing before the go-live date is set.
JDK 25 for your pinned version
The Besu 26.6.0 release notes state that Besu requires JDK 25 to build and run. Confirm that the Besu release you pin supports the JDK your build pipeline, container base images and hardened hosts provide, and that your change process covers JDK patching as well as Besu patching. Treat a JDK change as a release event that needs the same dev cluster rehearsal as a Besu upgrade.
Release cadence and support window
Besu ships calendar versions roughly monthly, so a pinned version falls behind quickly. Ask your team to define how long your network will stay on one release, who reviews each release, and how quickly a security fix must reach production. Confirm the maintainers' support policy for older releases with the project directly, because the docs we rely on do not set one out for you.
HSM support for your key type
The node private key file is not encrypted by default, and the security module plugin path relies on the Besu HSM plugin and the --security-module option. Confirm with your HSM vendor and the plugin's documentation that your device supports the curve and signing operations your nodes use, and that it works with the Besu version you pin. Test a validator restart against the HSM in the dev cluster before relying on it.
Proxy and load balancer behavior for JSON-RPC
Besu does not terminate HTTPS natively, so TLS, routing and any authentication happen in front of it or in Besu's own JSON-RPC settings. Confirm that your proxy or load balancer forwards JSON-RPC POST bodies, the Authorization header and WebSocket upgrades as your applications expect, and that it does not cache or retry transactions. Check how it behaves when one RPC node is removed from the pool mid-transaction.
Dev cluster storage and networking
The Kubernetes production guide recommends testing connectivity and throughput in a dev cluster before production. Confirm that the dev cluster uses the same storage class, disk type, network policies and node count as production, because a rehearsal on different storage can hide sync and I/O problems. Record the peer connectivity and block production results so you can compare them against production after go-live.
Removed features your design depends on
Tessera privacy, onchain permissioning, proof of work, fast sync and Clique are no longer supported in current Besu releases, and the privacy and EEA/PRIV RPC API groups were removed in 25.7.0. If your design needs private transactions or smart-contract permissioning, confirm which plugin, fork or alternative supports that need, who maintains it, and whether it works with the Besu version you plan to run. Do not assume a feature from an older guide still exists.
What a readiness review covers and what the client keeps
A readiness review is agreed as a fixed-scope engagement, with the scope, deliverables and timeline written down before work starts. The review starts from the network diagram and the decisions behind it: validator count, bootnode placement, node roles, the genesis settings, and how each node is permissioned. DeployOpen checks each decision against the rest of the design and records where it is unresolved. The output is a written set of deliverables: the configuration repository under source control, evidence from rehearsals in a dev cluster, the monitoring and alerting setup, and runbooks for provisioning, node updates, key handling and recovery. Confirm the exact deliverable list, and the format of each, in the statement of work.
The client keeps decision ownership throughout. The network's governance, validator membership, consensus choices and go-live call stay with the organization, and so does sign-off on each consortium member's nodes when several organizations share the network. DeployOpen prepares systems, controls and evidence for an internal review or for an independent assessment, but it does not issue audit reports, attestations or certifications. Ask the auditor or assessor which evidence they expect in advance, because that shapes how the rehearsal records and configuration history should be kept. The client should also confirm who in its own team will own each runbook after handover.
Ongoing work can be placed on a retainer rather than left to the handover. Besu releases roughly monthly, and the release notes for each version can change what needs checking, so a retainer can cover rehearsing each upgrade in the dev cluster, reviewing release notes against the network's configuration, and rerunning the testing that the readiness review set up. Ask for the retainer terms in writing, including what is included each month, how urgent requests are handled, and what the client must provide, such as access to the dev cluster and a named internal owner who approves changes.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Hyperledger Besu networks. For a production readiness checklist, we turn each item into a written scope, build and rehearse it in an environment you control, and hand over the configuration, runbooks and evidence your team needs to operate the network after go-live.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope lists validator and bootnode counts, node roles, RPC exposure and the configuration files to be placed under source control.
- Scope also names the upgrade rehearsal, monitoring and alerting, and secured RPC and key handling items the go-live depends on.
How we build
- We plan the network on paper first, then stand up the topology in a dev cluster you control to test connectivity and throughput.
- Each node configuration is kept in version control, with the Besu version and the --version-compatibility-protection setting recorded.
- Upgrades, node reprovisioning and rollbacks are rehearsed end to end, with a backup taken before each database change is tested.
How we hand over
- Handover includes the go-live checklist, configuration repository, dashboards and alert rules wired to Prometheus and Grafana.
- Runbooks cover RPC authentication, key file custody, backup and restore steps, and the upgrade procedure your operators will repeat.
- Documentation records open decisions and the items you must confirm with your consortium partners and your own security team.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial go-live work.
- Support can cover tracking the calendar release cadence, reviewing release notes and rehearsing each upgrade in the dev cluster first.
- Retainer scope, response expectations and review cycles are agreed in writing, and quotes follow from that written scope.
