Quarkus: a contributor surface at the root, an operations manual everywhere else

Three releases in a day, with a major beta newer than the patch stream

The release list reads as a timeline rather than a version list. On 2026-10-19, 3.27.6.1 was published at 12:33:06 and 3.40.1.1 at 14:15:59, and on 2026-10-28 4.0.0.Beta2 appeared. Two patch streams and a major version preview are therefore live at the same time, and the newest entry is a beta rather than something you would pin a production service to. Nothing at the repository root says which line is supported or for how long. The README sends you to a release planning document in the project wiki for timing, and a separate wiki page collects the migration notes. The question of what to depend on is therefore answered outside the checkout, and the word Beta in the version string is the only in-band signal of which is which.

The only mechanism the README explains is build-time work

The performance claim in the README carries a one-sentence mechanism: more is done at build time, so startup is fast. No figure accompanies it, there is no benchmark table, and there is no measurement anywhere in the repository root. What the README also does not contain is a single configuration key, a single command, or a single dependency coordinate. Every operational detail is delegated outward. Getting Started links to the documentation site and to the wiki. Build instructions are in CONTRIBUTING.md, with TROUBLESHOOTING.md beside it. The consequence is that a reader of the README cannot learn what Quarkus configures, because it names no property. The root is a contributor surface rather than a usage surface, and the gap between the two is bridged entirely by pages hosted elsewhere.

The framework names upstream projects instead of reimplementing them

The standards-based claim is concrete and it is a list of other people's work: RESTEasy and JAX-RS for the REST layer, Hibernate ORM and JPA for persistence, Netty and Eclipse Vert.x underneath, Eclipse MicroProfile for the cloud-native programming model, and Apache Camel for integration. That choice has a direct consequence for anyone adopting it. You are not taking only Quarkus, you are taking that whole set along with its upgrade schedule, and a Quarkus version bump moves the versions of all of them together. The layout reflects this: a bom directory at the root is where those aligned versions live, with build-parent next to it. The upside is that you write against standards you may already know. The cost is that the framework's release cadence becomes your dependency upgrade cadence, whether or not you touch the parts you did not choose.

JVM and native are two artifacts and the root documents neither build

Two runtime targets are claimed: the JVM for high throughput, and native for constrained environments. Those are not two settings applied to one output. They are two artifacts from different build paths, and the native one pays at build time for what it saves at startup. The repository root explains how to produce neither. There is no command for either, and the build is handed to the contribution guide, with the underlying structure exposed as directories: build-parent, build.scenario, independent-projects and core. For contributors the toolchain is pinned openly, with a .sdkmanrc file for SDKMAN, a .jbang directory for JBang, and a .justfile for task running. For users, choosing a target is a decision this checkout cannot help you make.

Forbidden APIs turn a library call into a build failure

A .forbiddenapis directory at the repository root means the build carries an explicit list of API calls the project does not accept, checked during compilation rather than left to code review. A call that compiles cleanly can still be rejected by that check. The consequence for an outside contributor is that a successful local compile is not evidence that a change passes this project's build. The same impulse appears elsewhere in the layout, with a coverage-report directory and a scan badge pointing at develocity.quarkus.io/scans. Checking what a change touches against the project's own written rules comes before debating style.

Merging runs through compatibility kits, not only unit tests

The test layout tells you what a change has to survive. There is a tcks directory for compatibility kits, a test-framework directory other projects build on, integration-tests, independent-projects and a coverage-report directory, alongside a GitHub Actions workflow named Quarkus CI. That is a heavier gate than a unit test suite, and it is the reason a small pull request against this repository is not a small pull request. Governance is written down in the open too: MAINTAINERS.adoc, COMMITTERS.adoc, DECISIONS.adoc and an adr directory for architecture decision records. The consequence for an outside contributor is that the bar is set by compatibility across many extensions, so the practical first move is to locate the decision record covering the area you intend to touch rather than to write code first.

Agent instruction files sit beside a written AI policy and a DCO requirement

The root holds an unusual cluster for a Java framework: an .agents directory, AGENTS.md, CLAUDE.md and a file named AI_POLICY.md. Written policy next to agent instruction files is a deliberate arrangement rather than leftover tooling, and it means the rules for generated contributions are something you can read before producing anything. Two established community requirements sit alongside them. ACTIONS.md sits beside them, and dco.txt is the Developer Certificate of Origin, so commits carry a sign-off. Together these set expectations for outside contributions before any code review begins. If you are generating a patch for this project, read AI_POLICY.md and confirm the sign-off first, because those two files decide whether a contribution is admissible at all.

One programming model for blocking and non-blocking puts event-loop rules into ordinary code

The unification claim covers reactive and imperative styles under one model, with Vert.x and Netty named as the substrate. The practical effect is that non-blocking code stops looking alien, which removes a good deal of duplication from application code. It also means event-loop constraints reach code that reads as plain method calls. A blocking call placed on the wrong thread becomes a correctness problem rather than a style problem, and nothing at the root marks which thread a given endpoint runs on. The README also commits to 12 factor architecture for container and Kubernetes environments and describes the range as spanning the smallest microservice to the largest monolith. Both are direction statements rather than mechanisms. The thread rules and the container contract are absent from the README, so again the specifics live on the documentation site.

Editorial conclusion

Quarkus suits teams writing Java services that ship as containers and who want the named upstream stack, RESTEasy, Hibernate ORM, Vert.x and MicroProfile, held at aligned versions in the bom directory. It does not suit anyone who needs the operational details inside the repository, because the root is a contributor surface with no install command, no configuration key and no stated support window. Before you adopt it, check three things. Read the release planning page in the wiki for the support window, because the README does not state one and 4.0.0.Beta2 was published on 2026-10-28. Read AI_POLICY.md and dco.txt if you intend to contribute, since both gate acceptance before review. And if you contribute, confirm your change passes the .forbiddenapis check.

Frequently asked questions

Official sources

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