JReleaser: one release pipeline for a Java project and everything around it

A release tool for projects that are not only Java

JReleaser describes itself as a release automation tool for Java and non-Java projects, naming Go, Rust, Elixir and C# explicitly, and its stated goal is to simplify creating releases and publishing artifacts to multiple package managers while providing customizable options.

That second clause is the whole proposition. Publishing one artifact to one registry is a short script. Publishing to eight destinations means each destination has its own conventions: a naming scheme, a version format, a file layout, a metadata file, a checksum, an index update. The Maven repository, the Gradle plugin portal, a container registry, a Homebrew tap, a Chocolatey feed and Flathub all want different things from you, and they change independently. JReleaser exists to hold that knowledge in one place so you describe your project once.

The project is built in Java and published to Maven Central, but that is an implementation detail rather than a restriction. The topic tags cover ant, ci-cd, cli, csharp, elixir, gradle, java, maven, release, rust and tool, which is a fair summary of the ecosystem it serves.

The audience is a release engineer, or a team where one person owns the tagging, the version bump, the build, the archive creation and the upload to five different places. JReleaser takes that sequence and turns it into a single command in continuous integration.

There is also an explicit note in the README about questions, support and general discussion going to GitHub Discussions rather than an issue tracker, which is the normal convention for a project of this size and gives a useful signal about where the community conversations happen.

The download matrix, which is the clearest statement of scope

The README's downloads section is the most informative part of the file, because it enumerates every destination the tool supports and every way to install it.

For installing JReleaser itself, the destinations are: a Gradle plugin portal entry under the plugin id org.jreleaser, a Maven Central artifact for the model API, an AppImage for Linux, Homebrew formulae, Chocolatey, a Flathub entry for the CLI under org.jreleaser.cli, and three container images published to Docker Hub, named jreleaser-slim, jreleaser-alpine and jreleaser-ubi. There is also an Azure DevOps extension.

Two things stand out. The three container variants exist because JReleaser runs in continuous integration, where the image is the installation, and the trio covers the three base image conventions teams have, a slim Debian style image, Alpine and Ubi. The second is the Homebrew and Flathub and Chocolatey trio, which are for a human who wants to run the release locally before wiring it into a pipeline.

The project also advertises an OpenSSF Best Practices badge, an OpenSSF Scorecard badge, an SLSA level 3 badge, and a Reproducible Central artifact badge. Those are claims about the build and release process rather than about the features, and for a tool whose entire job is producing artefacts that other people trust, they are the relevant badges.

The Azure DevOps extension is worth noting as a specific piece of support. A release tool that only works with GitHub Actions is a release tool for one hosting provider, and an extension means the pipeline step is configured the way that platform expects.

Two documentation tracks, and a versioned configuration

The documentation structure reveals how the project handles its own release cycle, and it is a detail worth copying if you are designing the same thing.

There are two documentation sites. The guide for the current release, versioned as v1.26.0, and a separate guide for the early access track, labelled snapshot. Both are published under jreleaser.org.

That pairing only works because the tool ships a rolling early-access release alongside numbered ones. The release list here shows an early-access tag dated 2026-10-15, followed by v1.26.0 from 2026-08-31 and v1.25.0 from 2026-06-29. So there are two documentation versions, two distribution channels, and the early-access one is where new behaviour appears first.

For a user, the practical consequence is that you must know which track your configuration targets. The two are versioned separately on the site, and the current one is labelled with the project version and the other with snapshot.

The repository layout shows the same structure in code. The top level holds a VERSION file, a jreleaser.yml, a jreleaser build.gradle, settings.gradle, gradle.properties, the gradlew wrappers, a buildSrc/ directory, and then the substantive directories: core/, api/, infra/, plugins/, sdks/, licenses/, src/ and a config/ directory that is presumably the tool's own configuration for releasing itself.

The project dogfoods. There is a jreleaser.yml in its own repository root, and the configuration directory is separate, which is a reasonable arrangement for a tool that releases itself with itself.

A plugin system and an SDK layer, which is where the complexity lives

The repository structure suggests a considerable amount of machinery, and the two directories to look at are plugins/ and sdks/.

The plugins/ directory is the extension mechanism, and the fact that it is a top level directory rather than a subpackage of core/ tells you it is meant to grow independently. A release tool for a dozen ecosystems accumulates a plugin per ecosystem, and separating them keeps the core from growing in proportion to the number of destinations.

