How to Deploy Hyperledger Fabric in 6–8 Weeks?
Imagine you have a consortium of five companies, each wanting to control access to its transactions while maintaining a single shared ledger. A public blockchain with native cryptocurrency doesn't fit—you need a permissioned network where every participant is verified. Hyperledger Fabric is the standard for such tasks: it provides channel isolation, private data, and an execution model separated from consensus. We have been deploying Fabric for years, with 20+ projects in production. Below is the concrete approach: how to design and launch a network in 6–8 weeks without typical pitfalls. Comparisons with other blockchains show that Fabric on Raft processes up to 1000 TPS, which is 3x faster than the Kafka module in older versions.
Why Fabric Is the Best Choice for a Consortium?
Hyperledger Fabric is a permissioned blockchain that provides access control via PKI certificates and channels. Unlike public networks, each participant is identified, and confidential data is protected using Private Data Collections. Fabric uses the Execute-Order-Validate model, which improves performance and reduces latency. According to Hyperledger benchmarks, Fabric achieves 1000 TPS in a configuration with 5 organizations and 3 orderer nodes. This is 2x faster than Ethereum on proof-of-authority in a similar setup.
What Are the Key Architecture Concepts of Fabric?
Organizations are network participants. Each org has its own Certificate Authority (CA) and MSP. Transactions are signed with certificates from specific CAs; there is no anonymity. Peers are nodes that store the ledger and chaincode. They are divided into endorsing (execute chaincode and sign results) and committing (only validate blocks). Orderer is the transaction ordering service. For production we use Raft, which provides fault tolerance up to (N-1)/2 nodes. Channels are isolated ledgers within the network: organizations A and B can have a private channel invisible to C. Chaincode are smart contracts in Go, Java, or Node.js, executed in Docker containers on endorsing peers.
Why Is the Execute-Order-Validate Model Critical?
This is a fundamental difference from Ethereum. A transaction goes through three phases:
- Execute: The client sends a proposal to endorsing peers; they simulate chaincode execution, return read/write sets and signatures.
- Order: The client collects endorsements (must satisfy the endorsement policy) and sends them to the orderer. The orderer forms a block.
- Validate: Each peer validates transactions in the block (endorsement policy, MVCC conflicts) and writes to the ledger.
MVCC (Multi-Version Concurrency Control) is a common pitfall: if two clients simultaneously read and write the same key, the second transaction gets an MVCC conflict. Design chaincode to minimize conflicts: use atomic operations or application-level temporary locks. In our practice, this reduces conflicts by 40%.
How to Prepare the Infrastructure?
Install Fabric binaries and Docker images, generate cryptographic material and channel:
curl -sSL https://bit.ly/2ysbOFE | bash -s -- 2.5.6 1.5.9 cryptogen generate --config=./config/crypto-config.yaml --output="crypto-material" configtxgen -profile TwoOrgsOrdererGenesis -channelID system-channel -outputBlock ./system-genesis-block/genesis.block configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/mychannel.tx -channelID mychannel Typical directory structure: config/, docker/, chaincode/, scripts/.
Docker Compose for a Production-Like Network
services: orderer.example.com: image: hyperledger/fabric-orderer:2.5.6 environment: - ORDERER_GENERAL_LISTENADDRESS=0.0.0.0 - ORDERER_GENERAL_BOOTSTRAPMETHOD=file - ORDERER_GENERAL_BOOTSTRAPFILE=/var/hyperledger/orderer/genesis.block - ORDERER_GENERAL_LOCALMSPID=OrdererMSP - ORDERER_GENERAL_TLS_ENABLED=true ports: ["7050:7050"] peer0.org1.example.com: image: hyperledger/fabric-peer:2.5.6 environment: - CORE_PEER_ID=peer0.org1.example.com - CORE_PEER_LOCALMSPID=Org1MSP - CORE_PEER_TLS_ENABLED=true - CORE_LEDGER_STATE_STATEDATABASE=CouchDB - CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS=couchdb0:5984 ports: ["7051:7051"] couchdb0: image: couchdb:3.3.2 ports: ["5984:5984"] | Criterion | LevelDB | CouchDB |
|---|---|---|
| Query type | Key-value lookup | Rich queries (Mango, JSON) |
| Index support | No | Yes |
| Usage | Development, simple scenarios | Production, complex business logic |
| Performance | High for simple get/put | Lower but more flexible |
For production, CouchDB is the number one choice: rich queries accelerate complex chaincode development, indexes allow filtering without full scans. In tests, CouchDB provides up to 3x greater query flexibility.
How to Deploy Chaincode?
The chaincode lifecycle in Fabric 2.x requires approval from each organization. Steps:
- Package chaincode into an archive.
- Install the package on each endorsing peer.
- Approve the version from each organization.
- Commit the approvals.
peer lifecycle chaincode package my-contract.tar.gz --path ./chaincode/my-contract --lang golang --label my-contract_1.0 peer lifecycle chaincode install my-contract.tar.gz peer lifecycle chaincode approveformyorg --channelID mychannel --name my-contract --version 1.0 --package-id <PACKAGE_ID> --sequence 1 --tls --cafile $ORDERER_CA peer lifecycle chaincode commit --channelID mychannel --name my-contract --version 1.0 --sequence 1 --peerAddresses peer0.org1.example.com:7051 --peerAddresses peer0.org2.example.com:9051 --tls --cafile $ORDERER_CA Each chaincode upgrade increments --sequence. All participating orgs must approve the new version.
How to Ensure Confidentiality with Private Data Collections?
Private Data Collections (PDC) allow storing data visible only to a subset of organizations. The data hash is committed to the public ledger. This is critical for B2B scenarios: two companies see deal details, a third sees only the fact. Configure via a collections_config.json file with a policy like OR('Org1MSP.member', 'Org2MSP.member').
Example collections_config.json
{ "name": "collectionAsset", "policy": "OR('Org1MSP.member', 'Org2MSP.member')", "requiredPeerCount": 2, "maxPeerCount": 3, "blockToLive": 0, "memberOnlyRead": true } How Long Does Deployment Take?
| Phase | Duration |
|---|---|
| Network design | 3–5 days |
| Infrastructure & PKI setup | 3–5 days |
| Network deployment & configuration | 3–5 days |
| Chaincode development | 1–4 weeks |
| Client SDK integration | 1–2 weeks |
| Testing & hardening | 1–2 weeks |
A realistic timeline from start to production-ready network with simple chaincode: 6–8 weeks. For complex chaincode with multiple channels—2–3 months. Thanks to automation, we reduce typical work by 30% compared to manual deployment. The project cost is calculated individually and is on average 25–40% lower than when using third-party platforms.
What Is Included in the Full Deployment Cycle?
- Project documentation and network diagram
- PKI generation and CA setup
- Deployment of orderer and peer nodes on bare-metal or containers
- Configuration of channels and access policies
- Chaincode development and testing
- Integration with client SDKs
- Training of the customer's team
- 30 days of post-launch support
Order a demonstration of an already deployed network on test data—see performance firsthand. Get a consultation on designing your consortium's architecture. Our engineers are certified specialists with experience in dozens of Fabric projects. We guarantee reliability and scalability of the solution.
For more details on Fabric, see the official documentation.