Open Liberty is a Java runtime you compose feature by feature, and its build is Gradle in dev/

The product is a runtime you compose, not a platform you inherit

The Summary section describes Open Liberty as a lightweight open framework for building fast and efficient cloud-native Java microservices, and the repository description calls it a highly composable, fast to start, dynamic application server runtime environment.

Three claims carry the whole pitch. The first is speed to start, with low memory footprint and live reload for quick iteration. The second is that it is simple to add and remove features from the latest versions of MicroProfile and Java EE. The third is zero migration, which the README glosses as letting you focus on what is important, not the APIs changing under you.

The second and third claims are the distinctive ones, and they are two sides of the same design decision. A traditional application server arrives with a large set of features switched on, and your application inherits all of them whether or not it uses them, and it inherits them at whatever version the platform shipped. A composable runtime starts with what you asked for, and adding a feature is a deliberate step with its own version.

That is a real trade and not a free win. The cost is that somebody has to decide what is in the runtime for each application, and the benefit is that the runtime stays small, starts quickly, and does not change its mind about what it contains when the platform is upgraded.

The runtime is distributed three ways. There is a Maven Central artefact, io.openliberty:openliberty-runtime, the website's own downloads area, and container images on Docker Hub as open-liberty, with a badge and a guide for the container route.

A sample app and one Maven command are the whole quick start

The Getting Started section is short, and it is worth following literally rather than improvising.

git clone https://github.com/OpenLiberty/sample-getting-started.git
cd sample-getting-started
mvn clean package liberty:run

That clones a separate sample repository, builds it with Maven, and runs it with the Liberty Maven plugin, after which you open a browser to http://localhost:9080/ and explore the demo application. The README then points at a guide for how it works.

The important detail is that the sample is its own repository. That is a deliberate separation, because the sample is the thing a new user should look at first and the main repository is a build of a server, not a demonstration of one. A user who clones the server repository to see what the runtime looks like is doing it the hard way.

The usage section offers three routes and links a guide for each. The Docker guide demonstrates development using Docker containers, the Maven guide demonstrates development using the Liberty Maven Plugin, and the command line reference demonstrates the basic server operation commands. The documentation itself is split into the guides and the reference documentation, which covers features, configuration and the APIs.

So the supported paths are the same three a Java developer would expect: an editor with the plugin doing a live reload, a container, or the server started from a command line. What makes it distinctive is that the first of those works because the runtime starts fast and reloads, rather than because the framework is clever.

The build lives in dev/ and needs a specific JDK arrangement

The contributing section is where most of this README's length is, and it is a build guide with one notable trap.

The first step is to clone the repository, and the second is to run a Gradle build, with the prerequisite that the environment variable JAVA_HOME must point to a Java 17 or Java 21 SDK. And here is the part worth flagging: if setting JAVA_HOME to Java 17, you will also need to set JAVA_21_HOME to a Java 21 SDK.

cd open-liberty/dev
./gradlew cnf:initialize
./gradlew assemble

So a contributor on Java 17 needs two JDKs installed, because the build compiles against a newer JDK than the one it targets. That is a reasonable requirement for a server that supports several Java versions, but it is not something the README glosses over, and a first-time contributor who does not read that sentence will hit an error that looks like a broken toolchain.

The build itself is Gradle rather than Maven, with the wrapper in the repository, and the build directory is dev/ rather than the repository root, which is why the instructions cd into it before running the wrapper. The first task, cnf:initialize, runs before assemble to set up the build.

The troubleshooting note is also specific and practical. If./gradlew assemble shows an out of memory error, you can increase the memory in the dev/gradle.properties file, and you should stop the Gradle daemon after changing the memory setting with./gradlew --stop, because a running daemon keeps the old setting. If that does not help, try cleaning up the Maven repository cache with rm -rf ~/.m2 and the Gradle cache with rm -rf ~/.gradle/caches.

Testing is unit tests plus a FAT project, and both are Gradle tasks

The test section is short and points at a wiki page for the description, but the commands are all there.

./gradlew test