The sdks/ directory is the other half. A release tool needs to talk to package registries, container registries, Git hosts and file hosts, and each of those is an API with its own authentication model and its own client library. The presence of an SDK layer suggests the tool wraps those interactions behind its own model rather than leaking registry specific types into your configuration.

This is where the cost of the tool shows. The configuration model is factored out into a model API artifact, referenced by the project and plugin attributes, and the top level of the repository carries a jreleaser.yml. A configuration language with a model, a plugin system and SDK integrations is a system with a learning curve, and JReleaser's is steeper than a shell script.

The api/ directory and the model API artifact published to Maven Central suggest that the configuration model is a public, published thing rather than an implementation detail, which is a good sign for a tool that others may want to extend or generate configuration for.

The security posture indicators are worth one more look. The repository has a.github-secrets.tar.gpg file at the root, a CLA.adoc, a NOTICE file, a jitpack.yml, and a code of conduct linked from the shared organisation repository. The encrypted secrets archive is a signing practice, and for a tool that publishes binaries on behalf of other projects, the signing and provenance story is part of the product.

Installing it, and the documentation gap you will hit first

The README does not give a command to install JReleaser, and that is deliberate rather than an omission. The install section points to two places, both in the guide: one for a development environment and one for CI/CD systems.

That is the honest answer for a tool with this many distribution channels. There is a container image for a CI job, a Gradle plugin for a JVM build that already has a Gradle wrapper, an AppImage, a Homebrew tap, a Chocolatey package, a Flathub entry and a standalone CLI. Each of those is installed differently, and a single command in the README would only be right for one of them.

So the practical path is to pick your context and follow that page. If you are wiring this into a GitHub Actions job, the container image is the shortest route, and the three variants mean you pick the base that matches your other steps. If you are running it locally to test a configuration before committing it, Homebrew, Chocolatey or the AppImage cover the three desktop platforms, and the Flathub entry is the flatpak route.

Because the README deliberately does not include the commands, there is nothing to quote here, and any command you see in a blog post about JReleaser should be checked against the install page for the version you are actually using. The version matters more than usual for this tool, because the early access and stable documentation tracks are separate.

One more practical note. The guide links in the README carry the path /guide/latest/, which is a moving target, and separately the documentation for the current version and the snapshot. If you are writing a runbook for your team, pin the URL to a specific version rather than to latest.

When JReleaser is the wrong amount of machinery

The honest critique of a tool like this is that its complexity is only justified by breadth, and breadth is something you either have or you do not.

If your project publishes a single archive to Maven Central, JReleaser is a large configuration for one upload. The Maven publishing plugin alone handles that case, and the difference in effort is not marginal: you would write one block of configuration rather than a model that describes the project, its artifacts, its changelog, its distribution and its destinations.

The second case is a project that does not fit the model. A release tool that is good at archives, container images and native packages is a poor fit for a project whose deliverable is something unusual, a firmware image, a signed binary with a bespoke upload protocol, a package for a registry nobody has written a plugin for. In that case you are back to a shell script, and you should be.

The third case is a team that does not want a tool in the release path at all. A release process that a human runs by hand, with a checklist, is more auditable than one that runs in CI, and for a project with two maintainers and a release every few months the manual process may genuinely be lower risk. JReleaser's value grows with the number of destinations and with the frequency of releases, because what it replaces is not one script but the accumulated knowledge of ten.

Where it wins is the medium case, a project with three or four destinations and a release every few weeks, where the manual process has quietly become a chore and one person's local knowledge about what the Chocolatey feed needs. That is the case the tool is built for, and the one to test it on.

Editorial conclusion

JReleaser fits a team that publishes a project to more than one destination and has outgrown a hand written release script, because the same YAML file can describe archives, a container image, a native package and a checksum, and the tool knows the conventions of each registry. It does not fit a project with a single destination and a simple release process, because the configuration surface is large and the value comes from breadth. Check three things before you commit. Check how many destinations you actually publish to, since the tool earns its complexity by doing the same work for ten of them, and for one of them it is a lot of configuration. Check the configuration format, because the top level of this repository carries a jreleaser.yml and the model API is a separate published artifact, so confirm which form your project will use. And check the version you pin, because the project publishes a rolling early-access release alongside numbered ones, so a snapshot build and a stable build behave differently. The last push was on 2026-10-16, the newest numbered release is v1.26.0 from 2026-08-31, and the license is Apache-2.0.

Frequently asked questions

Official sources

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