Block explorers for private Besu networks: what Chainlens and Blockscout add and what they need
Operators and auditors who run a private Hyperledger Besu network often need to see blocks, transactions and contracts without querying the node by hand. The Besu documentation lists Blockscout and Chainlens as block explorers for networks running Besu, and both read chain data from RPC nodes. That makes RPC exposure the main design decision: the explorer needs enough access to index the chain, and nothing else on the network should be reachable through the same path.
*Chainlens* is a block explorer and analytics platform for public and private EVM networks. The Besu Chainlens guide describes dashboard, blocks, transactions, contracts and events pages, and it can be added when a private network is generated with the Besu Developer Quickstart using the --chainlens true option. Chainlens may take a few minutes to index the latest blocks after the containers start, so auditors should not judge a fresh environment by its first minute of data. Confirm with Chainlens which deployment model and access requirements apply to your environment before you plan the RPC path.
*Blockscout* is an open-source block explorer that the Besu documentation lists as supporting networks running Besu. It is the option to evaluate when you need to run the explorer entirely inside infrastructure you control and keep its source and configuration under your own change control. Confirm the Blockscout version, indexing behavior and database sizing against its own documentation for your chain. Whichever explorer you choose, the Besu Chainlens guide notes that production networks must secure access to RPC nodes, so plan a dedicated read-only RPC endpoint, JSON-RPC authentication and network restrictions before the explorer goes live.
What you need before connecting an explorer
An explorer reads blocks, transactions and contract data from a Besu node over JSON-RPC, so its design depends on the network already running well. The cards below cover the network, the Besu version, the hosting decision, HTTPS and DNS, the network path and the people who own access.
A running network with an RPC node
Start with a private network that already produces blocks and has at least one RPC node the explorer can reach. Chainlens and Blockscout both index by querying a node, so a validator that is not serving RPC traffic is the wrong target. Confirm that the node you choose exposes the JSON-RPC methods the explorer needs and that it stays in sync during normal load. Decide whether the explorer should read from a dedicated RPC node so validator performance is not affected by indexing.
A supported Besu release
Pick a Besu release that is still maintained and confirm its JDK requirement before you build or deploy. The 26.6.0 release notes state that Besu requires JDK 25 to build and run, so older Java runtimes will not work on current releases. Also confirm the explorer's own version compatibility with your Besu release, since indexers may lag behind node features. Record the exact version in your change records so later upgrades can be planned against it.
A decision on where the explorer runs
Decide whether the explorer runs in the same cluster as the nodes, in a separate management network, or on a host you control outside the consensus path. Chainlens and Blockscout each bring their own database and indexing workload, which should not compete with validators for CPU, memory or disk. Confirm which team owns the explorer's patching, backups and access reviews. This is the placement that a regulator or internal auditor will ask about first.
HTTPS certificates and DNS
Besu does not terminate HTTPS natively, so the explorer's browser traffic and any exposed RPC endpoints need TLS from a reverse proxy, load balancer or ingress you operate. Plan the certificate authority, issuance and renewal process, and the internal DNS names for the explorer and the RPC endpoint. Keep the explorer's user-facing name separate from the RPC name so access rules can differ. Confirm who holds the private keys for these certificates and where they are stored.
The network path for indexing
The explorer needs a route to the RPC node and, for some components, to its database and any analytics services. Map each connection, its direction, port and protocol, and decide which segments are allowed. Limit the RPC path to the explorer's addresses rather than opening the node to a general network. Verify that the path still works after firewall changes, load balancer changes and node restarts, since indexing gaps are often caused by these events.
An owner for RPC credentials
Name one team that owns the JSON-RPC credentials the explorer uses. Besu supports a username and password credentials file or JWTs validated against a public key, and each option has a different rotation and revocation process. Store the credentials in your approved secrets tool, not in explorer configuration files, and document who can issue, rotate and revoke them. Ask the explorer vendor or the project to confirm which authentication method its indexer supports before you choose one.
Chainlens or Blockscout: how to choose for your network
For a developer or test network, the fastest route is the Besu Developer Quickstart. Generating the network with the --chainlens true option includes Chainlens in the generated environment, so you get an explorer without building the indexing stack yourself. Expect a short delay after the containers start, because Chainlens may take a few minutes to index the latest blocks before the dashboard, blocks and transactions pages show current data. This setup suits engineers who need to inspect transactions and deploy test contracts during design work. It is not a model for production, because the quickstart is built for local experimentation and its defaults were not designed for regulated access controls.
- Speed: the explorer arrives with the network, so no separate deployment is needed for the first tests.
- Coverage: Chainlens shows dashboard, blocks, transactions, contracts and events pages for the generated network.
- Throwaway data: test chains are often reset, so explorer data has no retention or audit value.
- Access: check which RPC endpoints the quickstart exposes before any network path leaves a developer laptop.
- Upgrade path: do not treat the quickstart setup as the base for a production build.
Before relying on the quickstart explorer for shared testing, confirm how the generated environment exposes its ports and who can reach them.
A production private network needs an explorer deployed as a managed service inside your infrastructure, with its own access model, backups and upgrade process. The Besu Chainlens guide notes that in production networks you must secure access to RPC nodes, so the explorer's connection to the node is a security boundary, not just a convenience. Plan the explorer's data source, its database, its network placement and who may query it before go-live. Your validators should not be exposed to the explorer's public network path, and read access should go through RPC nodes that you monitor and control.
- Network placement: decide whether the explorer sits in the same segment as RPC nodes or behind an internal gateway.
- RPC exposure: restrict the methods and origins the explorer may call, and authenticate requests as the Besu JSON-RPC documentation describes.
- Data retention: define how long indexed data stays in the explorer and how it is backed up.
- Ownership: name the team that patches, upgrades and monitors the explorer alongside the node.
- Consent for data access: confirm which auditors and operators may view transaction and contract data.
The production choice depends on the hosting, access and support answers covered in the next tab.
Chainlens and Blockscout differ in how they are sourced, hosted and supported, and the Besu documentation does not settle those questions for you. Before choosing, ask each vendor or project how the product is deployed, whether you can run it fully inside your own infrastructure or air-gapped network, and what support is available under that model. Ask whether upgrades are published as versioned releases, how security fixes reach you, and what your obligations are if you run the software yourself. Chainlens is described by the Besu docs as a block explorer and analytics platform for public and private EVM networks, while Blockscout is described as an open-source block explorer that supports networks running Besu.
- Hosting model: confirm whether self-hosting in your own cloud or data center is supported, and whether a hosted option sends your chain data outside your boundary.
- Support terms: ask what response commitments exist, in writing, for production issues.
- Upgrades: ask how releases are published and how long each version is maintained.
- Licensing: read the license for Chainlens and for Blockscout, and ask how commercial use and internal redistribution are treated.
- Feature parity: ask which features your auditors need, such as event decoding or contract verification, and confirm each is available for private networks.
Get these answers in writing from each vendor or project before you compare features, because they determine the operating cost and risk of the choice.
Connecting an explorer to a private Besu network in order
This sequence takes an explorer from a private Besu network with no explorer to one that reads from a secured node, indexes to the chain head, and returns verified data. Each step ends with a check you can repeat after every change.
Confirm the RPC endpoints the explorer needs
Your network team lists which JSON-RPC methods the explorer will call, which node will serve them, and whether that node runs in the validator or a separate read path. Agree this list with the platform owner before any explorer is deployed, because a validator should not be exposed to a browser-facing service. Done when the list names one node, its network address, and the RPC methods it will expose, and a query from the intended explorer host succeeds while the same query from an unapproved host is refused.
Place a secured gateway in front of the node
Place a read-only node or an RPC gateway between the explorer and your validators. Besu does not terminate HTTPS natively, so TLS termination belongs in a reverse proxy or gateway you control. Enable JSON-RPC authentication on the node, using either a credentials file or JWTs validated against a public key, and restrict the exposed API groups to the ones the explorer uses. Done when an unauthenticated request is rejected, an authenticated request from the explorer succeeds, and the gateway logs the caller identity for each request.
Deploy the explorer and point it at the node
Deploy Chainlens or Blockscout in the environment you chose, with the node endpoint and credentials supplied through your secret store rather than hard-coded in configuration. If you use the Besu Developer Quickstart with the --chainlens true option, that path is suited to test networks, so confirm what changes for a production network before reusing its settings. Done when the explorer container or service starts cleanly, reports a connection to the gateway address, and writes no authentication errors to its logs.
Wait for indexing to reach the latest block
Allow the explorer to index historical blocks until its latest indexed block matches the head reported by the node. The Chainlens documentation notes that indexing of the latest blocks can take a few minutes after containers start, so measure the gap instead of assuming completion. Record the indexing lag at intervals and confirm it closes and stays near zero under normal block production. Done when the explorer's latest block number equals the node's current block number and remains there across several block intervals.
Verify the block view against the node
Pick a recent block and a known older block. Query each through the node directly with eth_getBlockByNumber, then open the same height in the explorer's blocks page. Compare the block hash, parent hash, timestamp, miner or validator address, and transaction count. Done when all of these fields match for both blocks, and any mismatch is logged as a blocking defect rather than accepted as a display difference.
Verify transactions and contracts against the node
Select a transaction that deployed a contract and one that called a contract function. Compare the transaction hash, sender, recipient, status, and gas used with the node's eth_getTransactionByHash and eth_getTransactionReceipt results. For the contract, compare the deployed bytecode with eth_getCode at the contract address. Done when the transactions page and contracts page show the same status and addresses as the node, and the bytecode check matches for each deployed contract.
Verify events and the dashboard, then record the baseline
Confirm that an event emitted by a test contract appears on the events page with the correct topics and data, matching the node's log query for that block range. Check that the dashboard totals are consistent with the blocks and transactions already verified. Save the block hash, indexed height, and check results as the baseline for later comparisons, and schedule a repeat of the block and transaction checks after each node upgrade. Done when the event and dashboard checks pass and the baseline record is stored with the change ticket.
Why RPC access is the security decision for any explorer
The Besu Chainlens guide states that in production networks you must secure access to RPC nodes, and that statement should set the order of work for any explorer deployment. An explorer needs read access to blocks, transactions, receipts and contract data, and it should not need any write or administrative JSON-RPC method. Node management, peer administration, permissioning changes and transaction submission from the explorer's host are capabilities you should not hand to a web application that many people can reach. Before you connect Chainlens or Blockscout, list the JSON-RPC methods the explorer's indexer and interface actually call, then confirm that the RPC path exposes only those methods to it.
Besu gives you two authentication options for JSON-RPC. The first is a username and password credentials file. The second is externally issued JWTs, validated against a public key using RS256, RS384, RS512, ES256, ES384 or ES512. Both options protect the node's API, but the explorer has to present whichever credential your gateway enforces. If the gateway expects a bearer token, the explorer's backend must obtain and refresh that token from your identity provider, and the token lifetime and rotation must work with the indexer's long-running connection. Confirm with your team which option you will use, who issues the keys or tokens, and how a revoked credential is removed from the explorer's configuration. Besu does not terminate HTTPS natively, so the TLS termination point and the component that enforces the credential must also be decided in your design.
Which network data the explorer reads and who may see it
This table maps each explorer page to the RPC data it reads, the Besu node role that should serve it, and the audience allowed to reach it. Read it as a design input: the explorer needs read-only chain data, and the admin surfaces of your nodes must stay outside its reach. Network permissioning limits which nodes can join, but it does not decide who can query data through an explorer.
| Explorer page or data | RPC data it needs | Node role and access tier |
|---|---|---|
| Dashboard (network summary) | Latest block number, block times, peer and sync status | Read-only RPC node; members and auditors via the explorer backend |
| Blocks | Block headers and transaction hashes by number or hash | Read-only RPC node; members and auditors |
| Transactions | Transaction and receipt lookups, including logs for failed or pending status | Read-only RPC node; members and auditors, with logs visible to the same tier |
| Contracts | Contract bytecode and code at address, plus verified source if the explorer stores it | Read-only RPC node; members and auditors, verification write access limited to operators |
| Events | Filtered log queries across blocks, which can be heavy on large ranges | Dedicated RPC node with query limits; operators and auditors only, confirm range limits with your vendor |
| Admin and debug methods (for example, node management or txpool inspection) | Not required by any explorer page | Excluded from the explorer path and from any public-facing RPC, operators only on private interfaces |
| Node permissioning and account permissioning files | Not read by the explorer | Operator only; never exposed through RPC or the explorer UI |
| Private keys and node key files | Not read by the explorer | Never exposed; keep off every API path and confirm your key storage model before go-live |
Hardening the explorer and its RPC path
An explorer reads from the same JSON-RPC interface your applications and operators use, so its access path becomes part of your attack surface. The controls below separate what the explorer can reach, how that access is authenticated and encrypted, and how it is logged. Check each one in your own environment before the explorer is opened to auditors or other members.
TLS termination in front of the explorer
Besu does not terminate HTTPS natively, so encryption for explorer traffic must come from a reverse proxy, load balancer or API gateway placed in front of the RPC endpoint and the explorer web interface. Decide where certificates are issued and rotated, and confirm that traffic between the gateway and Besu stays on a segment you control. Test the full path, not only the public hostname, because an unencrypted hop inside the cluster is still exposure. Ask your platform team who owns certificate renewal and how an expired certificate is detected before it breaks indexing.
JWT or credentials enforcement at the gateway
Besu supports a username and password credentials file or JWTs validated against a public key, using RS256 through ES512. Choose one model for the explorer and enforce it at the gateway so unauthenticated requests never reach the node. Keep the signing keys or credentials file out of source control, and set token lifetimes that match how long an indexer runs. Confirm which key algorithm your identity provider issues, since a mismatch will fail silently at the gateway rather than at Besu.
Read-only RPC method allowlist
An explorer only needs read methods to build blocks, transactions and contract views. Configure the gateway to pass only those methods and reject state-changing calls such as sending raw transactions, unless a specific workflow requires them. Review the allowlist after each Besu upgrade, because method groups change between releases. Test the rejection path with a sample write request so you know the block is working before an auditor asks.
Separate indexing nodes from validators
Validators sign and propose blocks, so they should not serve public or explorer traffic. Run a dedicated non-validating node for the explorer to query and index, and let it peer with validators through the permissioning rules you already maintain. If the indexer is slow or overloaded, only the explorer suffers, not block production. Ask whether your design includes a separate sizing plan for the indexing node, since its storage and query load grow with chain history.
Segmentation and access logging
Place the explorer and its indexing node in a network zone that can reach the RPC gateway but not validator networks or key stores. Log every request at the gateway with the caller identity, method and timestamp, and forward those logs to the monitoring or SIEM platform your audit team already reviews. Define how long logs are kept and who can read them. Confirm that the explorer's own user accounts are logged too, since a shared login removes accountability.
Key handling for service credentials
The explorer should never hold node private keys. Besu's documentation states that the local node private key file is not encrypted, so that file must stay on validator and node hosts with restricted file permissions, or in a security module such as the Besu HSM plugin where your design requires it. Store explorer credentials, such as gateway passwords or JWT signing material, in a secrets manager with rotation and audit records. Review the list of places these secrets are copied during deployment.
Explorer failures and how to diagnose them
This table pairs common explorer symptoms on a private Besu network with the likely cause, the check to run and the fix. Work down the rows from the symptom you see, since several failures share the same root cause. The main takeaway is that most explorer problems trace back to the RPC path, indexing state or the node the explorer reads from, not to the explorer itself.
| Symptom | Likely cause | Check and fix |
|---|---|---|
| Blank or lagging pages right after startup | The explorer is still indexing blocks from the node. Chainlens may take a few minutes to index the latest blocks after containers start. | Compare the indexed height with the node's current block number. Wait for indexing to catch up before escalating. If progress stalls, check the indexer logs and restart the indexer, not the chain. |
| Pages show stale blocks | The explorer reads from an RPC node that is behind validators, or the indexer has stopped advancing. | Query the block number directly from the RPC node the explorer uses and from a validator. Fix the lagging node's peering or sync first, then confirm the indexer resumes. |
| RPC timeouts behind a load balancer | Requests from the explorer hit a node that is slow or unhealthy, or the balancer's idle timeout is shorter than the query time for heavy pages. | Call the same method against each backend node directly. Remove unhealthy backends from the pool, then review balancer timeouts and keep-alive settings for long-running queries. |
| Authentication failures between explorer and gateway | The explorer lacks the credentials or JWT the gateway expects, or the token has expired or was signed with a key the gateway does not trust. | Test the call with the same credentials outside the explorer. Confirm the username and password file or the JWT issuer, audience and signing key match the gateway configuration, then update the explorer secret. |
| Missing contract or event data | The indexer has not processed the blocks that deployed the contract, or the explorer is not configured to decode the contract's events. | Confirm the deployment transaction exists on the node and that the indexer height is past its block. Re-index the affected range if the explorer supports it, then verify event decoding for the contract's ABI. |
| Explorer shows a different chain head than validators | The explorer is connected to a non-validator node that has not caught up, or it points at a different network or genesis than the validators run. | Compare block hashes at a common height across the explorer's node and a validator. Confirm the chain ID and genesis match. Reconnect the explorer to a synced node in the same network. |
| Explorer unavailable after an upgrade | The Besu version or the explorer's schema expects a database state that changed during the upgrade. | Check the explorer logs for schema or RPC method errors and confirm the Besu release notes for removed API groups. Restore the explorer from its backup or update its configuration to match the node version. |
Testing the explorer before auditors rely on it
Treat the explorer as a read path that must agree with the node before anyone uses it for audit evidence. Start by reconciling the explorer against the node it reads from. Pick a sample of block numbers across the chain, including the latest blocks and a range from before the explorer was connected, then compare the block hash, parent hash, timestamp and transaction count on the explorer with the same values returned by the node's JSON-RPC interface. Repeat the check for a set of transactions per block, comparing status, sender, recipient and contract creation fields. Record the sample, the node version and the date, so the result can be repeated later. Confirm with your explorer vendor or the Besu Chainlens guide how indexing lag is measured in your deployment, since the guide notes that indexing of the latest blocks can take a few minutes after containers start.
Next, test the access controls the explorer depends on. The Besu Chainlens guide notes that production networks must secure access to RPC nodes, so the test is whether an unauthenticated or unauthorized caller can reach JSON-RPC methods directly, and whether the explorer's own service account can do only what it needs. Confirm that JSON-RPC authentication is enforced with the username and password credentials file or externally issued JWTs your configuration uses, and that requests without valid credentials are refused. Because Besu does not terminate HTTPS natively, check that the TLS termination point in front of the node is reachable only from the explorer's network segment. Then sign in as each read-only role and confirm that dashboard, blocks, transactions, contracts and events pages show the intended scope and that no page exposes actions or data outside it.
Plan retests as part of every Besu upgrade, not only at go-live. The Besu 26.10.0 release notes state that the Bonsai database auto-upgrades on first start and that older versions cannot open the upgraded database, so take a backup of the node the explorer reads from before upgrading it, and confirm that the backup restores on a separate host. After the upgrade, rerun the reconciliation sample and the access tests, and confirm that the explorer's indexer has caught up with the new head. Keep the test scripts and results in your change record so auditors can see that controls were verified after each change rather than assumed to persist.
Questions buyers ask about explorers on private Besu networks
Should we choose Chainlens or Blockscout for a private Besu network?
Choose on the views your operators and auditors need, the hosting model you can support, and what each project confirms for your Besu version. Both are listed in the Besu documentation as block explorers that work with Besu networks. Chainlens is described as a block explorer and analytics platform for public and private EVM networks, with dashboard, blocks, transactions, contracts and events pages. Blockscout is an open-source block explorer that supports Besu. Ask each project to confirm support for your exact Besu release, your genesis and consensus settings, how it indexes historical blocks, and which licence and support terms apply to your deployment. Run both against a test copy of your network before deciding.
What drives the cost of running an explorer on a private network?
Cost comes from people, infrastructure and ongoing upkeep, not from the software alone. Drivers include the number of nodes the explorer reads from, how much history must be indexed, how RPC access is exposed to the explorer, how users authenticate, where the service is hosted, and how often you upgrade it. Ask any provider, including DeployOpen, for a quote that separates one-time work (design, deployment, access controls, verification) from recurring work (hosting, patching, Besu upgrades, monitoring, access reviews). DeployOpen does not publish a price list; a quote follows from the written scope.
How long does an explorer setup take?
Duration depends on how many nodes and networks the explorer covers, how much of the RPC layer must be secured before users see it, and how many approvals your change process requires. A quick developer setup is not the same as a production deployment. The Chainlens quickstart option can include an explorer when generating a private network, but the docs note that indexing the latest blocks may take a few minutes after containers start. Production timelines should come from a written scope and a review of your environment, not from a generic figure.
Can our own team set up a Besu block explorer?
Yes, if your team has the skills to run the pieces the explorer depends on. Those include Besu node operations, container or Kubernetes deployment, database operations for the indexer, reverse proxy and TLS configuration, identity integration and monitoring. The hardest part is usually the access layer, not the explorer itself. Assess your skills against each component before deciding, and confirm the vendor's current installation guidance for your Besu version. A partner can take the work fully or carry out a fixed-scope piece, such as the access design, while your team runs the platform.
What do we need to provide for the explorer project?
Plan to provide network access between the explorer and the nodes it reads from, certificates for the public hostnames, named owners for the RPC nodes, and people who can approve access roles for operators and auditors. You will also need a decision on who can see transaction data, since an explorer makes blocks and transactions easy to browse. Confirm which network segments the explorer may reach, how your certificate authority issues certificates, and who signs off on each access tier. Write these into the scope so the quote reflects the actual dependencies.
Why must RPC access be secured before an explorer goes live?
An explorer reads from Besu JSON-RPC endpoints, and Besu does not terminate HTTPS natively, so transport security and authentication must be designed around it. Besu supports username and password credentials files or externally issued JWTs validated against a public key, using algorithms such as RS256 or ES256. The Besu Chainlens guide notes that production networks must secure access to RPC nodes. Decide which methods the explorer needs, keep write and administrative methods off public paths, and place a TLS-terminating proxy in front of nodes. Confirm the exact configuration keys for your Besu release before rollout.
Does a block explorer change our compliance evidence?
It adds a new system to the scope of your access and logging controls, so it changes the evidence you need, but it does not produce compliance evidence on its own. DeployOpen prepares systems, controls and evidence for compliance assessments, but does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that. Expect to document who can query the explorer, how access is granted and reviewed, how explorer logs are retained, and how the explorer is patched and upgraded. Confirm with your assessor which of these they will test.
How DeployOpen scopes and delivers an explorer integration
DeployOpen plans, builds, hardens and hands over block explorer deployments inside your own infrastructure, whether you choose Chainlens or Blockscout. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. Ongoing support is available as a retainer once the explorer is live.
How we scope
- We confirm which Besu nodes the explorer reads from and whether they run in your cloud, data center or closed network.
- We record which RPC methods, WebSocket endpoints and network access the explorer needs, and which must stay closed.
- The written scope names the explorer choice, the users who will see data, and the access model for operators and auditors.
How we build
- We deploy the explorer against a dedicated read path, keeping it separate from validator nodes and block-producing infrastructure.
- We place authentication, TLS termination and network controls in front of the RPC endpoints the explorer calls.
- We test indexing lag, page loads and data accuracy against transactions we submit ourselves on your test network.
How we hand over
- You receive configuration documentation covering endpoints, access rules, indexing settings and the components each one depends on.
- We document the restart, reindex and rollback steps, including the backup needed before any Besu or explorer upgrade.
- Handover includes a walkthrough with your operations and security teams so they can check the access controls themselves.
How we support
- Support covers explorer version updates, checks after each Besu release, and changes to RPC exposure as your network grows.
- Retainers can include periodic access reviews of the explorer endpoints and the credentials that reach the RPC layer.
- Continuous testing of the explorer's exposed surface can be added to a retainer, scoped in writing with your team.
