# Teku: a Java beacon node and validator client in one codebase

> Teku is the Consensys Ethereum consensus client written in Java, containing a full beacon node and a validator client. It suits operators who want one JVM process to cover both roles, and it ships as a Gradle distribution, a tarball or a Docker image.

**Consensys-Incorporated/teku** — 🚀 Open-source Ethereum consensus client written in Java

- Repository: https://github.com/Consensys-Incorporated/teku
- Website: https://consensys.com/teku
- Stars: 785 · Forks: 395
- Language: Java
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/consensys-incorporated-teku

## Teku bundles the beacon node and the validator client

Teku is an open-source Ethereum consensus client written in Java, and the README states that it contains a full beacon node and validator client implementation. That pairing is the defining decision. A beacon node follows the chain and exposes the API that clients, explorers and tooling read, while a validator client holds the keys and performs the attestations and proposals that make proof-of-stake work. The repository reflects that structure at the top level, with separate beacon/, validator/, storage/, networking/ and services/ directories. The audience is two groups. Node operators want a client they can run and monitor. Protocol engineers want a readable implementation of the consensus rules to check against the Ethereum Beacon Chain specification, which the README links as the normative reference.

## Java 25 is the floor for building and for running

The build prerequisite is stated plainly: Java 25+. The README adds a caveat that is easy to skim past. Official builds of Teku are performed with Java 25, building on a more recent version of Java is supported, but the resulting build will not work on earlier versions of Java. So the constraint is not symmetric. Compiling on Java 26 gives you something that will not start on a Java 25 runtime, which matters for container images and for operators pinning a base image. The practical implication is that the Java version in the build environment has to be tracked alongside the Teku version, and the README does not document a supported version matrix beyond this statement. Anyone automating Teku builds has to treat the JDK choice as part of the release process rather than as a local convenience.

## Gradle targets decide whether you get a tarball, a folder or an image

Building a runnable distribution is one Gradle invocation. The README clones the repository and runs two targets together:

```bash
git clone https://github.com/Consensys-Incorporated/teku.git
cd teku && ./gradlew distTar installDist
```

That produces a fully packaged distribution in build/distributions and an expanded distribution ready to run in build/install/teku. The table of useful targets names four outputs: distTar for a .tar.gz in build/distributions, distZip for a .zip in the same place, installDist for the expanded directory, and distDocker for the consensys/teku docker image. A plain build is also available:

```bash
cd teku && ./gradlew
```

The tarball and the Docker image are the two realistic deployment routes, and they differ in more than packaging. The tarball is a self contained process you manage with systemd or an equivalent supervisor. The image is built by the same Gradle project and published on Dockerhub under the consensys/teku repository, which suits an environment that already schedules containers and pulls images by tag.

## Test suites for the spec live beside the client

The repository layout is the clearest evidence of what kind of project this is. Alongside the client code sit eth-reference-tests/, fork-choice-tests/, eth-benchmark-tests/, eth-tests/, acceptance-tests/ and a fuzz/ directory, plus a specrefs/ directory. These are the harnesses used to check the implementation against the Ethereum consensus specifications, and the README even carries a badge that reads the refTestVersion out of build.gradle so the badge shows which spec release the tests track. A fuzz directory is worth noting for a consensus client, since the input space of a p2p message and of the block processing path is large enough that randomized testing is a normal part of the work. The presence of these suites is what makes Teku usable as a research and audit codebase and not only as a binary to point at a network.

## Release versions for mainnet, develop builds for testnets

Two distribution channels exist and the README is explicit about which to use. Binary releases are published on the releases page, and binary builds that track the latest changes on the master branch are available on Dockerhub using the develop version, or as tar.gz and zip downloads from the artifacts server. The guidance is that only release versions should be used for Mainnet, while develop builds are useful for testing the latest changes on testnets. The default branch is master, so anything cloned from the repository head is a develop build in effect. The release numbering follows a dated scheme: 26.9.1 on 2026-09-28, 26.10.0 on 2026-10-08 and 26.10.1 on 2026-10-15. The README also warns that the Changelog on the releases page carries details of upcoming breaking changes, which is the place to look before an upgrade.

