What does Hyperledger Fabric cost to run once the network is live?
Hyperledger Fabric is licensed under Apache 2.0 and has no paid edition, so the money goes to running the network. Once it is live, the recurring cost sits in infrastructure, hardware security modules, certificate operations, monitoring and the staff who keep each member organization's peers, orderers and Fabric CA healthy. A cost of ownership review turns those items into a model a consortium can fund. Teams usually request one at three points: before a funding decision, before a new member joins and the network grows, or before choosing between the 2.5 LTS line and the 3.x line. Each point changes the recurring bill differently, so the review should be dated and tied to a release decision.
Most teams build the core network in-house and bring in a partner for three pieces: the cost model, the operating design and the first-year plan. The split depends mainly on how much Fabric experience the internal team already has. A team that has run peers, orderers and Fabric CA in production can often build the model itself and only needs a review of its assumptions. A team building its first network usually needs help deciding which costs belong in the model at all, such as consortium governance time, key handling and the on-call coverage needed when a certificate nears expiry. Whichever side does the work, the decision and its owner should be recorded.
Each member organization carries its own share. One-time costs include designing channels and policies, deploying the peers and any orderers the organization hosts, setting up HSMs, building custom images where PKCS#11 support is required (the prebuilt Docker images are not built with it), and drafting the governance agreement. Recurring costs include compute and storage for peers and orderers, HSM service or hardware support, monitoring tooling, Fabric CA hosting and its database, staff time for certificate renewal and revocation, and the work of applying patch releases and planned upgrades. Confirm with each vendor whether HSM and monitoring licensing is charged per device, per instance or per seat, because that determines how the bill grows with each new member.
Several drivers push the recurring figure up or down. The number of member organizations and orderers sets the node count, and the ordering choice matters here. The Raft service keeps working while a majority of its nodes are available, while the BFT service added in 3.x tolerates failures of up to, but not including, one third of ordering nodes. The node count needed for a given fault budget therefore differs between the two and should be confirmed against the ordering service documentation. Environments also multiply cost, since development, test and production each need their own components. When requesting a quote, ask for the cost split by member organization, the assumptions behind node counts and environments, what patch and upgrade work is included, and which items are one-time and which recur each year.
Before the funding decision, build one sheet with a row for each cost item, a column for each member organization and a flag marking each item as one-time or recurring. Mark rows that depend on vendor terms or a release choice, and confirm those before the figures reach the steering group. LF Decentralized Trust also lists Fabric-X, aimed at regulated digital assets, as a separate implementation, so confirm early which one the use case needs. Costing the wrong implementation wastes the whole review, so settle it first. Record which release line the model assumes, because the 2.5 LTS and 3.x lines both receive patch releases, and a model built on one line needs a separate estimate for a migration to the other.
What a Hyperledger Fabric cost of ownership engagement includes
A cost of ownership engagement produces a written model that a consortium can use to compare options and split spending. Each card below is one part of that output, from the cost inventory to the quote inputs the client must confirm before any figure is treated as final.
Per-organization cost inventory
Each member organization gets a list of its cost components: peers, orderers, Fabric CA instances, HSMs, databases behind the CAs and peers, monitoring, backup storage and staff time. The inventory records which component runs in which environment and who operates it. Check that every organization in the consortium has its own line for each component, because orderers and CAs are often hosted by only some members.
One-time and recurring cost model
The model separates costs incurred once, such as design, initial builds, custom HSM images and migration work, from costs that repeat, such as cloud compute, storage, licenses for any third-party tools, HSM service fees, staff time for patching and certificate renewal, and monitoring. Every figure carries a stated assumption about node count, environment count and staffing level. Ask for each assumption to be written next to the number it drives.
Cost split across consortium members
The model shows how shared and per-member costs divide among consortium members, such as shared ordering infrastructure, shared governance effort and per-organization peers, CAs and HSMs. The split depends on agreed governance terms rather than on node counts alone. Confirm the allocation rule with all members before it is used in a funding discussion.
Fabric 2.5 LTS and 3.x path comparison
The model compares the cost of staying on the 2.5 LTS line with moving to 3.x across the planning horizon the client chooses. Fabric 3.x changes ordering options and MSP signing algorithms, and networks must first move Kafka ordering to Raft and all channels to the v2.x lifecycle. The comparison includes the one-time upgrade work and the recurring patch and support effort on each line.
Quote inputs to confirm
The engagement ends with a list of inputs the client must confirm before the model is final: cloud and data center rates, HSM hardware or service pricing, staff hourly rates, backup retention, expected number of channels and organizations, and the planning horizon. Each input has an owner and a source, such as a vendor quote, a cloud price sheet or an internal rate card. Missing inputs are marked as open rather than filled with estimates.
Scope of the written model
The deliverable is a written cost model and decision inputs for the consortium's own planning. It is not an audit report, an attestation or a certification, and no independent auditor or certification body is involved in producing it. Figures come from the client's own vendor quotes, cloud pricing and staff rates, and the model states which figure came from which source so that finance and governance reviewers can check it.
What drives Hyperledger Fabric running cost up or down
This table lists the design and operating choices that move Fabric running cost, why each one matters, and how to keep it under control. Fabric itself carries no license fee, so the rows focus on the nodes, certificate services, HSMs, environments and operational work that consortium members pay for. Read each row as a lever: the first column names the driver, the others explain its effect and the practical control.
| Driver | Why it matters for Fabric | How to keep it down |
|---|---|---|
| Number of member organizations | Each organization usually runs its own peers, CA and MSP keys, so per-member infrastructure and staff time multiply with membership. | Limit membership to organizations with a real channel need and agree on shared operating roles early. |
| Peers and orderers per organization | Every peer and orderer consumes compute, storage, certificates, monitoring and patching, and the count grows with each member. | Size peers to actual endorsement and query load and add orderers only where the ordering design requires them. |
| Ordering model: Raft node count | Fabric documentation recommends Raft, which tolerates the loss of a minority of nodes; a five node cluster tolerates the loss of two. | Start with the smallest node count that meets your fault tolerance target and confirm the number with your consortium. |
| Ordering model: BFT node count | The v3.0 SmartBFT service tolerates failures below one third of ordering nodes, so it needs more ordering nodes than Raft for the same failure count. | Choose BFT only if Byzantine fault tolerance is a stated requirement, and price the extra nodes in the plan. |
| Number of channels | Each channel adds ledger state, chaincode definitions, endorsement policies, and governance work to maintain across members. | Keep channels to documented business needs and reuse existing channel structures where data sharing allows. |
| Certificate authority count and database backend | Fabric CA issues enrollment and TLS certificates and handles renewal and revocation. The default SQLite backend suits single servers, while shared PostgreSQL or MySQL databases support clustered CAs behind a load balancer. | Confirm the database backend before go-live. Use a shared database only when you need highly available CA servers, and assign an owner for certificate renewal. |
| HSM use for MSP keys and custom images | Peer and orderer MSP keys can sit in an HSM over PKCS#11, but TLS keys must stay file-based and the prebuilt Docker images lack PKCS#11, so custom images must be built and maintained. | Limit HSM use to MSP keys where policy requires it, and budget custom image builds and rebuilds into each upgrade cycle. |
| Number of environments | Development, test, production and disaster recovery environments each need their own nodes, certificates, configuration and upgrade testing. | Use smaller non-production topologies that mirror production configuration, and automate deployment to keep environments consistent. |
| Monitoring and log retention | The operations service exposes health checks, log level control, version data and Prometheus or StatsD metrics on every peer and orderer, and the storage and alerting for these grow with node count and retention period. | Set retention to the period your audit and incident response needs, and secure the operations endpoints with mutual TLS. |
| Backup scope | Upgrade guidance calls for backing up the ledger and MSPs before each step, so backup volume and frequency scale with ledger size, node count and release activity. | Scope backups to ledgers and MSPs per node, test restores on a schedule, and keep the backup window tied to change windows. |
| Compliance evidence collection | Assessors expect records of configuration, certificate issuance and revocation, access and change history. DeployOpen prepares evidence; independent auditors issue any assessment outcome. | Agree the evidence list with your auditor before build, and collect it automatically from the operations service and CA logs. |
| Release line choice | Fabric v2.5 is the long-term support release for production users, while the 3.x line adds BFT ordering and Ed25519 signing. Each line receives patch releases, and running an unsupported path raises upgrade cost later. | Choose the release line deliberately, plan upgrades on a fixed cadence, and confirm current patch availability on the Fabric releases page before go-live. |
How consortium members split Hyperledger Fabric costs
The first decision in splitting Fabric costs is separating what the consortium funds together from what each member funds for its own infrastructure. Shared items include governance workshops, channel design that every member must agree to, a shared ordering service if members choose to run one, and shared test environments used to rehearse upgrades. Member items include its own peers, its own Fabric CA, HSMs holding MSP keys, staff who operate those nodes, and monitoring. Fabric is Apache 2.0 licensed with no paid edition, so none of these lines is a license fee. The split is about labor, infrastructure and time. Ask each member which lines it expects to fund directly before anyone signs.
Three common split models shape accountability and exit. In per-organization ownership, each member runs its own peers, CA, keys and staff, and only governance and channel design are shared. Accountability is clear and a member can leave with its own nodes and keys, but every member carries the full upgrade and monitoring load. In shared ordering, a subset of members runs the orderers for everyone while others contribute peers only. This reduces duplicated effort, but the orderer operators hold concentrated accountability, and the agreement must define how orderer operators are added, replaced or withdrawn. In a managed role, one operator runs the network for all members and recovers its costs through an agreed allocation. Smaller members benefit most, but accountability concentrates in one party, so exit depends on contracted terms for data and key handover.
Cost follows operational responsibility. The orderer or peer operator also owns upgrade work, certificate renewal, backups and monitoring for its own nodes. The Fabric upgrade guide sequences this work as a backup of the ledger and MSPs, followed by rolling orderer and peer binary upgrades and then channel capability updates, and each operator performs those steps on its own nodes. Certificate renewal lands on whoever runs the CA and the affected nodes. If a member needs a custom image to support PKCS#11 for its HSM, or an expired TLS certificate traces back to one orderer, the cost falls on that operator unless the agreement says otherwise. Decide these cases in advance.
Write the split into the consortium agreement. List each shared cost line, the allocation method (for example equal shares, per node or per member activity, as an illustrative option), who invoices, who approves changes to the budget, and what happens to shared costs when a member or an orderer operator leaves. Confirm the final wording with legal and finance before procurement, because the split affects liability, data ownership and how each member records its spend. Ask every partner quote to itemize the same lines so the shared and member figures can be compared directly.
Recurring costs after go-live and who usually carries them
This table lists the costs that continue after a Fabric network goes live, who usually pays each one, and what to request in a quote. Fabric itself has no license fee under Apache 2.0, so most recurring spend sits in infrastructure, certificate operations, and people. Use the rows to check that every consortium member has an owner for each line before go-live.
| Cost line | One-time or recurring | Who usually pays | What to ask for in a quote |
|---|---|---|---|
| Hosting for peers, orderers and CAs | Recurring (compute, network, storage) | Each member for the nodes it operates, plus any shared hosting agreement | Node count per organization, sizing assumptions, and whether hosting is in the member's own account or a shared environment |
| Database and storage for ledgers and CA backends | Recurring (storage growth, database service) | Each peer-operating member, and the member running CA databases | Storage growth assumptions, database engine and version, and backup retention settings |
| HSM hardware or service and its operation | One-time purchase or recurring service, plus recurring operation | The member holding the MSP keys, often with the HSM vendor for hardware support | Vendor support terms, key ceremony effort, and whether custom images with PKCS#11 support are included |
| Certificate renewal and revocation work | Recurring (per certificate lifecycle event) | The organization that owns each enrollment and TLS identity, usually with the network operator | Expiry tracking method, renewal runbook, CRL distribution responsibility, and who approves revocations |
| Monitoring and log storage | Recurring (tooling, retention, alert handling) | Each member for its own peers and orderers, or a shared monitoring platform funded by the consortium | Which operations service endpoints are scraped, retention period, and alert ownership per organization |
| Backup storage and restore testing | Recurring (storage, periodic test effort) | Each member for its ledger and MSP backups, with restore tests often coordinated across members | Backup frequency, off-site location, restore test cadence, and who signs off on a test result |
| Upgrade cycles on the chosen line | Recurring (planned effort per release, plus one-time migration work) | Each member for its own binaries, with the consortium agreeing the channel capability update timing | Target line (2.5 LTS or 3.x), patch intake policy, rehearsal environment, and rolling upgrade effort per organization |
| Staff time for on-call and patch intake | Recurring (salaried staff time or retained support) | Each member's platform or operations team, or a retained provider under a support agreement | Coverage hours, escalation path to other members, patch review ownership, and how staff time is estimated from the member's own salary data |
| Periodic security testing and compliance evidence preparation | Recurring (periodic testing, evidence collection) | The member under assessment, with shared evidence for network-wide controls split across members | Test scope, frequency, evidence list per control, and which party prepares evidence for independent assessors |
How a Hyperledger Fabric cost model is built, step by step
The sequence turns a network design into a cost model that each member can check against its own rates, approve through finance and governance, and maintain after handover. Each phase produces a named artifact so the model stays traceable to the design it prices.
Discover the network design and member roles
We review the intended consortium with the people who will sign it: the number of member organizations, which members run peers, orderers or Fabric CAs, the channels planned, and which member carries which obligation. Fabric itself carries no license fee, so every cost traces back to these design choices. The output is a written design baseline that lists each organization, its node roles and its governance responsibilities. The step is complete when the sponsoring members have confirmed that baseline in writing.
Inventory components and environments
Next we list every component the design requires in each environment, such as development, test, staging and production. The inventory covers peers, orderers, Fabric CAs with their databases, HSMs for MSP keys, monitoring and backup storage, and the client applications that use the Fabric Gateway client API. We record where each component runs, who operates it and which platform owns its certificates and keys. The output is a component register that the cost model can price line by line, and the step closes when the client confirms no component is missing.
Map cost components to the client's own rates
We map each inventory line to a cost component: compute and storage in the client's cloud accounts or data centers, HSM hardware or service fees, staff time for operations and certificate work, monitoring tooling, and support or retainer fees. Each component is tagged as one-time, such as initial build and integration, or recurring, such as infrastructure, certificate operations and patch cycles. The client supplies its own internal rates and infrastructure prices, which we apply without substitution. The output is a priced worksheet with an explicit source for every rate.
Compare release lines and upgrade paths
We compare the cost of running the network on the Fabric 2.5 LTS line against the 3.x line, using the upgrade requirements in the Fabric documentation. For a 3.x path, the model includes migrating any Kafka ordering to Raft, moving all channels to the v2.x chaincode lifecycle, and rolling orderer and peer upgrades with backups before each step. It also records the BFT ordering option and what extra orderer nodes it implies. The output is a side-by-side comparison of recurring upgrade effort for each line, and the step closes when the client has chosen the line to price.
Split costs across member organizations
We build a split model that assigns each cost to the member that incurs it, such as a member hosting an orderer or a CA, and to shared costs that the consortium divides by an agreed rule. The members decide the shared-cost rule, for example by node count, transaction volume or equal shares, and we show the effect of each option on every member. The output is a per-member view that shows one-time and recurring amounts separately. The step closes when the consortium has selected a rule in writing.
Review with finance and governance owners
We walk finance, procurement and the consortium governance owners through the worksheet, the release line choice and the split model. Reviewers test the assumptions, challenge rates and confirm which costs sit in which budget. Governance owners confirm who approves future changes to the model. Each review comment is logged with a decision and an owner. The timeline for this step is set in the written scope and depends on how many members must review the model, so ask for it to be fixed before work starts. The step closes when each member signs off its share.
Hand over the model and its assumptions
We deliver the final cost model with a register of assumptions, the rate sources, the release line assumed, the upgrade steps priced and the conditions that would change the figures, such as adding an organization or moving to a new hosting environment. The client receives the working files and a short walkthrough so its own team can update rates and rerun the split. The output is a documented model that the client owns and maintains. The handover is complete when the client confirms it can recalculate the model without us.
Where Hyperledger Fabric cost models go wrong
Fabric has no license fee, so most budget shortfalls come from work that is easy to leave out of the first estimate. The cards below cover the recurring and one-time items that most often go missing, with a prevention step for each.
Treating zero license cost as total cost
Fabric is Apache 2.0 with no paid edition, so the budget lives in nodes, HSMs, certificate operations, monitoring and staff for each member organization. A model that stops at the license line omits compute, storage, network, and the time each member spends on governance. Prevention: build the estimate per organization and per environment, listing each infrastructure item, who owns it, and whether it is one-time or recurring.
Undercounting staff time for upgrades and migrations
Certificate renewal, rolling orderer and peer upgrades, channel capability updates and Kafka-to-Raft or legacy chaincode lifecycle work all consume engineering hours that recur or arrive as projects. Teams often budget one go-live and forget the upkeep that follows. Prevention: schedule each certificate expiry, each Fabric release line and any migration step as a line item with named roles, and ask any partner to price those tasks separately in the written scope.
Assuming BFT needs the same node count as Raft
Fabric recommends Raft for most networks, and a five node Raft cluster tolerates the loss of two nodes. The BFT ordering service in v3.0 is based on SmartBFT and tolerates failures of up to, but not including, one third of ordering nodes, which changes the node count and the hardware, network and operations cost. Prevention: set the fault tolerance target first, then confirm the required node count in the ordering service documentation before pricing orderers.
Forgetting custom images for PKCS#11 HSMs
Fabric uses the PKCS#11 standard to keep peer and orderer MSP keys in an HSM, but TLS keys must stay file-based. The prebuilt Docker images are not built with PKCS#11, so an HSM deployment needs custom images, a build pipeline, and retesting on every Fabric release. Prevention: decide early which keys go to the HSM, price the image build and its maintenance, and confirm HSM vendor client support for the chosen platform.
Leaving out backups and restore tests
The Fabric upgrade guide starts with backing up the ledger and MSPs, and every upgrade depends on those backups being usable. Storage for ledger snapshots, MSP copies and off-site retention recurs, and restore tests take environment time and staff time that budgets rarely show. Prevention: include backup storage, retention periods set by your own policy, and at least one restore test per release cycle as recurring costs in the plan.
Failing to agree who pays for shared ordering
Orderers often serve every member of a consortium, yet the consortium may not have agreed who funds their hosting, monitoring, certificate work and upgrades. Without that agreement, a single member carries the cost or the network stalls during an unfunded change. Prevention: document the ordering cost split, the decision owner for upgrades, and the exit terms for a departing member before the first channel goes live.
What the client needs to provide for an accurate cost model
An accurate cost model for a Fabric network starts with a written member list. For each organization, record its role in the consortium (for example, endorsing peer operator, orderer operator, or a member that only submits transactions through a client application), the number of peers and certificate authorities it expects to run, and the named decision owner who can approve spend and accept risk for that organization. Fabric is licensed under Apache 2.0, so there is no paid edition to price. Every line item therefore comes from the nodes, HSMs, certificate operations, monitoring and staff each member carries, and those lines multiply with the number of organizations. Without a named owner per member, cost assumptions tend to stay unapproved until go-live.
Next, define the ordering model and where each node runs. Fabric documentation recommends Raft, which is crash fault tolerant and keeps working while a majority of orderers are available. A five node Raft cluster tolerates the loss of two nodes. Fabric v3.0 added a BFT ordering service based on SmartBFT, which tolerates failures of up to, but not including, one third of ordering nodes, and that choice usually means more nodes and more operational effort. State which organizations host orderers, which sites or cloud accounts they use, and which environments are in scope, including development, test, staging, production and any disaster recovery copy. Also name the candidate release line, either the v2.5 long-term support line or 3.x. The releases page lists v3.1.5 and v2.5.16, both published on June 18, 2026, so confirm which patch level the model should assume.
Record HSM and hosting decisions next, since they are often the largest unknowns. Fabric uses PKCS#11 to keep peer and orderer MSP keys in an HSM, but TLS keys must stay file-based, and the prebuilt Docker images are not built with PKCS#11, so a custom image is needed. Tell the model whether each member already owns HSMs, whether it will buy or lease them, whether they are hardware or cloud-hosted, and which data center or air-gapped network constraints apply. Attach existing vendor and cloud quotes, including licensing and support terms, along with internal staff rates or the cost center that will absorb operator time. Also confirm whether the Fabric CA database should be PostgreSQL or MySQL instead of the default SQLite, because that choice changes the hosting footprint.
Finally, list the compliance obligations that affect evidence work, such as the control frameworks your auditors use and the logs, access records and change records they will request from the network. Preparing that evidence takes staff time that belongs in the model, and the platform does not produce it on its own. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors issue any report or attestation. When an input is missing, the model does not stop. It carries an explicit, labeled assumption for that line, and the assumption appears in the output so the reader can see the gap and decide whether to supply the figure or accept the risk. Ask for a written list of open assumptions, each with an owner and a target date for closing it.
Hyperledger Fabric cost questions buyers ask before hiring help
Is Hyperledger Fabric free to license, or is there a paid edition?
Yes, the Fabric software carries no license fee. The hyperledger/fabric repository is published under Apache 2.0, which permits you to use, modify and distribute the code. The license does not cover the work around the software. Your budget still pays for the infrastructure that runs each peer, orderer and certificate authority, the hardware security modules that hold MSP keys, monitoring, backups, upgrades and the staff who operate the network. There is no separate paid Fabric edition to buy. Commercial offerings you encounter are services, support contracts or products built on Fabric, so ask each provider exactly what is included before you compare them with an in-house build.
Which Hyperledger Fabric release line should a new network choose?
For most new production networks, the choice is between the 2.5 LTS line and the 3.x line. The Fabric documentation identifies v2.5 as the long-term support release for production users, and the GitHub releases page shows both v3.1.5 and v2.5.16 published on June 18, 2026, so both lines receive patch releases. The cost difference lies mainly in future migration and upkeep. Fabric v3.0 removed Solo and Kafka consensus and the v1.x legacy chaincode lifecycle, so a network that still uses Kafka ordering or legacy lifecycle must migrate before it can upgrade. Confirm the current support status in the Fabric documentation, then weigh your upgrade cadence and migration budget against your support obligations.
How do consortium members split the running costs of a Fabric network?
Fabric does not set a cost split, so the consortium must agree one in its governance terms. The most common pattern is that each member pays for the components it operates, such as its peers, certificate authority, HSM, monitoring and staff. Shared ordering nodes, shared channel operations and common tooling are the costs that need an explicit rule. Options include equal shares, shares based on the number of nodes each member runs, or shares based on transaction volume. Write the chosen method, the cost categories it covers, the review cycle and the process for admitting or removing a member into the governance agreement. Without that, disputes tend to surface after go-live, when costs are already committed.
Can our own team build the cost model, and what do we provide?
Yes, an internal team can build a cost model if it maps every component and decision. The model should cover member organizations, peers, orderers, certificate authorities, environments, HSMs, monitoring, backups, upgrades and governance time. Your inputs include the planned topology, the number of channels, expected transaction volume, the hosting environment, existing cloud and HSM agreements, staff rates, and the compliance evidence your regulators expect. An outside partner can work from a written scope and check the assumptions. Either way, expect to provide the topology, the list of governance participants, access to your infrastructure inventory and named decision-makers for hosting, identity and key management.
How long does a Fabric cost model take, and what sets the timeline?
The duration depends on the scope, so no fixed figure applies to every network. The main drivers are the number of member organizations, how many decisions remain open, such as hosting location, HSM choice and governance terms, and how quickly your team can supply infrastructure inventories and existing contracts. Consortium review cycles often set the pace more than technical analysis does. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for the duration in the quote, along with the assumptions behind it, the decisions it depends on and the review rounds it includes.
Does Raft or BFT ordering cost more to run in Fabric?
The answer depends on how many ordering nodes you need for your fault tolerance target, so compare node counts before comparing prices. The Fabric documentation recommends Raft, a crash fault tolerant service that keeps working while a majority of nodes are available. A five node Raft cluster tolerates the loss of two nodes. Fabric v3.0 added a Byzantine fault tolerant service based on SmartBFT, which tolerates failures of up to, but not including, one third of ordering nodes. Cost drivers include the number of orderer nodes, their compute and storage, monitoring, and the staff skills needed to run each service. BFT is newer in the 3.x line, so confirm its operational maturity and node requirements with the documentation before you budget.
How much of Fabric network cost recurs after go-live?
Most of the ongoing cost is recurring, but the exact split varies by network. Recurring items include hosting for peers and orderers, storage, backups, HSM service fees, monitoring, certificate renewal and CA operations, patch and upgrade cycles, staff time, and any support retainer. One-time items include design, governance workshops, the initial build, integration, testing, first HSM setup and any custom images. Ask any provider to split its quote into one-time and recurring lines, and to show which assumptions drive each recurring line, such as node count, environment count, change frequency and support hours. That split lets you compare offers and forecast cost across the network's life.
How does Fabric-X change budgeting compared with Fabric?
Budget Fabric-X separately, because it is a different implementation and a cost model for Fabric does not transfer to it. LF Decentralized Trust lists two implementations, Fabric for permissioned networks and Fabric-X, which is aimed at regulated digital assets. The architecture, node roles, operational tooling and staff skills can differ, so the topology, hosting and support assumptions must be checked against the implementation you choose. Confirm the current status and requirements of Fabric-X with its project documentation. Digital asset use cases fall outside the scope of this page, so treat Fabric-X budgeting as a separate exercise that starts with its own scoping.
How DeployOpen builds a Hyperledger Fabric cost model
DeployOpen plans and implements self-hosted Hyperledger Fabric networks inside each client's own infrastructure, including cloud accounts, data centers and air-gapped networks. Fabric is licensed under Apache 2.0 with no paid edition, so we build the cost model from nodes, HSMs, certificate operations, monitoring and staff, and separate one-time build work from recurring operations so each member organization can see what it carries.
How we scope
- The written scope lists every member organization, peer, orderer and Fabric CA the model covers.
- Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
- Each cost line is tied to a named owner: who pays for nodes, HSMs, certificates and staff time.
How we build
- Inventory the nodes per organization, including Raft orderers, peers, and Fabric CA servers with their database backends.
- Model HSM needs for peer and orderer MSP keys, noting TLS keys stay file-based and custom images are required.
- Separate recurring costs such as operations monitoring, certificate renewal and patch releases on the 2.5 LTS or 3.x line.
How we hand over
- Written cost model covering one-time build work, recurring run costs and the assumptions behind each line.
- A split of costs per member organization, showing who owns each node, HSM, and certificate authority.
- Runbook for certificate expiry checks, backups before each upgrade step, and operations service alerts.
How we support
- Ongoing support, upgrades and testing are available as retainers, scoped separately from the initial build.
- Cost reviews when the network changes, such as new organizations, added channels or a move between 2.5 LTS and 3.x.
- Ask each quote to state which costs recur and who pays for them, including upgrade and certificate renewal work.
