Besu is the Java execution client, which means you still need a consensus client

An execution client paired with a consensus layer, not a chain of its own

The most important sentence in the README is short: Besu is an execution client and must be paired with a consensus client. That single constraint defines the audience. Anyone evaluating a full node for production cannot stop at Besu alone, and the README names the pairing explicitly, pointing at Teku as the consensus client and the Teku Discord as the place for questions about that combination.

What Besu itself is, in the project's own words, is an Apache 2.0 licensed, Mainnet compatible Ethereum client written in Java. That combination of properties matters for corporate adoption. Apache 2.0 has an explicit patent grant and is the licence most enterprises expect from infrastructure software, and Java keeps the deployment story familiar to teams that already run JVM services.

The audience that follows is a mainnet operator or an enterprise deployment rather than a developer experimenting with smart contracts. The documentation set the README links to is oriented that way: system requirements, troubleshooting peering, troubleshooting performance, configuring ports, understanding metrics, and configuring the JVM. Every one of those is an operator concern, not a developer one.

The Gradle module layout mirrors the execution layer

The repository top level shows how the client is decomposed, and the directories read like a protocol implementation laid out by concern. There is an `ethereum/` module for the chain logic, an `evm/` module for execution, `consensus/` for the interface Besu expects a consensus client to satisfy, and `crypto/` for the cryptographic primitives. Data shapes live in `datatypes/`, and general purpose code in `util/`.

Around that core sit the operational modules. `metrics/` handles the monitoring endpoints the documentation refers to when it talks about understanding metrics, and `nat/` is the natural place for network address translation concerns, which is exactly what stops a hosted node from being reachable. `services/` holds long-running services, `platform/` platform-specific code, and `plugins/` plus `plugin-api/` the plugin surface. `app/` is the launch layer, and `docker/` alongside a `.dockerignore` says a container image is part of the intended distribution.

`acceptance-tests/` and `testfuzz/` show that testing is treated as a first-class part of the build rather than an afterthought, and `config/` holds configuration material. The build itself is Gradle, with `build.gradle`, `settings.gradle` and the `gradlew` wrapper checked in.

Install the binary, then read the system requirements first

The README does not inline an install command. It points operators to the binary distribution instructions in the Besu user documentation, and the GitHub releases page is where builds are published. Any command shown here would be invented, so the honest starting point is the documentation page it names.

What the README does give is the shape of what comes next. Before launching anything, the documentation's system requirements page sets the expectation for disk, memory and CPU. Configuring the JVM is called out as its own task with a dedicated page, which is the expected shape for a JVM process that runs a full chain: the garbage collector settings and heap size are part of the deployment, not an afterthought.

Network exposure is the second thing to settle. The README links a page on configuring ports and another on troubleshooting peering, and the `nat/` module in the source tree is a reminder that discovery and reachability are the two separate problems. Besu publishes metrics, and the documentation has a page devoted to understanding them, so a monitoring target should exist before the first long run.

Dependency verification needs four Gradle flags or CI breaks on a clean clone

The one part of the README that documents a concrete command is dependency verification, and the detail matters for anyone touching the build. The project uses Gradle dependency verification, so every resolved artifact is checked against recorded checksums in `gradle/verification-metadata.xml`. Adding or updating a dependency, or bumping `apiBaselineVersion`, means regenerating that file:

./gradlew --write-verification-metadata sha256 --refresh-dependencies --rerun-tasks --no-parallel updateVerificationMetadata

All four flags are mandatory and the task fails fast when any is missing. `--refresh-dependencies` and `--rerun-tasks` make the regeneration behave like a clean checkout, because cached metadata and cached task results can otherwise produce a file that passes locally and fails on a fresh clone. `--no-parallel` is required since `generateLicenseReport` resolves cross-project configurations under an exclusive lock that only serial execution provides.

