Payara: two Jakarta EE runtimes, one for containers and one for servers

One platform, two very different runtimes

The Payara Platform Community Edition is described as an open source middleware platform for Jakarta EE, formerly Java EE, and MicroProfile applications, and the repository is really the source for two separate products. Payara Server Community is the full server runtime, positioned as a cloud-native open source middleware platform for development projects that supports Jakarta EE applications in any environment, on premise, in the cloud or hybrid. Payara Micro Community is the lightweight one, described as the middleware platform of choice for containerized Jakarta EE microservices deployments in development, requiring no installation, no configuration and no code rewrites, and staying under 70MB. The split is the practical thing to understand before anything else, because the choice between them is not about edition but about shape. If your workload is a set of small services that will run as containers, Payara Micro is the one you deploy. If it is a Jakarta EE application with the full platform API surface, that is Payara Server. The README also points at a separate, paid Payara Enterprise Edition for production, which the community edition is meant to lead into.

Payara Micro is sized for a container image

The 70MB figure is the whole argument for Payara Micro. A runtime that small changes what you can put in a container image and what you can do with a scale-out deployment, since each replica carries its own runtime. The README adds that it requires no installation, no configuration and no code rewrites, which is the standard complaint about application servers and the reason the Jakarta EE and MicroProfile runtimes have struggled in containerised environments. MicroProfile is the other half of the proposition: it is the smaller, more prescriptive profile for microservices, and a MicroProfile runtime is what you want when your service is a service rather than a full enterprise application. The honest caveat is that the README positions both community products explicitly for development projects, with the enterprise edition described as the option for mission-critical systems in production, including 24x7 and 10x5 support options and migration project support. If you are choosing for production, the community editions are the free half of a commercial arrangement.

What is in the repository is the server, not the micro profile

The top level listing gives the shape of the code. There is an appserver directory, which is the Payara Server implementation itself, a nucleus directory, which in the Payara architecture is the core that handles the low-level runtime concerns, and an api directory for the published interfaces. Above them sits a Maven pom.xml at the root, and the build is driven by a Jenkinsfile with a .jenkins directory, which is the continuous integration setup for the project itself. Alongside the code sit LICENSE.txt, PayaraCLA.pdf, which is the contributor licence agreement document, and SUPPORT.adoc, which is where the support terms are recorded. The repository therefore contains the full server platform rather than a small library, and the Jenkinsfile rather than a GitHub Actions workflow is what produces the monthly artifacts. Documentation is not here either: the README sends readers to docs.payara.fish for the complete Payara Server and Payara Micro documentation, and to www.payara.fish for resources.

Monthly releases, and a community support model that is not a contract

The release list shows a regular cadence in the 7.x line: payara-server-7.2026.8 on 2026-08-25, payara-server-7.2026.9 on 2026-09-16 and payara-server-7.2026.10 on 2026-10-14, with the last push to the repository on 2026-10-19. The version scheme encodes the year and the month, which makes it easy to see how fresh a deployment is. What that cadence does not give you is support. The README lists the community support offering as assistance on the Payara Forum, raising bugs on GitHub, a tech blog, and user guides and datasheets. Those are useful, and they are not a support contract: the enterprise edition is where the response times, the 24x7 and 10x5 coverage and the migration project assistance live. For an organisation that treats the runtime as infrastructure rather than a development convenience, that boundary is the practical dividing line between the free and paid products, and it is worth deciding on deliberately rather than discovering it during an incident.

The licence is the Payara CLA, not a standard one

The licence field on the repository says it is a custom licence that GitHub cannot classify and points to the LICENSE file, and the tree confirms the arrangement: LICENSE.txt is the licence text and PayaraCLA.pdf is a separate contributor licence agreement. Payara is a trademark of the Payara Foundation and GlassFish is a trademark of the Eclipse Foundation, and both statements are in the README, which is a reminder that the project sits in a space with several trademarks and licence terms layered on top of each other. The practical advice is narrow and specific. Read LICENSE.txt, and read PayaraCLA.pdf if you intend to contribute code, before you build a distribution strategy on top of this platform, because the community edition is free to use but the terms are not the ones an OSI-approved licence would give you, and the point of the CLA is to govern contributions rather than use. Anyone who needs a licence that their own legal review recognises without reading further should not assume the community edition satisfies that requirement.

Community edition against the enterprise edition

The comparison is drawn in the README rather than hidden. The community platform is pitched at rapid access to new features, regular and frequent releases, software experimentation, and suitability for development projects. The enterprise edition is described as stable and fully supported, designed for mission-critical systems in production, with 24x7 and 10x5 support and migration project support options. So the two editions differ along three axes rather than one: the stability promise, the support coverage, and the assistance you get when moving an existing system onto it. What the community edition gives you that a paid evaluation might not is the full source, the frequent release train and the ability to experiment with new platform features early. What it does not give you is a commitment that a given release will still be supported in two years, or that someone will answer the phone at 3am. For a team choosing a runtime for a long-lived internal platform, that is the whole argument, and it is an organisational one rather than a technical one.

Editorial conclusion

Payara fits a team that wants a Jakarta EE or MicroProfile runtime in containers and is willing to run the community edition during development, and it fits organisations that will later move to the paid enterprise edition for support. It does not fit a project that needs a support contract from day one without buying the enterprise edition, and it does not fit an organisation whose legal review requires a recognised OSI licence, because the licence field on the repository says it is a custom licence and the tree carries PayaraCLA.pdf. Verify first what PayaraCLA.pdf grants and requires, then confirm that the Jakarta EE and MicroProfile versions your application targets are supported by the release you plan to deploy. The last push was on 2026-10-19, and release payara-server-7.2026.10 was published on 2026-10-14.

Frequently asked questions

Official sources

1. Issues
2. payara/Payara on GitHub
3. Project website
4. README
5. Releases