./gradlew build.example_fat:buildandrun

The first runs the unit tests and the second runs a FAT project, which in the Liberty test vocabulary means a project that starts the server, exercises it end to end and shuts it down. The README notes that./gradlew build runs the assemble and test tasks together, so the full local gate is one command plus the FAT run.

The FAT run is the part that matters for an adopter, and it is the part a team outside the project is most likely to skip. A unit test can pass while the server does not start, and a feature set that assembles is not the same as a feature set that serves a request. The example_fat project is the smallest configuration that exercises the runtime the way a real application would, and the task name says so.

The repository supports the workflow with a.pre-commit-config.yaml and a.secrets.baseline file at the root, which is the detect-secrets baseline used to catch credentials before they are committed, and an AGENTS.md and a GENAI_GUIDELINES.md for contributors working with coding agents. The.ci-orchestrator/ and.bob/ directories sit alongside dev/, cla/ and logos/.

A local release is one Gradle task and a zip in a predictable path

The last step of the build instructions is a local release, and it is the tidiest part of the whole document.

./gradlew releaseNeeded

The note explains what it does: this task releases all projects to the local releaseRepo. The final Open Liberty zip can then be found at open-liberty\dev\cnf\release\dev\openliberty\<version>\openliberty-xxx.zip, with the version substituted.

The path is worth noting because it tells you where the build artefacts actually end up, and it is a different shape from a Maven repository layout. The build produces a server distribution rather than a set of jars, because the runtime is the product. The Maven Central artefact io.openliberty:openliberty-runtime is the packaged form of the same thing, and the container image is the packaged form for a deployment target.

So there are three consumption paths and one build path. The build produces the distribution, and from it come the Maven artefact, the website download and the container image. A contributor who wants to test a local change end to end runs releaseNeeded and unpacks the zip.

The .gitattributes, .gitignore, .github/ and images/ directories complete the tree, and the top-level CLAUDE.md-style guidance sits in AGENTS.md and GENAI_GUIDELINES.md rather than in the README, which is free to concentrate on the build.

EPL-2.0, and a branch story that has moved twice

The licence is EPL-2.0, with a LICENSE file at the repository root and a badge in the README pointing at the Eclipse Public License 2.0 text. Usage is provided under that licence, and the wording is a licensing fact rather than legal advice.

The branch arrangement is the part that will trip up a first-time contributor, because it has changed. The README notes that the project recently renamed the master branch to release, with a link to the wiki page describing the rename, and the CONTRIBUTING document it links to is itself on the release branch. The repository metadata, meanwhile, records the default branch as integration.

So there are three names in play, and the README only explains one of the transitions. The practical advice is to read the current CONTRIBUTING document rather than assuming a branch name, and to check the wiki page linked from the README, since that is where the rename is documented.

The release history is regular and fast. The recent releases are gm-26.0.0.9 on 2026-08-25, gm-26.0.0.8 on 2026-07-28 and gm-26.0.0.7 on 2026-07-02. The gm prefix marks them as general availability builds, and the three releases inside two months show the cadence the project works at. The last push was on 2026-10-15, so the integration branch is moving while the published builds are on 26.0.0.x.

The community channels are the ones a Java project would use. There is a Stack Overflow tag, a Groups.io list, a Twitter account, a website, and a SECURITY.md in the repository for disclosure, with the project site at openliberty.io and the documentation under /guides/ and /docs/.

Editorial conclusion

Open Liberty fits a Java team that wants a Java EE and MicroProfile runtime it can compose, run locally with live reload and in a container, and that is willing to build from source when it needs a fix. It does not fit a team that wants a full platform with every feature already present, and it does not fit a build environment without a specific JDK layout. Before adopting it, run the sample app with mvn clean package liberty:run to see the startup behaviour, and if you intend to build, set JAVA_HOME and JAVA_21_HOME as the README describes before running./gradlew assemble in dev/.

Frequently asked questions

Official sources

1. License: EPL-2.0
2. OpenLiberty/open-liberty on GitHub
3. Project website
4. README
5. Releases