Hyperledger Besu customization

Most Besu customization falls into one of three layers, and the layer determines who has to be involved and how risky the change is. The first layer is genesis and consensus settings, which are chosen when a network is created. The second is local permissioning files on each node, which control node permissioning for connections to known participants and account permissioning for onboarding, suspending accounts and limiting actions. The third is plugins built on the Besu plugin API, which add code to a node. Before anyone writes code, the team should decide which of these layers the requirement actually belongs to, because a change that fits in a configuration file is far cheaper to operate than one that needs a custom build.

Genesis and consensus settings deserve the most caution. Some of these values are fixed once blocks exist, and others may be adjustable on a running chain depending on the Besu release in use. The team should check the Besu documentation for each genesis or consensus parameter it intends to set and record, for every one, whether it can change on a live network and what procedure the documentation requires. Any change to a live chain's consensus behavior needs a coordinated plan agreed by all validators, including the timing of the change, how each operator will apply it, and what happens if one validator does not switch over. A change made by one operator alone can stall block production on a QBFT network.

Local permissioning sits in between. The node permissioning and account permissioning files are read by each node, so they can be changed without rebuilding Besu. That convenience carries an operational cost: every validator and any node that enforces the rules has to hold the same intended version of the files, and the team needs a process to confirm this after each edit. Account permissioning changes that suspend an account or restrict its actions should be tested in a non-production environment first, and the owners of the onboarding decisions should be named before the first change is made. Keep the files under version control so that the history of who changed which rule and when is available during an audit.

Plugins are the layer with the highest long-term cost. A plugin is compiled code that depends on the Besu plugin API, so each Besu release the team adopts may require the plugin to be rebuilt, retested and redeployed on every node. Ask the plugin's author or the internal engineering team to confirm which Besu versions the plugin supports, and treat that list as a constraint on the upgrade calendar. Some requirements can be met by a plugin that already exists, such as a security module plugin for hardware-backed key storage, and the team should check those options before building anything. The Besu maintainers have pointed teams that still need features removed from the product toward plugins or community forks, which means those teams should expect to own that code and its maintenance from the start.

Custom code in a Besu deployment carries a recurring cost that begins the day it goes live. Besu uses calendar version numbers and ships roughly monthly, and the release list on GitHub already runs from 26.7.0 (July 13, 2026) through 26.10.0 (October 16, 2026). Every plugin, custom permissioning rule or changed configuration path has to be checked against each release you intend to adopt, so the cost is not a one-time build fee. It is the sum of many small retests, each triggered by a release you did not choose to schedule.

The first decision is who pays for those retests. In most arrangements the client's own engineers absorb them by default, because they own the repository and the node fleet. A partner can instead take the work under a retainer, which covers reviewing release notes, rerunning the customization test suite and fixing breakage within an agreed scope. A split is common: the client's team owns the business logic and day-to-day operation, while the partner covers the Besu-facing interfaces, such as the plugin API calls and the permissions configuration. Whichever model you choose, write down which customizations fall inside it, because an unlisted plugin is usually billed as new work.

Triggers for retesting fall into three groups. Scheduled triggers are the monthly releases you decide to evaluate. Breaking-change triggers are removals already announced in the Besu release history, such as the removal of Clique consensus in 26.4.0 and the earlier removal of Tessera privacy and onchain permissioning in 25.6.0. Platform triggers come from the runtime, including the JDK requirement, which the 26.6.0 release notes say is JDK 25 for building and running Besu. A customization that touches none of these may still need a retest if it depends on a logging format, a metrics name or an RPC method that a release changes.

When you request a quote for ongoing support, ask for the following in writing. Get a named list of covered customizations, with the Besu interfaces each one uses. Ask how breaking changes are reviewed: who reads each release, which changes are classified as affecting your code, and how that classification is recorded. Ask who signs off a build for each environment, and whether the client's security or change-management owner must approve it before it reaches a validator. Finally, confirm how response work is priced when a release arrives outside the agreed cadence. The upgrade process itself, including database and rolling validator steps, is covered on the upgrades and support page.

Customization work stalls quickly when the client has not assembled its inputs before the first design session. The most important items are access to the current node configuration and the genesis file. Every genesis and consensus setting we would consider changing is read from these files, and a plugin or permissions change has to be checked against the exact chain parameters the network runs today. Without them, the team has to reconstruct the configuration from memory or from running nodes, which is slower and more error-prone. We ask for read access to the live configuration files for each node class, plus the genesis file used at launch and any later changes to it, so we can confirm what is actually in force.

The second item is a written list of consortium rules and the person who can decide them. Besu's local permissioning is configured in the node permissions file and the account permissions file, and both reflect governance choices: which nodes may connect, who may submit transactions, and under what conditions an account can be suspended. If nobody with authority is named, every permissioning question becomes an open item that waits for a meeting. Ask the client to identify a single decision owner for rule changes, and a deputy, and to record the rules in plain language before design begins. Missing rules delay design decisions and often force rework after a plugin is already written.

The client should also confirm the target Besu version and the JDK it will run on. Besu 26.6.0 release notes state that the software requires JDK 25 to build and run, and the release cadence is roughly monthly, so the target version determines which plugin API surface and build toolchain we use. Ask for the exact version, the JDK distribution the client has approved, and whether a plugin built against the current API is already in use. Without a fixed target, a plugin can compile against one release and fail against the version that reaches production. Also ask whether the client has a policy on how far behind the latest release it may run.

Two further inputs make custom code testable. First, a non-production validator set that mirrors the production consensus configuration, including validator count, key custody method and peer topology. Plugins that touch block production, transaction validation or permissioning cannot be verified on a single node, and tests run against a different validator set can pass while production behavior differs. Second, the client's build and artifact repository, meaning where source is stored, how builds are produced and where signed artifacts are published. We need to know the approved build pipeline, the artifact naming and retention rules, and who can publish to production. If these are missing, the custom code cannot be delivered through the client's own change process.

Finally, name an owner for each validator operator. Customization changes how validators behave, so each operator must know what is changing, when it will be rolled out, and who approves their node going live with the new plugin or configuration. Ask for a named contact per operator organization, their escalation path, and their availability during the rollout window. If operators are not named, validator changes cannot be coordinated, and the first real test of a custom plugin may happen on a live network. Confirm these owners in writing before the statement of work is signed, because they drive both the test plan and the cutover schedule.