What Besu upgrades and support involve
Besu uses calendar version numbers and ships roughly monthly, so a live permissioned network needs a repeatable routine for reading release notes, testing candidate builds and rolling changes onto validators and RPC nodes. The GitHub releases page lists 26.7.0 (July 13, 2026), 26.8.0 (August 19, 2026), 26.9.0 (September 25, 2026) and 26.10.0 (October 16, 2026) as examples of that cadence. Confirm the current release on the GitHub releases page before planning, because the list changes as new builds ship.
Most changes that need attention are not routine patches. Expect triggers such as a release that changes required runtime, a JDK change (the 26.6.0 release notes state Besu requires JDK 25 to build and run), a database auto-upgrade, a removed feature or a security fix. The Bonsai database upgrades automatically on first start, and older Besu versions cannot open the upgraded database, so a backup taken before the upgrade is the only practical rollback path. Check each trigger against your own node configuration and any custom plugins before scheduling.
Many teams keep routine patching in-house, with a staging network that mirrors their validator set and a written checklist for each release. They often bring in a partner for planned major upgrades, for removed features that need migration work, for incidents on a live network, and under a support agreement that defines response expectations after go-live. Ask any partner to state in the written scope which of these they cover, who runs the rollback, and how they handle a release that changes consensus or database behavior.
What the service includes
The service divides into release-cycle work packages that run each time Besu ships, plus a support agreement that covers the period between upgrades. Scope is agreed in writing against your network, configuration and plugins before work starts.
Release tracking and impact assessment
We follow Besu's calendar releases and assess each one against your running version and deployment before any change is scheduled. The output is a release impact register that records what changed, whether it affects your network, and which decisions remain open. Besu ships roughly monthly, so this work recurs.
Breaking change review against your setup
Release notes are read against your genesis, consensus settings, JSON-RPC exposure, metrics configuration and any plugins you run. Recent removals include Tessera privacy, onchain permissioning, Clique and the EEA and PRIV RPC groups, so each removal is checked for dependencies in your environment. Plugin compatibility is confirmed with the plugin owner or your own build.
JDK planning and runtime alignment
Besu 26.6.0 requires JDK 25 to build and run, so the runtime and build toolchain for each node are checked against the release before upgrade. We plan the JDK change as its own step with a rollback path, covering the image or package source, base OS and any configuration tied to the old runtime. Confirm the JDK requirement of the specific version you target.
Test network upgrades
Each target release is first rolled out to a test network that mirrors your validator count, consensus mode, plugins and RPC layout. Test results decide whether the production change proceeds and which configuration changes are needed first. The test network is kept in your infrastructure and reused for later releases.
Database backup and rollback rehearsal
Bonsai databases upgrade automatically on first start, and older Besu versions cannot open an upgraded database. We take and verify a backup before each change and rehearse restoring it on the test network, so rollback is a tested procedure rather than an assumption. Backup retention and storage location are agreed with your team.
Rolling validator and RPC node upgrades
Validators and RPC nodes are upgraded one at a time in a sequence that keeps the QBFT validator set above its fault tolerance threshold throughout. Each step has a go or stop check, a named owner and a defined point to halt. Separate sequencing for validators and RPC nodes is documented in the runbook.
Post-upgrade verification
After each node returns, we check block production, peer connections, sync status, validator participation and RPC responses against a baseline captured before the change. Metrics are compared with the dashboards and alerts you already use. Verification results are recorded in the change record before the upgrade is closed.
Support agreement: response scope and incident handling
The support agreement defines which Besu components, environments and issue types are covered, how incidents are triaged and who is contacted at each step. Response commitments are written into the agreement itself, with times agreed for your priorities rather than assumed. Confirm coverage boundaries for plugins and custom code before signing.
Scheduled upgrades and periodic review
Upgrades are scheduled against your change calendar and the Besu release cadence, with periodic reviews of the release register, configuration drift and open risks. Reviews confirm whether unsupported features or removed APIs are still in use. Frequency and attendees are set in the agreement.
Documentation and deliverables
At the end of each engagement you receive an upgrade runbook, the release impact register, and a change record for each upgrade, along with updated configuration and network documentation. Documents are written for your operators so they can repeat the procedure without us. Ask for the exact document list and formats in the written scope.
What drives upgrade effort and cost
This table lists the drivers that change the effort of a Besu upgrade, why each one matters and how to keep it down.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Number of nodes and validators | Every node must be upgraded and tested, and validator changes need coordinated restarts to keep QBFT finality. | Keep the validator set small and separate RPC nodes so validators can be upgraded one at a time. |
| Versions skipped | Each release can carry breaking changes, so a jump across several releases means reading every set of release notes in between. | Upgrade on a steady cadence and stay within a short window of the current release. |
| Removed features in use | Tessera privacy, onchain permissioning, Clique, and the EEA and PRIV RPC groups were removed, so networks using them need replacements first. | Inventory privacy, permissioning and RPC usage before planning, then replace or port each item. |
| Custom plugins or forks | Plugins and forks may need rebuilding, retesting and review against each target release. | Keep custom code small, stay on the documented plugin API and track how far each fork has diverged. |
| JSON-RPC and monitoring integrations | Clients, scripts, dashboards and alerts that depend on API methods or metric names can break after a release. | List every consumer of the RPC and Prometheus endpoints and test them in staging before each upgrade. |
| Environments upgraded in sequence | Development, test, staging and production each repeat the upgrade, and a failure in one blocks the next. | Automate node builds and pin the JDK in build scripts, since Besu 26.6.0 requires JDK 25. |
| Bonsai database size and backup window | Bonsai upgrades automatically on first start, and older versions cannot open the upgraded database, so rollback needs a prior backup. | Measure database size and backup time in advance, and confirm restore tests before scheduling the change. |
| Compliance evidence per change | Regulated networks need change records, test results and approvals for each upgrade, which adds review effort to every release. | Use templated change records, build evidence collection into the runbook and confirm the expected evidence with your auditors. |
How an upgrade cycle runs
The sequence turns each monthly Besu release into a reviewed, rehearsed and reversible change, with a written record at every gate.
Review the release and intake the change
We read each Besu release, its release notes and breaking changes against your running version and configuration, then log the items that apply to your network. Output: a release review note that lists each applicable change, removed feature or JDK requirement, with an owner and a decision on whether it is in the next cycle.
Assess impact and agree the plan
We map each applicable change to your validators, RPC nodes, plugins, permissioning files, monitoring and client integrations, and record what must change before the upgrade. Output: an impact register and a written upgrade plan that your team approves, including the rollback approach and the node order.
Build and check the runtime
We build or pull the target Besu version and confirm the runtime meets its stated JDK requirement, currently JDK 25 for recent releases, on each node image. Output: a build record with the artifact version, checksums and a JDK check per host, so no node is upgraded onto an unsupported runtime.
Rehearse on a copy of production data
We restore a recent copy of production node data into an isolated environment and run the upgrade there, including the database upgrade and a sync check. Output: a rehearsal report recording start time, upgrade time, errors, peer and block behavior, and any configuration changes the team must make before the live run.
Back up and take the go or no-go decision
We take and verify backups of node data and keys before any live change, because newer Besu releases can upgrade the database in a way older versions cannot open. Output: a verified backup record and a go or no-go decision signed by your approver, with the rollback path confirmed against that backup.
Upgrade validators and RPC nodes in order
We upgrade nodes one at a time in the agreed order, checking block production, peers and sync after each node before moving to the next. Output: a change record for each node with versions before and after, timestamps, and the health checks passed, and a stop rule that halts the sequence if the network stalls.
Verify and hand over
We confirm the network has finality, monitoring and alerts work on the new version, and client access is unchanged, then hand over the operating notes. Output: a post-upgrade verification report and a handover record. Durations depend on the size and state of your network, so confirm them in the written scope rather than from this page.
What stays in-house and what a partner takes on
This table compares the routine and planned upgrade tasks your team usually keeps with those a partner can take on, names the skill each task needs, and shows where consortium governance keeps the decision.
| Task | Skill the work needs | Who usually does it |
|---|---|---|
| Reading Besu release notes each month | Besu configuration | In-house: decides which releases to adopt. Partner: writes an impact review of breaking changes and removed features on request. |
| Applying patches to non-production nodes | Java runtime operations, Besu configuration | Shared: partner applies patches under a written runbook. In-house: approves each change and checks node behavior. |
| Monitoring validator health day to day | Besu configuration, monitoring with Prometheus and Grafana | In-house: owns on-call and escalation. Partner: tunes alert rules and reviews trends in agreed reports. |
| Planning rolling validator upgrades in production | Consensus and validator governance, change control | Partner: sequences the rollout and prepares the plan. In-house: approves the window and the order of validators. |
| Rehearsing upgrades on a copy of production data | Database and backup administration, Java runtime operations | Partner: runs the rehearsal and records timings and errors. In-house: provides the data copy and access controls. |
| Backing up before irreversible database upgrades | Database and backup administration | In-house: owns backup retention and access. Partner: verifies restores. Besu 26.10.0 notes say rollback needs a pre-upgrade backup. |
| Incident support during a stalled network | Consensus and validator governance, Java runtime operations | Partner: supports diagnosis and recovery steps under the agreed support terms. In-house: makes failover and restart decisions. |
| Adding or removing validators | Consensus and validator governance | Consortium: decides membership by vote under its own rules. Partner: executes only the change the consortium has approved. |
| Producing change records and test evidence | Change control and audit evidence | In-house: keeps approvals and owns the audit relationship. Partner: supplies change logs, test results and runbook versions. |
What usually goes wrong after go-live
Six failure patterns recur after Besu go-live. Each one has a prevention step that belongs in the upgrade runbook before the next monthly release arrives.
Skipping a release
Teams that stay on an older build across several monthly releases can miss a removal until a node refuses to start. Besu removed Clique consensus in 26.4.0, and removed Tessera privacy and onchain permissioning in 25.6.0, so a pure Clique network or a privacy setup can break on upgrade. Watch every release's breaking changes and map each removal to your network before choosing a target version.
Database upgrade without a backup
The Bonsai database upgrades automatically on first start, and older Besu versions cannot open the upgraded database. If a rollback is needed and no backup was taken beforehand, the node cannot return to its previous build on that data. Take a backup of each node's data directory before every upgrade, and test the restore procedure before the change window.
JDK mismatch on one node
Besu 26.6.0 requires JDK 25 to build and run. A single node left on an older Java runtime can fail to start while its peers run normally, and the fault often looks like a network problem at first. Pin the required JDK version in the runbook, check it on every node during the change window, and record it in your node inventory.
Validators upgraded out of order
In a QBFT network, validators must keep enough agreement online to produce blocks while the set changes version. Upgrading validators in an uncontrolled order can drop the number of online validators below the level needed for consensus and stall block production. Agree the upgrade order in advance, upgrade one validator at a time, and confirm block production and peer counts before moving to the next.
Plugins that break on new releases
Custom plugins built on the Besu plugin API, including security module plugins such as an HSM integration, can fail when the host release changes. The failure may appear only under load or on specific transaction paths, so a quick start test can pass. Keep a regression suite for each plugin, run it against every candidate release, and track each plugin's version alongside the Besu version.
Production as the first test
Applying a monthly release to production before it has run on a copy of the network makes the live chain the first real test. Rehearse on a copy built from current node data, with the same JDK, plugins and configuration, and time each step. Rehearsal results should decide whether the planned upgrade date holds.
How the work differs by starting point
Networks already on a current release with a standard configuration have the shortest upgrade path. The work is mostly routine: reading each release in the gap and moving one release at a time.
- Read every release note in the gap, including breaking changes and the JDK requirement. The 26.6.0 notes state that Besu requires JDK 25 to build and run.
- Plan the database step: Bonsai auto-upgrades on first start, and older Besu versions cannot open the upgraded database, so a backup must exist before the change.
- Roll validators one at a time so the chain keeps producing blocks throughout.
- Client: confirm the target release, change windows and who approves go-live.
- Partner: prepare the change plan, rehearse on a copy of the chain and run the rollout.
Networks that still depend on removed features must change their design before they can take the current release. The affected features are Tessera privacy, onchain permissioning, the EEA and PRIV privacy RPC groups, and Clique. The data and cutover details sit in the migration topic.
- 25.6.0 removed Tessera privacy and onchain permissioning.
- 25.7.0 removed the EEA and PRIV privacy RPC API groups, so any application calling them needs a change.
- 26.4.0 removed Clique: Besu can no longer start or produce blocks on pure Clique networks.
- Evidence needed: an inventory of every removed feature in use, drawn from genesis files, node configuration, RPC call logs and application code.
- Client: supply application owners and call logs. Partner: map each dependency to a replacement and sequence the cutover.
Custom plugins built on the Besu plugin API and forks of Besu carry their own upgrade work. A change in a release can affect the interfaces your code depends on, so each upgrade starts with compatibility testing. The design and cost of carrying custom code are covered in the customization topic.
- Plugins: build and test against the target release before any production node is touched.
- Forks: rebase your changes onto each release and confirm the diff still matches what your validators run.
- Security module plugins, such as an HSM plugin, need the same testing as the rest of the node.
- Evidence needed: a compatibility record for each release, including the JDK version and the exact plugin build artifacts.
- Client: decide which features justify carrying custom code. Partner: set up a test branch and run the regression suite against it.
On Kubernetes, an upgrade changes container images, probes, storage and rollout order. The chain rules stay the same, but the way each node restarts changes. Cluster upgrades are a separate workstream that your platform team should schedule.
- Pin each image to an exact release tag so every node runs the version you approved.
- Test persistent volumes: confirm data survives pod restarts and that the database upgrade runs once per node.
- Use an ordered rollout that updates one validator at a time, with readiness checks tied to peer count and block production.
- Evidence needed: the manifests, the volume snapshot policy and the restart test results.
- Client: confirm cluster ownership, upgrade windows and who holds the node keys. Partner: write the manifests, rollout runbook and rollback steps.
Where releases must be mirrored and approved internally, the release date is not the deployment date. Each upgrade waits for artifact transfer, scanning and sign-off. Auditors and certification bodies decide whether the evidence is sufficient, and DeployOpen prepares that evidence without issuing any attestation.
- Mirror the release binaries, container images and the JDK 25 installer into your internal repository before planning begins.
- Record the approval path: who signs off the version, the test results and the change.
- Match the approval cycle to the release cadence. Besu ships roughly monthly, so confirm how long your internal process takes.
- Evidence needed: artifact hashes, change records, test results and proof of the pre-upgrade backup.
- Client: own the approval process and the internal mirror. Partner: prepare the evidence pack and the offline install steps.
What you need to provide before a support agreement starts
Start with an inventory of every Besu node you operate: validators, RPC nodes and bootnodes, each with its exact Besu version, host operating system and the JDK it runs. Besu 26.6.0 requires JDK 25 to build and run, so confirm the JDK version on every host against the release notes for each version you plan to move to. Record which nodes serve which RPC endpoints and which validators sit in which operator's hands, because that decides the order of a rolling validator upgrade and who must be online for it.
Provide the current configuration files, the genesis file and every permissions configuration file used for node and account permissioning. Reviewers compare these against the release notes for each version in the upgrade path, since removed options and changed defaults usually appear here first. List every plugin, custom build and fork with its source repository, the Besu version it targets and who maintains it. A fork that has not been rebased onto the target release will block the upgrade, so ask whether each custom component has an owner who can test against the new version.
Grant access to a non-production environment that mirrors the validator set, plus a defined access path to production. Rehearsals need recent chain data, so confirm how that copy is made and whether it matches production backup procedures. Point us to the backup locations for node data and keys, and provide dated evidence that a restore was tested, including who ran it and how long the node took to rejoin. The Besu 26.10.0 release notes state that the Bonsai database upgrades automatically on first start and older versions cannot open it, so a backup taken before the upgrade is the only rollback path.
Name the people who approve changes to each environment, the maintenance windows your consortium accepts and a single contact who can decide consortium matters. Those matters include validator set changes by vote, timing of an upgrade that all validators must adopt and any pause in block production. Besu ships roughly monthly, so ask how many windows per quarter your consortium can commit to. Confirm window length with each validator operator, because their hosts carry the restart and their sign-off is needed before a rolling upgrade begins.
Questions about Besu upgrades and support
How often does Hyperledger Besu release new versions?
Besu uses calendar version numbers and ships roughly every month. The GitHub releases page lists 26.7.0 (July 13, 2026), 26.8.0 (August 19, 2026), 26.9.0 (September 25, 2026) and 26.10.0 (October 16, 2026). Release dates can change, so confirm the current schedule on the releases page and read the release notes for each version before planning an upgrade window. With a monthly cadence, a repeatable test and change process matters more than a one-off project.
Can our own team upgrade Hyperledger Besu without a partner?
Yes, if your team has the skills and time. Upgrades touch the Java runtime, node configuration, removed features and the node database, and each validator needs a rollback plan. Many teams handle routine minor moves in-house and bring in a partner for planning, higher-risk releases or a retainer that covers monthly testing. Check your capacity against the release calendar before you decide, and confirm each release's requirements in its notes.
What makes a Hyperledger Besu upgrade risky for a permissioned network?
Several factors combine. Besu 25.6.0 removed Tessera privacy and onchain permissioning, 25.7.0 removed the EEA and PRIV privacy RPC API groups, and 26.4.0 removed Clique consensus, so networks that depend on these cannot simply move forward. Runtime changes: Besu 26.6.0 requires JDK 25 to build and run. Irreversible data changes: the Bonsai database upgrades on first start. Coordination: validators and RPC nodes must be moved in a planned order, with the operators of each node agreeing on timing.
Why must we back up Besu before the Bonsai database upgrade?
Because the Bonsai database upgrades automatically on first start, and older Besu versions cannot open an upgraded database. Once a node runs the new version, returning to the previous binary will not open its data, so a copy taken beforehand is the rollback path. Test restoring that backup on a non-production node first. Then confirm the exact procedure for each validator and RPC node against the 26.10.0 release notes and the current Besu documentation.
What does a Besu support agreement cover after go-live?
A support agreement is a retainer with a written scope, separate from the original implementation. DeployOpen offers ongoing support, upgrades and continuous testing as retainers. Items to negotiate include reviewing each Besu release, applying it in a test environment, planning upgrade windows with validator operators, verifying backups, and maintaining custom plugins or configuration. Ask for response expectations to be written into the agreement so both sides know what happens when a node fails.
How is the cost of Besu upgrade and support work set?
The written scope sets the cost. DeployOpen does not publish a price list. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Cost depends on the number of nodes and environments, how many releases fall in the period, whether custom plugins or removed features need migration, how many partners must coordinate validators, and how much test automation exists. Ask each proposal to separate one-time work from recurring retainer fees and to state what triggers extra charges.
How DeployOpen delivers Besu upgrades and support
DeployOpen plans and carries out Hyperledger Besu upgrades on infrastructure you control, starting from a written scope that covers your release path, validator and database changes, and the operations work that follows. Support after go-live can be set up as a retainer that keeps pace with Besu's monthly calendar releases.
How we scope
- Inventory your current Besu versions, JDK, consensus mode and any use of removed features such as Tessera, onchain permissioning or Clique.
- Map the release path from your version to the target release, reading each breaking-change note in order before any change is made.
- Agree the written scope in advance, naming the environments, validators, RPC nodes and deliverables included in the fixed-scope engagement.
How we build
- Prepare the JDK and runtime changes in staging, then confirm the node starts and produces blocks on a copy of your network.
- Take and verify a backup of node data before any irreversible database upgrade, since older Besu versions cannot open an upgraded database.
- Roll validators one at a time while checking block production, peer count and finality, with a documented stop condition for each step.
How we hand over
- Document the upgrade runbook, rollback steps, configuration changes and the test results from each environment.
- Walk your operators through the procedure and the checks they should run before and after each future Besu release.
- Deliver a record of what changed, what was tested and which open items remain for your team to own.
How we support
- Offer ongoing support, upgrades and monitoring review as a retainer, scoped in writing to your release cadence and environments.
- Track each monthly Besu release against your planned upgrade window and flag breaking changes before they reach production.
- Ask any support provider to confirm response scope, the versions covered and who performs rollback in a failed upgrade.