## Style and tests are enforced by the build itself

The project follows Google's Java coding conventions, and the check is automated rather than advisory. The README gives a single command for reformatting:

```bash
./gradlew spotlessApply
```

Code style is checked automatically during a build, so a change that does not match the conventions fails before it reaches review. Unit tests run as part of the build as well, and can be triggered explicitly:

```bash
./gradlew test
```

Two things are missing from the README, and they matter for anyone planning around the build. It does not document the command line flags or the configuration file that a running node reads, so those have to be taken from the user documentation at docs.teku.consensys.io and the REST API reference. It also does not publish a minimum hardware requirement or a memory footprint. The REST API reference is documented separately, which is the interface most operators will actually consume.

## Where Teku is the wrong choice

Three situations rule it out. The first is a host where you do not want a JVM in the critical path. A consensus client carries signing keys and the machine running it is part of your security boundary, and Teku adds a managed runtime and garbage collector to that surface. The second is any deployment plan that follows master. The README restricts develop builds to testnet use, so a node that tracks the branch is running code that has not passed the release review. The third is a team that wants to read the consensus rules in a systems language and then compare implementations. Teku is written in Java, which is readable, but the same spec also has implementations in other languages, and the reference test suites in eth-reference-tests/ are what let you compare behaviour rather than prose. Teku is the wrong tool for a low level performance investigation, and it is the right one when JVM operational experience already exists.

## Apache-2.0, a dedicated changelog, and an active master branch

The project is released under the Apache-2.0 licence, which permits internal use, modification and redistribution provided the notice and licence text are kept. The repository root carries the usual governance layer for a project of this size: CHANGELOG.md, CONTRIBUTING.md, GOVERNANCE.md, CODE_OF_CONDUCT.md, SECURITY.md, a CLA.md and an AGENTS.md and an mlc_config.json. Maintenance is current. The last push was on 2026-10-22, and three releases landed in the three weeks before that, 26.9.1, 26.10.0 and 26.10.1. Renovate configuration and a codespell configuration sit in the tree, which points to a project with automated dependency and spelling checks rather than a manual maintenance routine. The upgrade cost for an operator is a version bump plus a read of the changelog, since the release notes are where breaking changes are announced in advance.

## Conclusion

Teku fits operators who already run Java on their hosts and want the beacon node and validator client in one client, plus developers who want to read a consensus implementation in Java rather than in a systems language. It is a poor fit for a mainnet deployment where you intend to track the latest master branch, since the README recommends release versions only for mainnet. Before adopting, check that your Java runtime is 25 or newer, take a tagged release rather than a develop build, and read the CHANGELOG on the releases page for the breaking changes flagged for the next version.

## FAQ

### What is Teku and what does it include?

Teku is an open-source Ethereum consensus client written in Java that contains a full beacon node and validator client implementation.

### Which Java version does Teku require?

The build prerequisite is Java 25 or newer. Official builds use Java 25, and a build made on a more recent Java release will not run on earlier Java versions.

### How do I build a Teku distribution from source?

Clone the repository and run cd teku && ./gradlew distTar installDist, which leaves a packaged distribution in build/distributions and an expanded one in build/install/teku.

### Should I run a develop build of Teku on mainnet?

No. The README recommends using only release versions for mainnet, and says develop builds are useful for testing the latest changes on testnets.

### How do I build the Teku Docker image?

The distDocker Gradle target builds the consensys/teku image, and Dockerhub carries the develop version of it for binary builds that track the master branch.

### What licence is Teku released under?

Teku is released under the Apache-2.0 licence, which allows internal use, modification and redistribution as long as the notice and licence text are kept.

## Sources

- [Consensys-Incorporated/teku on GitHub](https://github.com/Consensys-Incorporated/teku)
- [License: Apache-2.0](https://github.com/Consensys-Incorporated/teku/blob/master/LICENSE)
- [Project website](https://consensys.com/teku)
- [README](https://github.com/Consensys-Incorporated/teku/blob/master/README.md)
- [Releases](https://github.com/Consensys-Incorporated/teku/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/consensys-incorporated-teku