What Hyperledger Besu cost looks like when the license is free
Hyperledger Besu carries no license fee under Apache 2.0, so a budget for a permissioned Besu network or upgrade is a budget for running it. The money goes to compute and storage for validator and RPC nodes, key custody (including any hardware security module or security module plugin), a monitoring stack, test and staging environments, and the people who operate validators, apply monthly releases and answer for the network's uptime. Those lines are the ones to estimate, and each one needs an owner before the number is trusted.
A cost of ownership review is usually triggered by one of three situations. The first is a new consortium build, where the budget must exist before validator operators and their infrastructure are settled. The second is an inherited network, where the previous team's cost assumptions, hosting arrangements and key handling are often undocumented. The third is a planned migration off features the maintainers removed, including Tessera privacy, onchain permissioning and Clique consensus. Removed features can turn into plugin development, a fork to carry, or a redesign, and those costs rarely appear in a license-based comparison because there is no license line to compare against.
Most cost is recurring rather than one-time, so the review should separate the two. One-time costs include design, environment build, key custody setup and initial integration. Recurring costs include infrastructure, monitoring, backups, staff time for upgrades and the testing that comes before each one. Besu's upgrade path adds a specific item: JDK 25 is required, and the Bonsai database upgrades automatically on first start, with older versions unable to open it. Rollback therefore depends on a backup taken before each upgrade, so storage and backup verification belong in the recurring line, not as an afterthought.
Teams with experienced node operators often estimate in-house first, and that is a sound starting point for a single well-understood network. Teams facing a new consortium, an inherited network or a migration off removed features usually get more value from asking a partner to model the cost from a written scope, because those are the situations where the largest variances come from assumptions nobody on the team has tested. Whichever route is chosen, ask for an itemized quote that separates one-time from recurring costs, states the release and upgrade cadence it assumes, names who supplies key custody and monitoring, and lists what is excluded.
What a Besu cost of ownership review includes
The review produces a written scope and model that a buyer can use to compare an in-house build with a partner and to request a quote. Each card is one deliverable or input, and the same assumptions carry from the inputs into the cost lines and open decisions. The output is a written scope and model. It is not an audit, attestation or certification.
Cost model with one-time and recurring lines
A cost model that separates one-time costs, such as design, environment build, initial key setup and migration effort, from recurring costs, such as compute, storage, monitoring retention, security module service fees if chosen, and staff time for validator operations. Each line states who pays for it: your cloud account, your data center, a vendor, or DeployOpen under the written scope. Ask that every line shows its unit basis so you can rerun the model when validator count or environments change.
Component map for each cost line
A map that links every cost line to the Besu component driving it: validator and RPC nodes, persistent volumes for the Bonsai database, node key storage and any security module plugin, Prometheus and Grafana, load balancing and TLS termination in front of JSON-RPC, and backups. For each component the map records what raises its cost, such as more validators, faster state growth or additional environments. Use it to see which decisions move the total and to compare scenarios side by side.
Validator count and environment assumptions
Every model states the assumed number of QBFT or IBFT 2.0 validators, the number of RPC nodes, and which environments exist, such as development, test, pre-production, production and disaster recovery. The review separates assumptions fixed in the scope from placeholders awaiting your decision. Validator count also sets fault tolerance, so a change here affects node spend and the operator staffing needed. Confirm whether non-production environments need the production topology or a reduced one.
Open decisions register
A register of decisions the model cannot settle without you, each with a named owner, the options considered and the cost lines it affects. Typical entries include key custody (file-based node keys or a security module plugin), how to handle privacy or permissioning features that the maintainers removed, the upgrade cadence against Besu's roughly monthly releases, and whether support is handled in-house or under a retainer. Each open item lists the project milestone by which it must close.
Infrastructure inputs reviewed
Node topology, storage growth and runtime requirements. The review covers how many nodes run in each site or cloud account, how each is sized, and how quickly chain state and logs grow on the planned storage. It also confirms the runtime: Besu 26.6.0 requires JDK 25 to build and run, so the JDK version, its patching process and any base image changes become cost and effort lines. Ask your team for the storage growth figures they use today.
Operating inputs reviewed
Key custody, monitoring stack and internal roles. Key custody decides whether node private keys stay in the unencrypted key file, sit behind an HSM security module plugin, or move to another approved store, and each option carries different hardware, vendor and staffing costs. The monitoring stack, whether Prometheus and Grafana or your existing tooling, sets retention and alerting work. Internal roles show who on your side operates validators, approves changes and responds to incidents.
Which factors move Hyperledger Besu cost up or down
This table lists the drivers a reader can change when costing a permissioned Besu network, with why each one moves cost and one way to keep it down. Read each row against your own topology, since the total depends on how these choices combine rather than on any single driver.
| Driver | Why it changes cost | One way to keep it down |
|---|---|---|
| Validator count and operator separation | Each validator needs its own node, storage, monitoring and key custody, and running validators under separate operators adds governance, access and coordination work for each party. | Start with the smallest validator set that meets your fault tolerance and consortium governance needs, and agree operator roles in writing before build. |
| RPC and non-validator nodes | Every RPC, archive or observer node adds compute, storage and monitoring, and each one must be patched and upgraded on the same schedule as validators. | Serve application traffic from a small number of well-sized RPC nodes and avoid running nodes that no application or auditor uses. |
| Number of environments | Development, test, production and disaster recovery each duplicate infrastructure, and the disaster recovery site also needs its own keys and replicated data. | Keep development and test small and short-lived, and size disaster recovery to the recovery time your governance accepts rather than mirroring production in full. |
| Key custody model | The local node private key file is not encrypted, so hardware-backed storage through a security module plugin such as the Besu HSM plugin adds hardware, integration, testing and ongoing key ceremony work. | Decide early whether your risk model requires hardware-backed keys, and confirm the plugin supports your chosen hardware before committing to a design. |
| Monitoring depth | Enabling metrics is inexpensive, but dashboards, alert tuning, log retention and on-call coverage for a permissioned network add recurring operating effort. | Begin with alerts on peer count, block production and sync status, then add depth only where an incident or audit requires it. |
| Compliance evidence needs | Assessors may ask for access logs, change records, permissioning configuration history and key management procedures, which must be collected, stored and reviewed. | Design evidence collection into the build, such as version-controlled permissions files and automated log export, and confirm the evidence list with your assessor early. |
| Dependence on removed features | Networks that rely on Tessera privacy, onchain permissioning, Clique or the removed EEA and PRIV RPC groups need a plugin, a fork or a migration, which carries custom code and release-tracking costs. | Inventory your current features against the Besu release notes first, and prefer rebuilding on supported features over carrying a fork across monthly releases. |
How a Besu cost model is built, step by step
This sequence turns a permissioned Besu network plan into a cost of ownership model that separates one-time from recurring costs. Each phase produces a document that the next phase depends on, so the final quote reflects the real participants, nodes and controls.
Confirm network purpose and participants
Establish what the network is for, which organizations run validators, which parties only submit transactions or read data, and whether the design is a private, proof-of-authority network using QBFT or IBFT 2.0. Besu is Apache 2.0 licensed, so there is no license fee to model, but participant count and roles set the number of nodes and the internal and external effort that follow. Confirm any dependency on features the maintainers removed, such as Tessera privacy or onchain permissioning. Output: a scope note agreed by each participant that lists validators, non-validator nodes and required features.
Inventory current or planned nodes and environments
List every node and environment the network needs: validators, RPC nodes, observer nodes, and separate development, test and production environments. For each one, record the Besu version and JDK in use or planned, since current releases require JDK 25, and whether the node is new or migrated from an existing network. Flag any legacy setup that relies on Clique, Tessera privacy, onchain permissioning or fast sync, because those are no longer available in current Besu and add migration work. Output: an inventory table with node role, site, operator, environment, runtime and version, reviewed with the platform team.
Size storage and compute for each node role
Estimate compute, memory, disk and network capacity for each node in the inventory, using chain growth and retention targets that your engineering team supplies. Storage depends on chain data and the Bonsai database, which upgrades automatically on first start, so plan disks and backup capacity together. Keep a backup taken before each upgrade, because older Besu versions cannot open an upgraded database. Output: a sizing sheet per node role with compute, disk, backup target and network assumptions, mapped to the cloud or data center line items they will become. Confirm growth assumptions with the team, since the model is only as good as those inputs.
Select key custody and monitoring approach
Decide how node private keys are stored and who watches the network. The local node private key file is not encrypted, so teams that need hardware-backed key storage should cost a security module plugin such as the Besu HSM plugin, enabled through the --security-module option, along with the HSM hardware or service and its operations. For monitoring, Besu exposes metrics for Prometheus when --metrics-enabled is set, so the cost includes hosting Prometheus, dashboards and alerting. Output: a key custody decision for each validator and a monitoring design that names the platform, retention period and alert owners. Confirm plugin compatibility with the chosen Besu version and the HSM vendor's support terms.
Assign internal and external roles
Name who performs each piece of work: your staff, DeployOpen, other consortium members, the infrastructure provider, and any HSM or monitoring vendors. Internal work usually includes key ceremonies, change approval, on-call coverage and reviewing releases, which Besu ships roughly monthly. External work covers skills or capacity your team does not have in-house, such as build, hardening, testing and handover. Record which participant pays for each activity, since some costs fall on each organization separately. Output: a responsibility matrix listing each activity, owner and recurring frequency, which becomes the basis for the staffing lines in the quote. Confirm named staff availability with their managers before pricing.
Produce the quote with one-time and recurring lines
Convert the earlier outputs into a quote with separate one-time lines, such as design, build, migration, initial key setup, HSM setup, and initial monitoring build and testing, and recurring lines, such as infrastructure, storage growth, backups, HSM service fees, monitoring, release upgrades and support. Ask each provider for a fixed-scope written quote tied to the inventory and responsibility matrix, with stated assumptions for each line and an explanation of what changes if node count or environments change. Confirm that the quote covers JDK upgrades and the pre-upgrade backup for each database upgrade. Output: a comparison sheet showing one-time and recurring totals for each option. DeployOpen provides fixed-scope quotes based on written scope.
Which costs recur after go-live and who pays for them
This table lists the cost lines a permissioned Besu network creates, marks each as one-time or recurring, and names who usually pays. Besu itself carries no license fee under Apache 2.0, so most of the budget sits in infrastructure, storage, key custody, monitoring and the people who keep validators running. Use the payer column to match each line to the budget owner you need to confirm in a quote.
| Cost line | One-time or recurring | Who usually pays | What drives the cost |
|---|---|---|---|
| Compute and hosting for validators | Recurring | Internal budget or cloud provider | Validator count, instance class, number of environments and sites, and whether each validator runs with a separate operator |
| Compute and hosting for RPC nodes | Recurring | Internal budget or cloud provider | Number of RPC endpoints, expected JSON-RPC request load and whether RPC nodes are kept apart from validators |
| Block and database storage | Recurring (grows over time) | Internal budget or cloud provider | Chain growth rate, the Bonsai database footprint and retention decisions for archive or full nodes, which should be confirmed for your workload |
| Backups and recovery storage | Recurring | Internal budget or cloud provider | Backup frequency, retention period and the pre-upgrade snapshots needed before a database upgrade, since older Besu versions cannot open an upgraded database |
| HSM or key management hardware or service | One-time setup, then recurring support | Hardware vendor or cloud provider, plus internal budget | Choice of HSM plugin or managed key service, number of node keys, and vendor support terms, which should be confirmed in writing |
| Monitoring and log infrastructure | Recurring | Internal budget or cloud provider | Metric volume from Besu's Prometheus endpoint, log retention, alert routing and dashboard hosting |
| JDK and dependency maintenance | Recurring | Internal budget or partner | Besu 26.6.0 requires JDK 25, so each JDK and library change needs testing, patching and rebuilds of node images |
| Upgrade testing for monthly Besu releases | Recurring | Internal budget or partner | Release cadence, breaking changes listed in release notes, plugin or custom code compatibility and the number of environments tested before each rollout |
| Internal skills for validator operations | Recurring | Internal budget | Staff time for validator health, key handling, incident response and on-call coverage, which a partner can supplement under a support agreement |
How the release calendar and removed features change the budget
Besu's release cadence turns part of the budget into a recurring line item, while the removed features add a one-time migration cost for networks that still depend on them. Besu uses calendar version numbers and ships roughly monthly. 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). Because there is no paid edition to renew, the cost of keeping pace sits in staff time to read release notes, test each candidate build, schedule validator upgrades and sign off changes. Ask any partner or internal team to estimate that time per release, and to state whether the estimate assumes every release or only the ones that matter to your network.
Three removals create one-time costs for networks built on older features. Besu 25.6.0 (June 4, 2025) removed the Tessera privacy feature and onchain permissioning. Besu 25.7.0 removed the EEA and PRIV privacy RPC API groups, so any application or middleware calling those methods must be rewritten or replaced. Besu 26.4.0 (April 22, 2026) removed Clique consensus, and the release notes state that Besu can no longer start or produce blocks on pure Clique networks. Each removal needs a decision: migrate the affected data and permissions, move to QBFT or IBFT 2.0, or rebuild the feature through a plugin or community fork. The maintainers suggest plugins or forks for teams that still need privacy or permissioning, and the internal cost of that path, including ongoing maintenance across releases, is the number to confirm before you commit.
The Bonsai database changes the rollback budget. According to the 26.10.0 release notes, Bonsai auto-upgrades on first start, and older Besu versions cannot open an upgraded database. A rollback therefore depends on a backup taken before the upgrade, not on reinstalling the previous binary. Budget for the storage that snapshot needs on every validator and RPC node, the time to take and verify it, and the window in which a failed upgrade must be restored. Check the storage type and retention you will pay for, and confirm with your operations team how long a restore takes on your hardware, since that duration drives how many upgrade windows a consortium can absorb each quarter.
Confirm two things before you build a budget. First, which Besu version your network will target at go-live and how long you will stay on it, since staying on an older release can make later migrations larger. Second, what the maintainers' suggested plugin or fork path would cost inside your own organization, including who writes it, who reviews it, who tests it against each monthly release and who owns it when the original maintainer changes direction. Ask any partner quoting this work to show those items separately, so one-time migration effort and recurring upgrade effort appear as distinct lines.
How the cost of ownership shifts by starting point
A new permissioned network built on QBFT carries the fewest inherited costs. Besu is licensed under Apache 2.0 and has no paid edition, so the budget is set by the nodes, storage, key custody and people you commit to. Most spending is recurring infrastructure and operations, with one-time work concentrated in design and the first deployments.
- One-time: governance decisions, genesis and validator set design, the permissioning file design, and the first build of each environment.
- Recurring: compute and storage for validator and RPC nodes in every environment, plus monitoring and log retention.
- Recurring, people: internal or contracted operators who watch validators, apply upgrades and respond to incidents.
- Grows with: the validator count, the number of environments, and the number of sites or operators that host validators.
- Ask for: a quote that lists each environment on its own line and separates build effort from run effort.
Check whether the quote prices a non-production environment and a disaster recovery copy as separate lines.
Networks that relied on Tessera privacy or smart-contract-based permissioning carry a larger one-time bill. Besu 25.6.0 removed both features, and Besu 25.7.0 removed the EEA and PRIV privacy RPC API groups. Some recurring costs may fall once the retired components are gone, but the replacement design has to be built and paid for first.
- One-time: redesign of confidentiality as application logic or plugin work, and migration of permissioning rules into node and account permissioning files.
- One-time: testing to confirm that applications no longer call the removed RPC groups.
- Shrinks: Tessera nodes, their storage, their certificates and their separate runbooks, once they are retired.
- Grows: plugin maintenance, because custom code must be carried across monthly Besu releases.
- Ask for: a written inventory of every removed feature the network uses, with a line for each replacement.
Check whether the quote covers application changes as well as Besu node changes.
A network still on Clique or an older Besu release has the most urgent one-time work. Besu 26.4.0 removed Clique consensus, and according to the release notes, Besu can no longer start or produce blocks on pure Clique networks. Waiting adds cost over time, because each skipped release widens the gap between the running version and the current one.
- One-time: consensus migration planning toward QBFT or IBFT 2.0, validator agreement on the cutover, and a plan that every operator signs off.
- One-time: installation of JDK 25 on every node, since Besu 26.6.0 requires it to build and run.
- One-time: a verified backup before upgrading, because the Bonsai database upgrades automatically on first start and older versions cannot open it.
- Grows: the number of intermediate upgrade steps to test when the network is many releases behind.
- Ask for: the upgrade path, the rollback plan, and which steps the quote treats as separate phases.
Check whether the quote assumes a test network has already rehearsed the cutover.
The hosting model changes which cost lines dominate, but it does not remove the node work. Kubernetes adds cluster operations, cluster upgrades and the skills to run stateful workloads reliably. Virtual machines keep the operating model simpler for teams that already patch hosts, but each host needs its own hardening and configuration. Besu-specific effort such as key handling and validator management stays in both cases.
- Kubernetes, one-time: cluster build, storage classes for node data, and manifests or charts for validators and RPC nodes.
- Kubernetes, recurring: cluster upgrades and the platform engineers who maintain them, on top of Besu upgrades.
- Virtual machines, one-time: host hardening, configuration management and service definitions for each node.
- Virtual machines, recurring: host patching and capacity planning for each node, carried by the platform team.
- Ask for: which platform the quote assumes, and whether cluster or host operations are priced apart from node operations.
Check who owns the cluster or host layer after go-live and whether that owner appears in the run cost.
An air-gapped network removes the simple paths for software delivery, monitoring and patching. Every Besu release, dependency, JDK and plugin must be brought across a controlled transfer process. That process becomes a recurring cost for as long as the network is supported, and it adds one-time work for artifact handling and offline monitoring.
- One-time: an internal artifact repository or transfer procedure for Besu releases, the JDK and plugins, with checksums verified inside the boundary.
- One-time: offline monitoring, because Prometheus and Grafana must be hosted inside the enclave.
- Recurring: the transfer cycle for each Besu release, which ships roughly monthly, including review and testing before promotion.
- Recurring: key custody. The node key file is not encrypted, so an HSM security module plugin may be part of the design.
- Ask for: how the quote treats release intake, and whether the transfer cycle sits in the run budget or the build budget.
Check whether the security approvals for each transfer are counted as internal time in your estimate.
What usually inflates Besu costs after the first quote
Most Besu budgets are set during a pilot, and the gaps show up later in storage, upgrades, removed features, key handling and staff time. Each card below names one cost pattern and the step that should appear in the quote or plan before work starts.
Storage growth on archive and long-running nodes
Archive and long-running nodes keep growing their data for as long as the network runs, and disk growth is one of the easiest costs to underestimate. Storage needs depend on node type, pruning settings and how much chain history you retain, so a quote built on a fresh test chain will understate production. Ask for sizing based on measured growth from a comparable test network, and list disk expansion, snapshot storage and backup copies as recurring line items.
Assuming the license is the only expense
Besu is licensed under Apache 2.0, so the software itself carries no license fee. The recurring spend sits in compute and storage for validator and RPC nodes, key management hardware or a security module, monitoring infrastructure, and the engineers who patch and watch validators. Ask the quote to list each of these as a separate line with a named owner, marked as either one-time setup or ongoing operations.
Skipping backups before database upgrades
Besu's Bonsai database upgrades automatically on first start, and older Besu versions cannot open an upgraded database. Without a backup, rolling back means rebuilding node data, which takes time and can leave validators offline. Plan a copy of each node's data directory before every database-changing upgrade, test restoring one copy in a non-production environment, and budget the storage and staging time for those copies in the upgrade plan.
Planning for features Besu no longer ships
The maintainers have sunset Tessera privacy and smart-contract-based permissioning, and Besu 25.6.0 removed both. Besu 25.7.0 removed the EEA and PRIV privacy RPC API groups, and 26.4.0 removed Clique consensus. A design that relies on any of these needs a replacement, a migration or a plugin, which adds engineering and testing effort. Ask the quote to confirm which removed features the design uses and to price migration separately from a new build.
Deferring key custody to a later phase
Besu documentation states that the local node private key file is not encrypted. Teams that postpone key custody often run validators on plain key files because the pilot works, and those files then reach production. Include a hardware-backed option in the first build, such as the Besu HSM plugin loaded with the --security-module option or another approved key service. Ask whether the quote covers the hardware or key service fees, plugin configuration and key handling documentation.
No one budgeted to read release notes
Besu ships calendar releases roughly every month, and each one can carry breaking changes, JDK requirements and database changes. Besu 26.6.0 requires JDK 25 to build and run, which can force a platform upgrade before a node update. Without a named owner, the first sign of a required change may be a failed node start. Assign an owner for monthly release review, schedule the time, and ask whether release monitoring and patch testing are inside the support scope or billed separately.
What your team needs to provide before a Besu quote can be accurate
A quote for a Besu network can only be as accurate as the inputs behind it. Because Besu is licensed under Apache 2.0, there is no license line item to price. The effort and running cost depend on how many validators you need, who operates each one, where they run, and how keys and evidence are handled. Before asking for a scope, gather the items below and share them in writing. Each one changes either the build effort, the recurring running cost, or both.
Start with the network shape. Tell us the target validator count, the organizations that will each run validators, and the number of RPC or non-validating nodes you expect. Include the participant list that will go into node permissioning, since Besu's local permissions file restricts which nodes may connect, and the account permissioning rules you expect to enforce, such as onboarding, suspension and restricted actions. Also confirm whether any participant will run more than one validator, because that affects how many separate key, monitoring and on-call setups are needed.
Next, state what you run today. Confirm the Besu version and JDK currently in use if you already operate a node, and whether any network relies on Tessera privacy, onchain permissioning, Clique or the EEA and PRIV RPC groups that the maintainers removed. Those features change the migration effort far more than any licensing question. Specify your storage and retention expectations, including how long chain data must be kept and how often backups must be restorable. Describe your cloud accounts, data centers or air-gapped networks, along with any region, network segmentation or egress rules that apply.
Then describe key custody and monitoring. Explain your key custody policy for validator and node keys, and state whether an HSM is already in place and which vendor and model it is. Besu's documentation notes that the local node private key file is not encrypted, and hardware-backed storage can be added through a security module plugin, so an existing HSM may reduce new procurement but will still need integration work. List the monitoring tools already in use, such as Prometheus, Grafana or a central logging platform, and note who owns their alerting.
Finally, name the people. Provide named owners for validators, for upgrades and for on-call, with the escalation path for a stalled network. Ask us to confirm which of these roles DeployOpen would cover under a support agreement and which remain with your team. List any regulatory evidence requirements you must meet, and identify who will receive that evidence. DeployOpen prepares systems, configurations, controls and evidence for assessments, but it does not issue audit reports, attestations or certifications. Your auditor or certification body makes those determinations, so confirm early which of your evidence needs they will accept.
Questions buyers ask about Hyperledger Besu cost and editions
Is there a paid edition of Hyperledger Besu?
No. Besu is open source under the Apache 2.0 license, so there is no paid Besu edition to purchase. Your cost sits in the infrastructure that runs nodes, storage, key management, monitoring, backups and the staff who operate and upgrade the network. Some organizations also pay for a hosting service, a vendor support contract or a plugin, so confirm with procurement whether any of those are in scope. Also check whether your current network depends on features the maintainers removed, such as Tessera privacy, onchain permissioning or Clique consensus. If it does, migration work or custom plugin development becomes a separate cost line that the license does not cover.
What drives Hyperledger Besu cost the most?
The biggest drivers are the people who run the network and the infrastructure it needs in each environment. Costs rise with the number of validators and RPC nodes, the number of environments (development, test and production), storage growth on the Bonsai database, and the key custody approach, including whether you need hardware-backed storage through a security module plugin. Monitoring retention, backup frequency and the number of integrations also add cost. Upgrade effort is a steady driver because Besu ships roughly monthly and the 26.6.0 release requires JDK 25. Ask your engineers to size each driver against your own transaction volume, retention policy and availability targets.
Can our own team estimate Besu cost of ownership?
Yes, your team can build a first estimate. List every component: nodes per environment, compute and storage, hardware or cloud instances, key management, monitoring, backups, networking and staff time. The harder items to estimate internally are the first-time build effort and the time needed to keep pace with releases, so note those as assumptions. Mark each line as one-time or recurring, and replace assumptions with quotes from your cloud provider, hardware suppliers and any service firm you consider. Label every assumption clearly so an independent reviewer or a partner can check the model before you use it for budgeting.
How long does a Besu cost model take to produce?
The time depends on how many nodes, environments and integrations are in scope, and on how much of your current network needs to be inventoried first. A partner typically starts from a written scope, and most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins. Your own team can shorten the process by preparing the network topology, consensus type, current Besu version, environment count, key custody requirements, integration list, data retention rules and any use of removed features. Ask for the expected duration in the written proposal instead of relying on a general estimate.
What costs recur after a Besu network goes live?
Recurring costs include compute and storage for validators, RPC nodes, backups and monitoring, plus any key management service or HSM maintenance fees. Staff time repeats for monitoring, incident response, access reviews and testing each Besu release. Hardware maintenance contracts, cloud egress or support subscriptions also recur, if you use them. Because Besu releases roughly monthly, upgrade testing is a regular cost rather than a one-time project. Confirm cloud pricing, hardware maintenance terms and whether your own team, a retainer or a mix will carry upgrades, since each choice changes the recurring total.
Do we need a partner to keep Besu upgraded?
Not necessarily. Your team can upgrade Besu if it has the skills, a non-production test environment and a tested rollback plan. Plan for the step that cannot be reversed casually: the Bonsai database auto-upgrades on first start, and older Besu versions cannot open an upgraded database, so a backup must be taken before each upgrade. Read breaking changes and JDK requirements in each release before scheduling. A partner is one option when internal capacity is limited. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and the scope of any retainer should be compared in writing against your own staffing plan.
Which costs are one-time when standing up Besu?
One-time costs cover discovery and design, the initial build of nodes and environments, genesis and validator setup, initial permissioning configuration, key custody setup (including any HSM work), integration development, testing, documentation and cutover. If you are migrating from a network that relied on Tessera privacy, onchain permissioning or Clique, add migration analysis, data movement and any plugin or custom code work. Ask quotes to show these lines separately from recurring fees so you can see what your budget will carry after go-live and what it will not.
What should we ask for in a Besu quote?
Ask for a written scope listing deliverables, environments, validator count, integrations and assumptions, then request a split between one-time and recurring fees. Confirm which items are fixed scope and which are billed on time, what triggers a change request, and which cloud, hardware or third-party license costs are excluded and passed through to you. Ask what support and upgrade coverage is included after go-live, who owns the keys and documentation at handover, and how long the proposal remains valid. DeployOpen does not publish a price list. A quote follows from the written scope, so supply your topology and requirements first.
How DeployOpen scopes and delivers a Besu cost of ownership review
DeployOpen approaches Hyperledger Besu cost of ownership as a written scope that covers the costs outside the license. Besu is licensed under Apache 2.0, so the bill comes from nodes, storage, key management, monitoring and the people who run validators. The review below describes how that work is scoped, built and handed over.
How we scope
- The written scope lists each node, validator, environment and region the cost model covers.
- We separate one-time costs, such as setup and key ceremonies, from recurring hosting and upkeep.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We model node counts, storage growth and monitoring components against your validator and RPC design.
- We confirm the JDK 25 requirement for build pipelines and every runtime host.
- We size key custody options, including an HSM security module plugin, since the node key file is not encrypted.
How we hand over
- Handover covers runbooks for validator upgrades, backups taken before Bonsai database upgrades, which older Besu versions cannot reopen.
- The cost model is documented with assumptions, unit rates and the quote lines that your finance team can audit.
- You receive the written list of components, owners and monitoring alerts that your team keeps after handover.
How we support
- Ongoing support, upgrade work and continuous testing are available as retainers after go-live.
- A retainer can track Besu's roughly monthly releases and review each breaking change for your network.
- Ask the partner to confirm which support hours, response terms and upgrade windows the retainer includes in writing.