The reason the file is so large is spelled out too. It records binary and source JARs of every dependency, and the source JARs are needed because IntelliJ downloads sources automatically and fails to sync when a checksum is missing. It records the `.pom` of every dependency as well, resolved through the license report, because ordinary resolution prefers Gradle Module Metadata over the `.pom` and the POM checksums are never written otherwise. Plugin JARs, including those declared in subproject `plugins {}` blocks, and the released Plugin API baseline used by `:plugin-api:checkAPICompatibility` round out the list.

To check the metadata without modifying it, which is what CI runs:

./gradlew verifySourceArtifacts

Profiling and reference tests are documented as separate workflows

Two debugging paths get their own documentation files rather than living in the README, and both matter operationally.

Profiling uses Async Profiler, described as a low-overhead sampling profiler. Setup and usage are in the profiling guide at `docs/PROFILING.md`. The stated targets are block processing, transaction validation and EVM execution, and one operational constraint is called out: the profiler must be run as the same user that started the Besu process. Attaching a profiler as a different user is the kind of failure that costs an afternoon.

Correctness verification goes through `REFERENCE_TESTS.md`. Besu supports running Ethereum reference tests and generating opcode-level JSON traces, which is the mechanism for checking execution behaviour rather than guessing at it. The repository also ships `BENCHMARKING.md`, so performance comparison has a documented path as well.

These three documents are the difference between a client you can operate and one you can only restart. Note that the README does not document any rollback procedure or state migration for an existing chain database, so an upgrade plan for a node already holding data needs more than the README.

Version cadence is monthly and the release notes live in CHANGELOG.md

The recent release tags tell you what kind of project this is. 26.8.0 shipped on 2026-08-19, 26.8.1 followed on 2026-09-01, and 26.9.0 landed on 2026-09-25. The naming convention encodes year and month, and the spacing between them is a few weeks, so an operator should expect a monthly upgrade rhythm rather than an annual one.

The last push to the repository was on 2026-10-15, and the project is not archived. That is the current state, and it says nothing about the client's share of the network; treat the tag cadence as the only reliable upgrade signal.

Release notes live in `CHANGELOG.md` at the repository root, and the README describes the GitHub repository as the place that tracks recent releases, patch notes and known issues with status on fixes and mitigations. That is where to look before applying a monthly tag to a mainnet node. The project also has `SUPPORT.md`, `SECURITY.md` and `CHARTER.md`, which is the governance shape an enterprise buyer will want to see, plus `NOTICE` and `LICENSE` under Apache 2.0.

Version announcements are posted in the Besu Discord announcements channel, and the team occasionally posts emergency alerts and support information on Discord and on X. An operator watching a monthly cadence should treat those channels as part of the upgrade procedure, because that is where urgent network information appears first.

Where Besu is the wrong choice

Two cases stand out. The first is a team that wants one process to run a chain. Besu cannot do that on its own; it needs a consensus client alongside it, so pairing adds another client to operate and coordinate. If that operational surface is unacceptable, the problem is structural rather than a configuration mistake.

The second is a team without JVM competence. Besu is written in Java, the documentation devotes a page to passing JVM options, and the build is Gradle. The code itself is readable by any Java developer, but tuning heap and garbage collection for a chain synchronizer is a specialty. The same applies to the build: the dependency verification procedure in the README is already intricate, with source JARs, POM checksums and an exclusive lock, and that is only for contributors.

A third limit is worth stating plainly. The README is a support and community document. It links to operator documentation rather than reproducing it, so details on hardware sizing, port choices, metrics semantics and consensus pairing live outside the repository. Anyone who needs a self-contained reference will not find it here.

Editorial conclusion

Besu fits teams that already operate JVM infrastructure and want an execution client under Apache 2.0 with reference tests, JSON tracing and a documented profiling path. It does not fit anyone expecting a single binary that runs a chain on its own, because the README states it is an execution client and must be paired with a consensus client, and the repository does not document an in-process consensus implementation. Before deploying, read the system requirements and port configuration pages in the Besu documentation, confirm your JVM flags against the JVM options guide., since the README itself routes operators to those pages for the decisions it does not cover.

Frequently asked questions

Official sources

1. besu-eth/besu on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases