How to Deploy a Private Blockchain on Hyperledger Besu

When is a private blockchain really needed?

"We need our own blockchain" — a phrase I hear once a month. Most often, behind it is a task that can be solved with a regular database with an audit log or permissioned smart contracts on a public blockchain. But there are legitimate use cases: consortium settlements between competing companies where no party trusts the other enough to host data on its server; state registries requiring decentralization without publicity; trade networks with their own settlement token. If you fall into one of these scenarios, this guide is for you. Order a free consultation on private blockchain architecture — our engineers will help you choose the platform.

We have deployed over 50 private blockchains for financial, logistics, and government clients. Experience shows: a properly configured network runs for years without failures if architectural principles are followed. Mistakes at the start lead to loss of consensus and costly rework. A network of 4 nodes tolerates 1 failure (25% of all nodes), and 7 nodes tolerate 2 failures (28.5%).

How to choose a platform for a private blockchain?

Three real options for enterprise private blockchain:

• Hyperledger Besu — EVM-compatible Ethereum client, developed by ConsenSys, now Linux Foundation. Supports QBFT and IBFT2 consensus. Main advantage: full EVM compatibility — everything that works on Ethereum works here unchanged. Solidity contracts, Hardhat, MetaMask, ethers.js — everything works. For teams with EVM expertise, it's the first choice.
• Hyperledger Fabric — not EVM, chaincode in Go/Java/Node.js, channel architecture, MSP (Membership Service Provider) for participant management. Better suited for complex permissioned scenarios with different participant roles. More complex to operate.
• Polygon Edge / Polygon CDK — EVM-compatible, bridge to Ethereum mainnet or Polygon. If you need connection to a public blockchain, it's a good choice. Actively developed as an appchain framework.

For most enterprise tasks, I recommend Besu with QBFT: EVM compatibility opens access to a vast ecosystem of tools, and QBFT provides deterministic finality without forks.

Hyperledger Besu + QBFT network architecture

QBFT (Quorum Byzantine Fault Tolerance) is a Byzantine fault tolerant consensus. A network of N nodes tolerates up to ⌊(N-1)/3⌋ failures. For 4 nodes — 1 failure, for 7 — 2. The minimum production topology includes three validators (one per organization) and one RPC/boot node for applications.

Genesis block configuration

The genesis defines the initial state of the network. Critical parameters:

{ "config": { "chainId": 12345, "berlinBlock": 0, "londonBlock": 0, "qbft": { "blockperiodseconds": 2, "epochlength": 30000, "requesttimeoutseconds": 4 } }, "nonce": "0x0", "timestamp": "0x5B3D92D7", "gasLimit": "0x1fffffffffffff", "difficulty": "0x1", "mixHash": "0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365", "coinbase": "0x0000000000000000000000000000000000000000", "alloc": { "0xYOUR_INITIAL_ACCOUNT": { "balance": "90000000000000000000000" } }, "extraData": "0x<QBFT_EXTRA_DATA>" } 

chainId — unique network identifier. Choose one that does not conflict with public networks (list of occupied chainIds can be found on official resources).

Deployment with Docker Compose

Step-by-step instructions:

1. Generate keys and extraData using besu operator generate-blockchain-config.
2. Create genesis.json and key folders for each validator.
3. Configure docker-compose.yml with services for validators and bootnode.

version: '3.8' services: validator1: image: hyperledger/besu:latest volumes: - ./data/validator1:/data - ./genesis.json:/genesis.json - ./networkFiles/keys/validator1:/keys command: > --data-path=/data --genesis-file=/genesis.json --node-private-key-file=/keys/key --rpc-http-enabled --rpc-http-api=ETH,NET,QBFT,ADMIN --rpc-http-cors-origins=* --rpc-http-port=8545 --p2p-port=30303 --bootnodes=enode://BOOTNODE_ENODE@bootnode:30303 --min-gas-price=0 --revert-reason-enabled --metrics-enabled --metrics-port=9545 ports: - "8545:8545" - "30303:30303" 

--min-gas-price=0 disables the minimum gas fee — this is a simple gas optimization for private networks, speeding up transactions and reducing overhead.

Participant management (Permissioning)

Besu supports on-chain permissioning via smart contract. Recommended for production:

contract NodeRules { mapping(bytes32 => bool) private allowedNodes; function connectionAllowed( bytes32 sourceEnodeHigh, bytes32 sourceEnodeLow, bytes16 sourceEnodeIp, uint16 sourceEnodePort, bytes32 destEnodeHigh, bytes32 destEnodeLow, bytes16 destEnodeIp, uint16 destEnodePort ) external view returns (bytes32) { bytes32 nodeId = keccak256(abi.encodePacked(sourceEnodeHigh, sourceEnodeLow)); return allowedNodes[nodeId] ? 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff : 0x0; } } 

Adding/removing nodes is done via multisig transactions, with an audit trail on the blockchain.

How to set up monitoring and disaster recovery?

Monitoring with Prometheus + Grafana

Besu natively exports metrics in Prometheus format:

scrape_configs: - job_name: 'besu' static_configs: - targets: ['validator1:9545', 'validator2:9545', 'validator3:9545'] 

Key metrics:

• besu_blockchain_height — blockchain height (should be the same on all nodes)
• besu_peers_connected_total — number of peers
• besu_consensus_round_change_total — QBFT round changes (growth indicates problems)

An alert when height divergence > 5 blocks is mandatory.

Disaster Recovery

tar -czf validator-keys-backup-$(date +%Y%m%d).tar.gz \ ./networkFiles/keys/ \ ./genesis.json 

Store validator keys in HSM (AWS CloudHSM, Azure Dedicated HSM) and in different physical locations. Loss of keys of the majority of validators stops the network.

What's included in the work

• Engineering project: network topology, number of validators, governance model, permissioning.
• Genesis configuration and smart contracts: consensus parameters, chainId, token distribution, permission contracts.
• Deployment and testing: deployment via Docker Compose or Kubernetes, consensus verification under failures, load testing (up to 1000 TPS).
• Monitoring and documentation: Prometheus/Grafana dashboards, runbook for ops, backup procedures.
• Team training: 1-2 day workshop on network administration.
• Support: one month of post-release support with 4-hour SLA.

Work process

Total time: 1-2 weeks for a basic network. With HSM, SIEM integration — up to 3-4 weeks. Contact us for a consultation on your project — we will help you choose the platform and design a turnkey network. Our engineers are certified in Hyperledger and have 10+ years of blockchain development experience. We guarantee network fault tolerance if architectural recommendations are followed.

More details at Hyperledger Besu.