What does permissioned blockchain cost when the software is free?
If you are a finance or platform leader with a network idea and no license line to budget, start here: Hyperledger Fabric and Besu both carry no license fee. Fabric is licensed under Apache-2.0, and Besu is licensed under Apache 2.0 as well. That moves the cost somewhere else: labor to deploy and run nodes, infrastructure for each member's peers and orderers or validators, hardware security modules and key management, certificate authority operations, smart contract development and review, monitoring, upgrades, and the governance work of getting several legal entities to agree on one network. The total depends mainly on how many members join, which regulations apply to each of them, and who operates each node. A consortium where every member runs its own nodes costs differently from one where a single operator runs nodes on behalf of several members.
There are three paths. With build, your team owns the platform, the runbooks and the on-call rota. With partner, an implementation partner plans, deploys, hardens and documents the network inside your cloud accounts or data centers, and your team keeps the keys and operating responsibility it chooses to keep. With SaaS, a managed blockchain service runs the infrastructure, and you accept its terms for hosting, key custody, upgrade timing and exit. DeployOpen does not publish a price list. Its engagements are fixed-scope, so a quote follows from a written scope that names the member count, the nodes each member hosts, the HSM model, the monitoring and upgrade services, and any retainer for ongoing support.
Before you compare numbers, ask each option to separate one-time costs (design, first deployment, initial smart contract build and audit, governance documents) from recurring costs (node hosting, HSM fees, monitoring, Fabric or Besu upgrades, contract changes, support). Ask who pays for each member's nodes, and what happens to the network if a member leaves. For SaaS, confirm in writing how the provider prices nodes, what it charges for data egress and key operations, and whether you can export your ledger and identity records. For build or partner, confirm which Fabric or Besu release line you will target, since upgrade work recurs with every supported release. Your own cost model should reflect those answers rather than a generic figure.
Which cost components sit in-house, with a partner, or in SaaS
This table shows, for each cost component of a Fabric or Besu network, whether the work usually stays in-house, goes to an implementation partner, or is bundled into a managed blockchain service. Read each row for who is paid, and whether the cost is mostly one-time setup or recurring operation. The main takeaway is that licence fees are zero for the open-source core, so the cost sits in people, infrastructure and governance, and the split between the three models should be set in writing before the network is built.
| Cost component | In-house | Partner | SaaS |
|---|---|---|---|
| Node hosting per member | Your team runs peer and orderer or validator nodes on your infrastructure, with recurring staff and compute cost | Partner plans, builds and runs nodes in your cloud or data center under a written scope, usually with recurring support | Provider hosts nodes, typically billed as a recurring subscription; confirm which nodes you control |
| HSMs and key custody | You buy, configure and operate HSMs for node and signing keys, with one-time hardware and recurring maintenance | Partner configures HSM-backed key storage per the Fabric HSM documentation; hardware purchase and licences are usually quoted separately | Provider manages keys; confirm who holds custody and how keys can be exported or revoked |
| Custom images and CI | Your engineers build and patch node images and pipelines, a recurring effort tied to each release | Partner builds hardened images and pipelines as a one-time project, then supports upgrades under a retainer | Usually included in the service; confirm whether you can run your own chaincode or contract images |
| Fabric CA or permissioning administration | Your identity team issues enrollment certificates, handles renewal and revocation, and maintains node and account permissions | Partner designs the CA hierarchy and permissions model once, then supports ongoing identity operations | Provider runs the certificate authority; confirm revocation procedures and who approves new members |
| Smart contract development and independent review | Your developers write and test contracts; independent review is a separate, one-time or periodic cost | Partner builds contracts and arranges or performs security testing as fixed-scope work, with review quoted separately | Provider may supply templates; custom contract development and independent review are usually extra, so confirm in writing |
| Monitoring and alerting | Your operations team runs metrics, logs and alerts, a recurring cost tied to on-call staffing | Partner sets up monitoring as a one-time build and can offer recurring monitoring support | Provider dashboards are usually included; confirm what each member can see across the network |
| Version upgrades | Your team plans and executes rolling upgrades, backups and rollbacks, recurring with each release line | Partner runs upgrade planning and execution under a retainer, including rollback backups before each change | Provider schedules upgrades; confirm notice periods, testing windows and what happens if a member lags |
| Multi-party governance | Your legal and governance staff negotiate membership, data rules and change control, a recurring cost while the network runs | Partner facilitates design workshops and documents governance as a one-time project, with recurring coordination | Provider offers a governance framework; members still negotiate rules, so confirm who carries the disputes |
What moves the cost up or down
Permissioned ledger cost comes from the people and infrastructure a network needs, not from license fees. The drivers below set how many nodes you run, how much key and certificate work you carry, which release line you pin, and how much evidence you produce for supervisors and auditors.
Member count and nodes per member
Every member that hosts its own peer, and every orderer or validator it runs, is infrastructure someone patches, monitors and pays for. Costs multiply with each member because each one needs its own hosting, backups, certificates and on-call coverage. Ask the partner how many nodes per member they recommend, who hosts each node, and which member pays for the shared ordering service. Confirm the count before comparing quotes, because the node total drives most recurring operations effort.
Ordering topology: Raft or BFT
Fabric documentation recommends Raft ordering, which is crash fault tolerant. A five-node Raft cluster tolerates the loss of two nodes, so it needs five orderers across member infrastructure. Fabric v3.0 added a BFT ordering service based on SmartBFT that tolerates failures of up to, but not including, one third of ordering nodes. BFT typically needs more nodes and more operational skill, so ask the partner to model both topologies against your failure requirements.
HSM and key requirements
Node keys, signing identities and CA material need protected storage, and a hardware security module adds purchase, hosting, firmware and backup costs that a software keystore does not. Fabric supports HSM-backed keys, but the integration work, key ceremonies and recovery procedures are billed as project effort. Ask for the key hierarchy, who holds custody of each key, how HSM failover is tested, and whether the quote includes HSM configuration or only node software.
Fabric release line: v2.5 LTS or v3.x
The Fabric documentation names v2.5 as the long-term support release for production users, and the 3.x and 2.5 lines both receive patch releases. Moving to v3.x requires migrating Kafka ordering to Raft and moving all channels to the v2.x chaincode lifecycle before the upgrade. That migration is one-time project work, but it changes which features you can use and how often you upgrade. Ask the partner which line they will support, how long they commit to patching it, and what the migration plan costs.
Besu sunsetting and Clique removal
For Besu, several features that older private network designs relied on have been removed or sunset. Tessera privacy and onchain permissioning were removed in 25.6.0, and Clique consensus was removed in 26.4.0, so a pure Clique network can no longer start or produce blocks. Migrating a network built on these features is a one-time cost, and it means each new feature choice must be tested against the current release. Ask the partner which privacy and permissioning design replaces each retired feature, and how the migration is tested.
Regulatory evidence duties
Regulated members must show how the network is monitored, changed and recovered. The FTC Safeguards Rule requires logging of authorized user activity, change management procedures and encryption of customer information, and absent effective continuous monitoring it requires penetration testing and vulnerability assessments at least every six months. Evidence collection, retained logs, test reports and change records are recurring work. Ask the partner which evidence they produce, in what format, and whether it is included in the fixed scope or a retainer.
Why upgrades and deprecations are a recurring cost line
Upgrades on a permissioned network are a recurring line item, not a one-time install. Both platforms have removed features in recent releases, and each removal turns a routine patch into a migration project with its own testing. In Fabric, v3.0 removed the Solo and Kafka consensus types and the v1.x legacy chaincode lifecycle. Any network still on Kafka ordering must move to Raft, and every channel must move to the v2.x lifecycle, before the upgrade can even begin. Besu has been more aggressive on removals: recent releases dropped the Tessera privacy feature, onchain permissioning, the EEA and PRIV privacy RPC API groups, and Clique consensus. A node that depends on any of these will not start or produce blocks after upgrading.
The cost sits in the work around each change. Your team, or your implementation partner, has to inventory which removed features each member's nodes use, rebuild configuration and client integrations, rehearse the change on a non-production network that mirrors the members, and agree the timing across every member organization. Ask any partner to show, for the specific versions you plan to run, which deprecated items affect your current configuration and how much of that work is included in a fixed-scope quote. The Fabric upgrade documentation and the Besu release notes are the starting points for that inventory.
The Besu Bonsai database is the rollback risk to plan for. The 26.10.0 release notes state that the database upgrades automatically on first start and that older Besu versions cannot open an upgraded database. Rollback therefore depends entirely on a backup taken before the upgrade, and the restore has to be tested, not assumed. Fabric's guide follows a similar discipline: back up the ledger and MSPs, upgrade orderers and then peers in a rolling fashion, and only then update channel capability levels. Confirm with your partner who owns each backup, where it is stored, how long it is kept, and how a restore is rehearsed before every production upgrade, and make those activities explicit line items in the quote.
How the three options compare for a consortium member or operator
Building in-house means your own team owns every node, certificate authority, key store and contract release. Because Hyperledger Fabric and Besu are open source, there is no license fee to pay, so the spend is in people, infrastructure and the governance work of a network with several parties. Your organization decides the upgrade calendar, including when to move from the Fabric v2.5 long-term support line to the 3.x line, and it carries the operational pager for ordering or validator outages.
- Keys: your team generates and protects node, MSP and CA keys, usually with HSMs, and runs rotation and revocation.
- Upgrades: you plan rolling orderer and peer upgrades, backups before each change, and the Besu rollback rule for upgraded databases.
- Contracts: your developers write, test and version chaincode or contracts, and they need an audit before production.
- Recurring work: monitoring, on-call coverage, capacity, patch testing and staff retention.
- Exit: the open-source code can be moved, but only if your runbooks and data formats are documented well enough for another operator to take over.
Confirm with your own engineers how many people can cover a node incident on a weekend, and whether the skills exist before you commit.
An implementation partner builds the network to a written scope, then hands it over or runs it under a separate retainer. The fixed scope should name the nodes, the members and the deliverables, such as CA setup, HSM integration, monitoring, upgrade runbooks and contract release procedures. Ownership of keys and infrastructure stays with the member or the consortium, which matters for supervisory evidence.
- Keys: the partner configures key storage in your environment, but the keys should be generated and held under your control.
- Upgrades: the partner can execute the first upgrade cycle and write the runbook, while ongoing upgrades depend on whether a retainer is signed.
- Contracts: the partner can develop and test contracts, and the scope should say whether an independent audit is included or separate.
- Recurring work: retainers for support, patches and testing are optional and priced separately from the build.
- Exit: the written handover, source, documentation and credentials define how you leave. Ask for these to be listed as deliverables.
Confirm in the statement of work who acts as the operator after go-live, what response times apply, and what happens to the environment if the engagement ends.
A managed blockchain service runs the network infrastructure for you, usually under the provider's cloud and operating model. This lowers the amount of node administration your team performs, but it changes who holds keys, where the data sits and which upgrade calendar applies. Membership, governance and contract rules still need to be agreed among all members, because no provider can settle those for you.
- Keys: confirm whether node and CA keys sit in your own HSM or in the provider's key service, and whether you can export them.
- Upgrades: the provider decides the release timing, so ask which Fabric or Besu versions are offered, how long old versions are supported, and how you are told about breaking changes.
- Contracts: most services leave contract development and audit to you or a third party, so the cost sits in your budget even when hosting is included.
- Recurring work: subscription fees, usage charges and support tiers recur for as long as the network runs.
- Exit: ask how ledger data, certificates and configuration can be exported, and in what format, before you sign.
Confirm with each provider which Besu permissioning and Fabric CA features are exposed, what audit logs you receive, and what the contract terms say about data retention and termination.
How to build your own cost estimate
This sequence turns a vague budget into a line-item model you can test against any build, partner or managed service quote. Work through it in order, because each step sets the inputs for the next.
List members and nodes per member
Start by listing every organization that will join the network, the role each one plays, and how many peer, orderer or validator nodes each must host. Count the nodes per member first, since most recurring infrastructure, monitoring and patching costs scale with that number. Ask each member whether it will run its own nodes or rely on another member or a provider to host them. The output is a membership table with node counts and an owner for each node, which you can send to partners as the basis for their quotes.
Choose the ordering and CA design
Decide the ordering service model and how identities will be issued before pricing anything else. Fabric documentation recommends Raft for most networks, and a five-node Raft cluster tolerates the loss of two nodes, while Fabric v3.0 added a BFT ordering service based on SmartBFT that tolerates failures of up to, but not including, one third of ordering nodes. Decide whether Fabric CA or an external user registry such as LDAP will handle enrollment, renewal and revocation. Each choice changes how many ordering nodes, CA instances and operators you need. The output is a written design decision that names the consensus model and the identity source.
Map HSM and backup needs
List every key that must be protected, including node keys, MSP signing keys and CA keys, and decide which of them need hardware security module storage. Confirm with each member what their internal policy or supervisor expects for key custody. Then size backups for the ledger, the MSPs and the Besu database, noting that a Besu upgrade can make the database unreadable by older versions, so a pre-upgrade backup is required for rollback. The output is a key inventory with storage method per key, plus a backup schedule and retention rule that you can price as recurring work.
Count contract and audit scope
Inventory the smart contracts or chaincode the network will run, the number of channels or contract groups, and the business rules each one enforces. Estimate how many contracts will change in the first year and how each change will be reviewed before deployment. Ask partners to quote development and security review separately, and ask whether the review covers each contract version or only the initial release. The output is a contract register with version count, owner and review type, which turns a loose development estimate into countable work.
Add monitoring and upgrade cadence
Define what must be monitored on every node, such as operations metrics, alerts for orderer availability and certificate expiry, and log retention for authorized user activity. Then set an upgrade cadence that names the Fabric LTS line or the Besu release track you will follow, and the number of test environments each upgrade must pass through. Fabric publishes patch releases on its 3.x and 2.5 LTS lines in parallel, and Besu ships roughly monthly, so the cadence determines how often this work recurs. The output is a monitoring scope and an upgrade calendar that a partner can price as a retainer or per-event effort.
Price governance meetings and change control
Estimate the governance work that keeps a multi-party network running, including membership onboarding, permission changes, contract approvals and incident reviews. Count the standing meetings, the change requests you expect each quarter, and the people from each member who must attend. Besu's permissioning and Fabric's channel policies both require agreed decisions before a change is applied, so treat that approval time as a cost. The output is a governance calendar with expected change volume, which exposes the recurring labor that most early estimates leave out.
Compare quotes by recurring and one-time totals
Ask every build, partner or managed service provider for line items that match the steps above, not a single bundled figure. Request separate totals for one-time setup, such as design, initial contracts and HSM provisioning, and for recurring costs, such as hosting, monitoring, backups, upgrades and governance support. Confirm which items each provider includes and which are excluded, and compare the recurring total over the period you plan to run the network. The output is a side-by-side comparison in which every provider's recurring and one-time totals are visible, so differences in scope are easy to see.
Questions buyers ask before hiring outside help
What drives the cost of running a permissioned blockchain network?
The main cost drivers are how many nodes each member runs, whether keys sit in hardware security modules, how many custom images your team builds and maintains, the certificate authority operations behind identities, smart contract development and independent review, monitoring, and the upgrade cycle. Governance work across the members is often the largest hidden item, because every change to the network needs agreement from parties who may have different priorities. Ask a partner to price each of these as its own line in the written scope, separating one-time setup from recurring operations.
Is there a license fee for Hyperledger Fabric or Besu?
Both platforms are open source. Hyperledger Fabric is licensed under Apache 2.0, and Besu is also licensed under Apache 2.0, so there is no software license fee to pay to the project. The costs you will pay are for infrastructure, people, hardware security modules, implementation and support. Check any commercial add-on, managed service or vendor tooling separately, since those are priced by their providers and are not part of the open source license.
How much effort does a permissioned ledger take to run?
Effort depends on the number of members, the consensus design, how often you upgrade, and how much identity and key management you own. A Raft ordering service with a five node cluster can tolerate the loss of two nodes, which means someone must watch nodes, certificates and capacity continuously. Each Fabric major line and each Besu monthly release also needs testing before rollout. Ask a partner to show the recurring tasks, who performs them, and how often they occur, rather than accepting a single effort figure.
How long does it take to stand up a network in production?
Timing is set by the number of members who must agree on governance, the identity model, the consensus choice, the hosting footprint and the smart contract review cycle. Most of the delay usually comes from multi-party decisions and compliance evidence, not from installing software. Ask for a written plan with milestones for each member and a dependency list that shows which decisions block others. Any duration quoted before those decisions are made should be treated as an assumption to confirm.
What does the work need from our internal team?
Your team needs named owners for node operations, identity and certificate policy, key custody, change control and the network governance process. Engineers will need access to your cloud or data center accounts, your identity provider if you use one, and your monitoring stack. Business owners must agree on membership rules, data sharing and who approves smart contract changes. Ask the partner to list these roles in the scope so you can confirm staffing before work starts.
Can we run a permissioned ledger ourselves without an outside partner?
Yes, an internal team can run the platform if it has skills in Linux operations, public key infrastructure, Fabric or Besu administration, security testing and release management. The harder part is keeping pace with releases. Besu ships roughly monthly and requires JDK 25, and Besu removed features such as Tessera privacy and Clique consensus in recent releases, so an upgrade can require code and configuration changes. Fabric v2.5 is the long-term support release for production users. Outside help is most useful for the initial design, the first upgrade cycles and independent testing.
When is a managed blockchain service a better choice than self-hosting?
A managed service is usually the better fit when your network has few members, no strict data residency or key custody rules, and no plan to build internal platform skills. Self-hosting fits better when regulators or members require you to control nodes, keys and data location, or when you need to connect the ledger to internal ERP and identity systems. Ask any SaaS provider which keys they hold, where nodes run, how upgrades are scheduled, and how you export your ledger data if you leave.
How DeployOpen scopes a fixed-price permissioned network
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including Hyperledger Fabric and Besu networks. For a permissioned ledger, the work starts with a written scope that separates license-free software from the node, key, certificate and governance work that carries the real cost.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope lists each member's nodes, HSM or key storage choices, and whether ordering runs on Raft or BFT.
- Smart contract count, audit depth and upgrade policy are named so a quote reflects the actual work.
- Your infrastructure, cloud accounts or data center rules are confirmed so hosting costs are not guessed.
- Ongoing support and upgrade work are scoped separately as a retainer, so recurring costs are visible from day one.
How we build
- Node deployments, Fabric CA or Besu permissioning, and HSM-backed key handling are built inside your environment.
- Monitoring, metrics and alerting are configured for every member's nodes, with clear ownership per node.
- Smart contracts or chaincode are tested, and security testing covers the application and API layers where applicable.
- Backup procedures are set before any upgrade, including ledger and MSP backups for Fabric and database backups for Besu.
- Configuration and build decisions are documented so each member can run its own nodes after handover.
How we hand over
- Handover documents cover node runbooks, certificate enrollment and revocation steps, and the upgrade sequence for each release line.
- Governance artifacts such as channel policies, permissioning files and onboarding rules are delivered for the network operators.
- Compliance evidence is prepared in the form your auditors or supervisors request, such as access logs and change records.
- Operator training is run against your own nodes so staff can perform routine tasks without outside help.
- Open items, known gaps and the owner of each are listed in writing at the close of the engagement.
How we support
- Retainers cover monitoring follow-up, patch releases on the chosen Fabric or Besu line, and upgrade planning.
- Upgrades are scheduled per member, with a backup taken before each change and a rollback plan on record.
- Continuous security testing can be added to cover contract changes and new onboarded members.
- Support scope, response expectations and exclusions are written into the retainer before it starts.
- Ask any partner, including DeployOpen, to confirm which parts of the network they operate and which stay with each member.
