Hyperledger Development: Choosing and Building on Fabric, Besu and Friends

"Hyperledger" is not one blockchain but a family of open-source projects, now hosted by LF Decentralized Trust. For most enterprise builds the real choice is between Hyperledger Fabric, a permissioned ledger with chaincode and fine-grained privacy, and Hyperledger Besu, an Ethereum client that can run private EVM networks. This guide covers how to choose, how a Fabric or Besu project is actually built, and what it takes to run one in production.

The Hyperledger landscape in 2026

In 2024 the Hyperledger Foundation became part of LF Decentralized Trust, a broader Linux Foundation umbrella that also hosts identity, cryptography and interoperability projects, including Hiero (the open-source codebase behind Hedera). The Hyperledger brand remains on the major projects. Some older ones are inactive or archived, so check a project's release activity before you build on it.

If you want a conceptual introduction rather than a build guide, the companion article Hyperledger development explained covers the history and concepts.

Fabric vs Besu: how to decide

Choose Fabric when participants need to see different subsets of data, when you need endorsement rules like "a transaction is valid only if the buyer's and seller's organizations both sign," and when nothing will ever need to touch a public chain. Choose Besu when your team knows Solidity, when you want standard Ethereum wallets, libraries and auditors, or when tokens might eventually move to a public network. Besu's own private-transaction feature (built around Tessera) has been deprecated, so privacy on Besu now comes from network-level permissioning, separate networks per confidentiality domain, or keeping sensitive data off-chain.

Corda and Quorum compete in the same space; see Corda development and Quorum development for comparisons.

How Hyperledger Fabric works

Fabric uses an execute-order-validate model, unlike the order-then-execute model of most blockchains:

1. A client application sends a transaction proposal to endorsing peers.
2. Each peer simulates the chaincode against its copy of world state and returns a signed read-write set without committing anything.
3. The client gathers enough endorsements to satisfy the endorsement policy and submits them to the ordering service.
4. Orderers sequence transactions into blocks. Raft is the common crash-fault-tolerant option, and Fabric 3.0 added a Byzantine-fault-tolerant ordering service (SmartBFT) for networks where orderer operators do not fully trust each other.
5. Every peer validates endorsements and checks the read set has not changed (MVCC), then commits valid transactions to its ledger.

The key building blocks:

• Organizations and MSPs. Each organization has its own certificate authority (often Fabric CA) and Membership Service Provider defining its identities.
• Channels. Separate ledgers shared by a subset of organizations. Useful but operationally heavy; do not create one per relationship unless you must.
• Private data collections. Data shared peer-to-peer among authorized organizations, with only a hash on the channel ledger. Often a better tool than extra channels.
• World state. LevelDB for key-value access, or CouchDB if you need rich JSON queries (at a performance cost).

Writing and deploying chaincode

Chaincode (Fabric's term for smart contracts) is written in Go, Java, or JavaScript/TypeScript using the contract API. It is deterministic business logic: read keys, apply rules, write keys, emit events. Common mistakes are non-determinism (calling external APIs, using local time or random numbers, iterating maps in Go), which causes endorsements to disagree, and key designs that create MVCC conflicts under concurrent updates. Composite keys and careful key layout fix most hot-key problems.

Deployment uses the Fabric lifecycle: package the chaincode, install it on each organization's peers, have enough organizations approve the definition, then commit it to the channel. Upgrades follow the same path with a new sequence number, which means chaincode changes are a governance event, not just a deploy. Running chaincode as an external service (chaincode-as-a-service) fits Kubernetes environments better than having peers build containers.

Client applications should use the Fabric Gateway client API (available for Go, Node.js and Java), which replaced the older per-language SDKs. The Fabric documentation has current lifecycle and gateway guides.

Building a private network with Besu

A private Besu network uses a proof-of-authority consensus protocol; QBFT is the recommended choice for enterprise use, giving Byzantine fault tolerance with immediate finality among a known validator set. Permissioning restricts which nodes can connect and which accounts can transact. From there, development is ordinary EVM work: Solidity contracts, Foundry or Hardhat, OpenZeppelin libraries, and standard wallets or custody providers. Gas price can be set to zero on a private network, though leaving metering on protects against runaway contracts. The general practices in private blockchain development apply.

Operating a Hyperledger network in production

The code is the smaller half of the job. Production networks need:

• Certificate lifecycle management. Expired TLS or enrollment certificates are a classic cause of Fabric outages. Automate renewal and alert well before expiry.
• Kubernetes deployment. Operators and tools such as Hyperledger Bevel automate peers, orderers and CAs across organizations.
• Key protection. HSM support via PKCS#11 for organizational signing keys.
• Monitoring. Peers and orderers expose Prometheus metrics; track block height, endorsement latency and ledger size.
• Backups and recovery. Plan how a peer rejoins or rebuilds from other members.
• Governance. Who can add organizations, change policies and approve chaincode upgrades, written into the consortium agreement.

Middleware: when FireFly saves time

Most Fabric and Besu projects end up writing the same supporting code: an API layer for business applications, event listeners that push ledger events into queues, a store for documents that should not go on-chain, private messaging between organizations, and token handling. Hyperledger FireFly packages these as a "supernode" that each organization runs alongside its blockchain node, exposing REST APIs and event streams to existing systems. It can save months on a multi-party build, but it is another substantial component to operate and upgrade. Use it when you need several of those capabilities; skip it when your application only submits a handful of transaction types.

Team, timeline and cost drivers

These are reasoned estimates for a moderately complex workflow. The biggest drivers are the number of organizations, integration with ERP or core banking systems, privacy design (channels and collections), and who operates nodes. Multi-organization networks are slowed more by legal agreements and onboarding than by engineering.

Where Hyperledger projects go wrong

• Building a network nobody else joins. Secure partner commitment before production.
• Over-engineering privacy with dozens of channels instead of private data collections.
• Treating it as a database replacement. Fabric is slower and more complex than a database; it pays off only where shared trust is the problem.
• Ignoring upgrades. Running an old Fabric version for years makes later migration painful; budget for regular upgrades within the supported releases.

Use cases where Fabric has seen real adoption include trade and supply chain traceability (see supply chain development) and inter-bank or insurance workflows. For the broader question of whether a permissioned ledger is right for you, start with enterprise blockchain solutions.

What to ask a Hyperledger development team

• Which Fabric or Besu versions have they run in production, and how did they handle upgrades?
• How do they design keys to avoid MVCC conflicts?
• How are certificates issued, rotated and monitored across organizations?
• Will each member organization be able to run its own nodes, or does one party host everything?
• What is the exit plan if the consortium changes its platform?

Frequently asked questions