What a Fabric implementation involves and who usually does it
A Hyperledger Fabric network build covers far more than installing software. In your own infrastructure, the work spans a governance agreement among the member organizations, the organizations' cryptographic identities, the ordering service that sequences transactions, the peers that hold the ledger and run endorsement, the certificate authorities that issue identities, the channels that scope which organizations see which data, and the deployment pipeline that keeps all of these consistent across environments. Each of these needs an owner and a decision before any node starts.
Most engagements start from one of three triggers: a consortium deciding to share records, a pilot that has to become a production network, or a regulator or trading partner requiring that shared records be permissioned and auditable. The trigger matters because it sets who signs the governance terms and how much time the consortium will spend on decisions that technical teams cannot make for it, such as membership rules, data-sharing boundaries and who may approve changes.
The short answer on in-house versus partner: Fabric is licensed under Apache 2.0, so there is no licence fee. The cost is labor and infrastructure. Teams that already operate Kubernetes, PKI and HSMs at production standard can often carry much of the build themselves. Teams without that experience, or consortia where each member needs independent evidence of how its nodes were built, usually bring in a partner for the first network. Confirm your own skills against the component list above before deciding.
Chaincode business logic is not part of this service. DeployOpen plans and builds the network, its identities, channels and deployment, but the smart contract code that encodes your business rules is written by your developers or a separate development team. Agree that boundary in writing, because channel design and endorsement policies depend on what the chaincode does.
What the implementation includes
A Fabric build breaks into design decisions that set the network's shape, then configuration and verification work that turns those decisions into running components. Each package below carries its own effort drivers.
Network and governance design
This package fixes the consortium's members, roles, endorsement and channel policies, and the rules for admitting or removing an organization. Governance decisions are often slower than the technical work, so ask who signs off each policy and how long those sign-offs are expected to take. Confirm the agreed scope in writing before any node is provisioned.
MSP and CA design
Each member organization needs a Membership Service Provider defining its identities, plus Fabric CA servers that issue enrollment and TLS certificates. Decide early whether each organization runs its own CA, how identities map to your directory, and which key algorithm the MSPs use. Check how many CA instances and databases the design requires.
Orderer and peer topology
This package sets the number of orderers, their consensus type, and where each node runs across organizations and sites. Raft is the Fabric-recommended ordering service, and a five node Raft cluster tolerates the loss of two nodes. Ask which sites and failure domains the topology must survive before the layout is fixed.
Channel creation and chaincode lifecycle
Channels define which organizations share which ledger, and the chaincode lifecycle governs how smart contracts are approved and committed to each channel. Plan channel membership, approval policies and the approval sequence for every organization before creating anything. Changes to channel membership later require careful configuration updates, so confirm who owns that process after go-live.
Operations service and monitoring hookup
Peers and orderers expose a health endpoint, log level control, version reporting and metrics, secured with mutual TLS. This package connects those endpoints to your monitoring stack and defines alerts for ordering, endorsement and gossip problems. Confirm which team receives the alerts and who holds the client certificates needed to scrape them.
HSM integration where required
Where policy requires hardware-protected MSP keys, Fabric supports PKCS#11 HSMs. TLS keys must stay file-based, and the prebuilt Docker images lack PKCS#11, so custom images and HSM test passes add work. Ask your HSM vendor and your security team which key operations the HSM must hold and how key loss is recovered.
Go-live support and acceptance
Go-live covers the cutover checks, a supervised first transaction flow, and acceptance tests against the agreed scope. Ask what post-go-live support is included in the fixed scope and what is available as a retainer. Agree in writing what counts as acceptance before testing begins.
Client deliverables and handover
The client receives a topology document, configuration and deployment code, runbooks, a certificate inventory with expiry dates, and acceptance test results. The certificate inventory and runbooks are the items your team will use most after handover. Confirm the format and version control of each deliverable in the written scope.
What drives the cost and duration
This table lists the design choices that most change Fabric implementation effort, why each one adds work, and how to keep it contained before the build starts.
| Driver | Why it adds effort | How to keep it down |
|---|---|---|
| Member organizations | Each member adds its own MSP, certificate authority, peers, operations endpoints and governance sign-off. | Limit membership to organizations that must endorse, order or hold ledger data, and agree roles in writing early. |
| Orderers and consensus | Raft is crash fault tolerant and a five node cluster tolerates two node losses. BFT (SmartBFT, Fabric v3.0) tolerates failures below one third of orderers but needs more coordination. | Choose Raft unless Byzantine failures are a stated requirement, and confirm node placement across sites and organizations. |
| Peers per organization | Every peer needs certificates, TLS configuration, health checks, metrics and upgrades in each rolling cycle. | Size peers to the endorsement load and redundancy the consortium agrees, and add peers only where a stated requirement needs them. |
| Certificate authorities and database | Fabric CA defaults to SQLite. Several CA servers sharing a database need PostgreSQL or MySQL and a load balancer such as HAProxy. | Use a shared database only when clustered CAs are required, and confirm backup and failover ownership before configuration. |
| HSM for MSP keys | MSP keys use PKCS#11 while TLS keys stay file-based. Prebuilt Fabric images lack PKCS#11, so custom images must be built and patched. | Decide HSM scope early, confirm the HSM vendor's PKCS#11 support, and budget for an image pipeline that follows each Fabric release. |
| Identity source | Fabric CA can use LDAP as its user registry, so directory schema, group mapping and attribute rules must be agreed with the directory owner. | Document the directory attributes each identity type needs and confirm who owns changes before connecting Fabric CA. |
| Environments | Each environment repeats the network build, certificate issuance, configuration and upgrade testing. | Keep environments on the same release line and confirm how configuration is promoted between them. |
| Channels, chaincodes and migration | Each channel adds membership, policies and capability levels. Kafka ordering and v1.x lifecycle chaincode must be migrated before moving to Fabric v3.0. | Use fewer channels with clear membership, and scope any Kafka or v1.x migration as separate work before the upgrade. |
Project phases and what each produces
The sequence moves a Fabric network from agreed governance and design to a production network that your own team can operate after handover.
Agree governance and scope
DeployOpen runs discovery workshops with each member organization to confirm the consortium's business purpose, number of organizations, channels, roles, and who approves changes. The output is a signed governance agreement and a written scope that sets the timeline, deliverables, and acceptance criteria. The step closes when every member organization has signed.
Design the target architecture and topology
Together with your platform and security teams, DeployOpen designs the topology: peers and orderers per organization, ordering consensus (Raft or BFT), certificate authorities and their database backend, HSM use for MSP keys, hosting sites, and the operations service layout. The output is a signed design document with a decision record for each trade-off. Confirm the design against your own infrastructure before sign-off.
Build the non-production environment
DeployOpen builds a non-production network in your infrastructure from a versioned configuration repository, covering identities, MSPs, channels, chaincode lifecycle, and monitoring. The configuration repository and build runbooks are handed over at this stage. The step closes when the network starts, channels join, and a test chaincode runs end to end.
Test integration and failure scenarios
DeployOpen tests client application integration and deliberately fails components, such as stopping orderers, expiring a certificate in a test CA, and restoring a backup, to confirm the network recovers as designed. The output is a test evidence pack listing each scenario, expected result, observed result, and fixes. Your team reviews the evidence before the next phase starts.
Prepare production readiness, certificates and backups
DeployOpen hardens the production build, sets up certificate issuance and renewal, configures TLS and MSP key handling including any custom PKCS#11 images, and automates ledger and MSP backups with a tested restore. The outputs are production configuration, certificate and backup runbooks, and restore test results. Confirm the restore test with your operations team.
Go live and hand over
The network moves to production under the agreed change window, and DeployOpen supports the first transactions and monitoring checks. Handover covers operational runbooks, training for your operators, and open items. The step closes with a written acceptance sign-off from each member organization against the scope, after which any ongoing support is agreed in a separate written arrangement.
What teams keep in-house and what they outsource
This table separates the consortium decisions and business knowledge that stay with member organizations from the platform engineering work that is often contracted out, with the skills each part requires.
| Work area | Usually kept in-house | Often outsourced | Skills the work requires |
|---|---|---|---|
| Business process and data ownership | Each member decides which business processes run on the channel and which data it shares | Not usually outsourced, though a partner can facilitate workshops that document the agreed flows | Business analysis, domain knowledge, data classification |
| Governance and membership changes | Approving new members, endorsement policy choices and dispute handling stay with the consortium | Drafting governance documents and running facilitated sessions, with decisions still made by members | Governance facilitation, contract drafting input, risk and legal review |
| Chaincode business logic | Rules that define assets, transfers and approvals should be owned by the business team that will maintain them | Engineering support for packaging, lifecycle commands, testing harnesses and deployment pipelines | Go or Node.js development, Fabric chaincode lifecycle, unit and integration testing |
| Channel and topology design | Sign-off on which organizations join which channels and which data is private | Designing the topology, organization count, peer placement and channel layout against the agreed requirements | Fabric operations, network architecture, consensus trade-off analysis |
| Raft or BFT ordering configuration | Choosing the ordering model and the organizations that host orderers | Configuring consenters, sizing the cluster, validating failover and quorum behavior | Fabric operations, distributed systems, Linux administration |
| CA, MSP and PKI setup | Policy on certificate authority hosting, identity sources and revocation responsibilities | Installing Fabric CA, connecting identity sources, building MSP definitions and certificate renewal routines | PKI, Fabric CA administration, LDAP or directory integration |
| HSM and custom image work | Decision on whether MSP keys must sit in an HSM and who holds HSM administration credentials | Building custom images with PKCS#11 support and integrating HSM access on peers and orderers | HSM administration, PKCS#11, container image build pipelines |
| Infrastructure and Kubernetes platform | Cloud accounts, data center or air-gapped hosting choices and security approvals | Deploying Kubernetes or VM hosts, storage, network policy and ingress for each node | Kubernetes or Linux administration, network security, storage engineering |
| Automation and testing | Acceptance criteria, business test cases and sign-off on each environment | Infrastructure as code, deployment automation, upgrade rehearsals and operations service monitoring setup | Automation tooling, CI/CD, Prometheus, test engineering |
What usually goes wrong and how to prevent it
Most Fabric delays and cost overruns trace back to decisions made late or assumptions never checked. Each card names a failure point and the step that prevents it.
Governance agreed after build starts
Teams often begin building peers and orderers before members have agreed on channel membership, endorsement policies, who can approve chaincode changes and who can admit new organizations. Rework then lands on the most expensive parts of the network. Prevention: sign off a written governance model, including the decision owner for each change type, before any node is provisioned.
Undercounting organizations that run nodes
Each member organization that hosts a peer, orderer, or Fabric CA adds infrastructure, certificates, monitoring, and staff. Plans frequently count only the lead sponsor's nodes. Prevention: list every member that will operate its own node, then cost each one separately for hosting, HSMs, and on-call coverage.
HSM selected before key handling is checked
Fabric uses PKCS#11 for peer and orderer MSP keys, but TLS keys must stay file-based, and the prebuilt Docker images do not include PKCS#11 support. An HSM bought before these limits are confirmed can leave the network needing custom images and a different key design. Prevention: confirm the key layout and build a custom image plan before purchasing hardware.
Unowned certificate expiry
Enrollment and TLS certificates expire, and an expired orderer or peer certificate can halt a channel without warning. When no team owns renewal, reenrollment, and revocation, the first signal is often an outage. Prevention: assign a named owner for each certificate type, record expiry dates in a shared register, and agree on the renewal runbook during design.
Raft cluster sized without node loss
A five node Raft cluster tolerates the loss of two nodes, but a cluster sized only for normal operation has no margin for maintenance or failure. Orderers spread across too few sites or organizations also share the same failure modes. Prevention: size the cluster so that a planned upgrade on one node and an unplanned failure of another still leave a majority, and spread orderers across organizations and sites.
Consortium decision time left unbudgeted
Channel design, policy changes, onboarding reviews, and upgrade approvals all consume time from legal, security, and business representatives in each member organization. This effort rarely appears in infrastructure estimates. Prevention: ask each member to name its decision makers and estimate their availability, then include that staff time in the plan as a recurring line item.
Legacy version dependencies found late
Fabric v3.0 removed Solo and Kafka ordering and the v1.x legacy chaincode lifecycle. Networks still on Kafka ordering or legacy chaincode must migrate before they can upgrade, and that work is often discovered during the upgrade itself. Prevention: audit the current ordering type, chaincode lifecycle, and binary versions on every node during discovery, and schedule migration work before choosing the target release line.
How the work changes by starting point
A new consortium network carries the most governance work, because membership, policies and roles must be agreed before any node is built. Effort concentrates in the early decisions and in the time members need to reach agreement.
- First decisions: the list of member organizations, which organization operates each orderer and peer, the endorsement and channel policies, and who signs changes to the consortium definition.
- Governance time: members often need several rounds of review on policies and data sharing rules. Ask for this to be scoped as a separate phase in the quote.
- Ordering layout: confirm how many orderers each member runs and whether the consortium plans Raft or BFT ordering, since this sets the node count per member.
- Confirm with the platform team: which member hosts the first certificate authority, how enrollment is bootstrapped for each organization, and who owns the initial channel genesis material.
- Recurring: every later membership change repeats part of this governance cycle, so ask how changes are handled after go-live.
A pilot run by one organization is smaller in governance effort, but it should be designed so that adding members later does not force a rebuild. Most of the cost comes from choices that are hard to change after the first channel exists.
- First decisions: the naming and MSP structure, the certificate authority layout, and the channel model, because these carry into any future member.
- Growth path: confirm how a second organization would join, including whether the pilot's orderers can be extended or must be replaced.
- Scale assumptions: write down the expected peer count and ordering node count for the pilot and the target state, so the quote covers both.
- Confirm with the platform team: whether the pilot runs on the same infrastructure planned for production, and which parts of the pilot are throwaway.
- Recurring: a pilot still needs monitoring, certificate renewal and upgrade planning from the first day, even with a single operator.
The hosting model changes how nodes are deployed, restarted and recovered, but not the Fabric design itself. The choice is mostly an operations decision, and it changes which runbooks and tooling your team must maintain.
- First decisions: the platform for peers, orderers and Fabric CA, the storage class for ledgers, and how secrets and TLS material are delivered to each node.
- Kubernetes effort: operators or Helm charts, pod disruption rules and persistent volume planning add build time, and your team must know how to manage them.
- Virtual machine effort: configuration management, service supervision and manual rolling upgrades take more operator time at each upgrade.
- Confirm with the platform team: which clusters or hypervisors are already supported, whether the organization has an existing ingress and certificate pattern, and who patches the host layer.
- Recurring: whichever model you choose, the upgrade procedure has to be rehearsed on it before a production change.
A network with no internet access changes how software, images and dependencies enter the environment. The Fabric design stays the same, but supply chain steps and offline support become substantial parts of the work.
- First decisions: how container images and Fabric binaries are mirrored in, and whether custom images are needed. Note that the prebuilt Docker images are not built with PKCS#11, so HSM-backed MSP keys require custom images.
- HSM planning: confirm which HSM is approved, how it is reached from the nodes, and that TLS keys stay file-based, as Fabric requires.
- Upgrade supply chain: every patch release must be staged into the restricted environment before it can be applied, so ask how this is scheduled.
- Confirm with the platform team: what approval process governs new software, where logs and metrics are kept, and whether external certificate authorities are permitted.
- Recurring: offline mirrors, HSM firmware and custom image rebuilds recur with every Fabric release.
When a regulator expects evidence, the build must produce records as it runs, not only a working network. The effort moves toward controls, logging and documented decisions, and the evidence itself is assessed by the regulator or an independent auditor.
- First decisions: which controls the regulator expects, how identity and certificate issuance are documented, and where access and change records are retained.
- Evidence design: plan operations service metrics, log retention and backup records as deliverables, not side effects.
- Certificate records: confirm how enrollment, renewal and revocation events are logged and how certificate revocation lists are published and reviewed.
- Confirm with the platform team: which control framework applies, who owns each control, and which parts the regulator will sample.
- Recurring: evidence collection, access reviews and control testing repeat on a schedule set by the regulator and your internal policy. DeployOpen prepares the systems and evidence, but independent auditors and certification bodies issue any assessment outcome.
What the client needs to provide
Missing owners and late governance decisions are the most common causes of schedule slippage on a Fabric build. Before work starts, the client should name one accountable owner for each member organization, along with a deputy who can approve configuration and access requests when the primary owner is unavailable. Each owner needs authority to commit their organization's peers, orderers, Fabric CA and key custody arrangements, not just to attend meetings.
The consortium should also bring a signed or at least a draft governance charter. It needs to settle which organizations are members, how channel membership and endorsement policies are agreed, how a new member joins, and how a member leaves. Engineers cannot finalize MSP definitions, channel policies or orderer placement until these answers exist. Ask for the charter draft at least as early as the first technical workshop, and confirm who can sign off changes to it.
Several technical decisions must be made in writing before design starts. These include the ordering service (Raft or BFT, and how many orderers each organization runs), the HSM vendor and key custody model for peer and orderer MSP keys, and the identity source Fabric CA will use. For the identity source, the client must provide a read-only LDAP service account, directory base DNs, and network routes from the Fabric CA hosts. Also agree on the hosting platform, network paths between organizations, DNS and TLS naming conventions, and the change windows in which orderer and peer restarts may occur.
Finally, name a single decision-maker for scope changes, with authority to accept cost or timeline impacts. Without one, requests from different member organizations stall in review. Ask the client to confirm in writing who that person is and how quickly they will respond during the build.
Frequently asked questions
Does Hyperledger Fabric have a license fee?
No. Hyperledger Fabric is licensed under Apache 2.0, so the software itself carries no license fee, and Fabric has no paid edition. Cost sits in the infrastructure, HSMs, certificate operations, monitoring and the staff each member organization needs to run its peers and orderers. Ask your partner to separate one-time build costs from recurring operating costs in the quote, and to show which consortium member pays for each line.
How long does a Fabric build take and why?
No single duration fits every network, because the timeline follows scope. The main factors are how many organizations join, how many peers and orderers each runs, how many channels and chaincode packages are designed, and whether certificate authorities, HSMs and extra environments are built in parallel. Governance work, such as agreeing endorsement policies and onboarding rules across organizations, often lengthens the schedule more than the technical build. Request a timeline in the written quote that lists these drivers and the decisions each phase depends on.
What does a Fabric implementation cost, and what changes the price?
The price follows the written scope, and DeployOpen does not publish a price list. The main cost drivers are the number of organizations, peers, orderers and certificate authorities, the number of environments, whether keys must sit in HSMs, and how much consortium governance support is included. Ask for one-time costs (design, build, testing and go-live) shown separately from recurring costs (node hosting, HSM service, monitoring, upgrades and any support retainer), with the member responsible for each line.
Can our own team build a Fabric network without a partner?
Yes, a capable team can build one, but the work spans more disciplines than installing nodes. It includes channel and chaincode design, Fabric CA and MSP identity, HSM integration, operations monitoring and upgrades that must follow the documented order. Many teams underestimate the governance agreements that must be signed before the network can start. Assess your team against those disciplines first. If you want most work kept in-house, ask a partner to scope only the gaps.
What must our organization provide before a Fabric build starts?
Your organization supplies the infrastructure, people and decisions. Typical inputs include the cloud accounts, data centers or air-gapped networks where nodes will run, network access rules between member sites, DNS and TLS certificate policy, the identity source for enrollment such as an LDAP directory, the HSM choice if keys must stay in hardware, and a named owner in each member organization. Governance inputs matter as much: a signed consortium charter, an endorsement policy, and onboarding and offboarding rules. Confirm the exact list in the written scope.
Should we choose Raft or BFT ordering for Fabric?
Choose Raft unless you have a specific reason to need Byzantine fault tolerance. The Fabric documentation recommends Raft, which is crash fault tolerant and keeps working while a majority of nodes are available. A five node Raft cluster tolerates the loss of two nodes. BFT ordering, based on SmartBFT, arrived in v3.0 and tolerates failures of up to, but not including, one third of ordering nodes. Byzantine faults include nodes that behave arbitrarily, not only nodes that stop. BFT therefore requires a larger ordering set, so confirm your threat model and orderer count before deciding.
Should we start on Fabric v2.5 LTS or v3.x?
The Fabric documentation states that v2.5 remains the long-term support release for production users, and the 2.5 LTS and 3.x lines both receive patch releases in parallel. Choose v3.x if you need BFT ordering or Ed25519 alongside ECDSA for MSP signing, and confirm that your client applications and tooling support it. Choose v2.5 LTS if its support model fits your requirements. Either way, v3.0 removed Solo and Kafka ordering and the v1.x lifecycle, so Kafka networks must migrate to Raft before any upgrade.
What is on the consortium side versus the partner side?
The consortium keeps decisions and ownership. That covers the governance charter, which organizations join, endorsement and channel policies, data classification, and who operates each peer and orderer after go-live. The partner handles scoped delivery, including design documents, configuration, Fabric CA and MSP setup, HSM integration if it is in scope, operations service monitoring, testing, runbooks and handover. Each member organization runs its own nodes and keys, so write responsibilities per organization. Agree the split and the post go-live support terms in the written scope.
How DeployOpen scopes, delivers and supports Fabric work
DeployOpen plans, implements, hardens, documents and supports Hyperledger Fabric networks inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, so the written scope sets the deliverables and the basis for the quote.
How we scope
- We agree the written scope before work starts, covering organizations, peers, orderers, certificate authorities and environments.
- Scope maps the consortium governance decisions, such as endorsement policies and member roles, that drive build effort.
- Our quote follows from that written plan, including HSM, certificate lifecycle and monitoring needs.
How we build
- Build sequence starts with channel and organization design, then identities, ordering, peers and client applications.
- Fabric CA, TLS and MSP key handling is configured in the target environment, including HSM-backed keys.
- Each environment is tested, with peer and orderer operations endpoints, health checks and monitoring wired in before go-live.
How we hand over
- Handover covers the network topology, channel configuration, policies and certificate inventory as written documentation.
- Runbooks cover backups before each change, rolling upgrades and how to renew or revoke certificates.
- Your team receives the configuration, scripts and deployment definitions for the infrastructure you control.
How we support
- Post go-live support is available as a retainer covering upgrades, patches and questions on Fabric 2.5 or 3.x.
- Upgrade work follows the four-step guide: backup, orderer rollout, peer rollout, then channel capability updates.
- Fabric 3.x and 2.5 LTS receive parallel patch releases, so the chosen line is confirmed before planning.
