Quarkus: Container-First Java Framework

What Quarkus is

Quarkus is a Java framework for building services and applications that run well in containers. Its README describes it as a cloud native, (Linux) container first framework for writing Java applications, and the tagline, "Supersonic Subatomic Java", points at the two things it optimises for: fast startup and a small memory footprint. The project's own summary of its approach is short: it does more at build time so that applications start fast.

The README lists the ideas the framework is built around. It is container first, producing minimal-footprint applications suited to running in containers. It is cloud native and embraces the twelve-factor architecture in environments such as Kubernetes. It is meant to scale from the smallest microservice to the largest monolith. It runs on the JVM for high throughput or as a native executable for constrained environments. It brings imperative and non-blocking reactive styles under one programming model. And it is standards-based, building on APIs and libraries Java developers already know: RESTEasy and JAX-RS, Hibernate ORM and JPA, Netty, Eclipse Vert.x, Eclipse MicroProfile and Apache Camel, among others. The last item on the list is "developer joy", which in practice means live reload, continuous testing and automatic provisioning of dependencies in development.

Quarkus is licensed under Apache-2.0 and developed in the open on GitHub. It is aimed at Java teams building REST APIs, event-driven services and batch or CLI tools that will run on Kubernetes, serverless platforms or other container hosts, and at teams that want to keep using Jakarta and MicroProfile APIs while getting startup times and memory use closer to what other ecosystems offer.

How it works

Build-time processing

The core idea is to move work that traditional Java frameworks do at startup, such as scanning classes, reading annotations and wiring components, into the build. The build is driven by the quarkus-maven-plugin (or the Gradle plugin), which the getting-started guide describes as responsible for packaging the application and providing development mode. Projects import the Quarkus BOM, quarkus-bom, so individual Quarkus dependencies do not need explicit versions.

Functionality comes in extensions. Adding an extension such as rest, a database driver or the Kubernetes integration both adds the runtime library and plugs build-time steps into the build. Dependency injection is handled by ArC, which the guide describes as a CDI-based solution tailored to Quarkus's architecture. It implements a subset of CDI with some non-standard additions, so applications that rely on obscure CDI features should check the CDI reference before migrating.

JVM, Leyden AOT and native

The same application can be packaged three ways. The default is a JVM "fast-jar". On JDK 24 and later it can also use Project Leyden's AOT cache, which needs a training run on a representative workload. And it can be compiled ahead of time into a native executable with GraalVM or Mandrel, a Quarkus-focused GraalVM distribution that leaves out components Quarkus does not need, such as polyglot support. The native-image guide is careful to say that JVM mode is often the right choice, and its advice is to start there and move to native only when there is a concrete need.

The guide includes a comparison table based on the project's own benchmarks. For a tuned benchmark run with Quarkus 3.34.3 on JDK 25, it reports peak throughput of about 13,265 transactions per second and 304 MiB of RSS for JVM fast-jar, against about 5,411 transactions per second and 95 MiB for the Mandrel native executable, which it describes as roughly 59% lower throughput. Cold start, by the guide's figures, ranges from about 0.4 to 3 seconds on the JVM and about 17 to 240 milliseconds natively, depending on application size. Those are the project's own measurements on a specific setup, but they show the trade-off honestly: native buys startup time and memory at the cost of throughput and build time.

Dev mode is a different runtime

The dev-mode guide explains that an application running under dev mode differs architecturally from the production application started with java -jar. Dev mode uses a hierarchy of class loaders so user code can be reloaded without a rebuild or restart; production uses a single, purpose-built class loader. The guide states in capitals that dev mode should never be used in production.

Key features

• Live coding. In dev mode you edit Java or resource files, save and refresh; changes take effect without a restart, and compilation or deployment errors appear on an error page.
• Dev UI. A dashboard at /q/dev-ui shows extensions, configuration and endpoints, and exposes actions such as changing configuration values, running database migrations, clearing caches, running scheduled jobs and building a container.
• Continuous testing. From the dev-mode console, pressing r runs tests, and Quarkus then re-runs only the tests that cover the code you changed each time you save.
• Dev Services. If you add an extension and do not configure it, Quarkus starts the service for you in dev and test mode, usually with Testcontainers, and wires the application to it. Databases, Kafka, AMQP, Redis, MongoDB and other services are covered, and H2 runs in-process.
• Native executables. One flag builds a native binary, and a container build option produces a Linux executable without installing GraalVM locally.
• Container images. The CLI's image commands build with Docker, Buildpacks, Jib or OpenShift and push to a registry.
• Imperative and reactive together. The reactive architecture guide says you can implement reactive and imperative components and combine them in the same application, without separate stacks or tooling.
• Configuration profiles. Properties can be scoped to a profile with a prefix such as %prod.. The Dev Services guide uses this to configure a real PostgreSQL datasource for production while dev and test mode keep using an automatically provisioned database, because configuring a service is what switches its Dev Service off.
• A CLI. The quarkus command creates projects, manages extensions and wraps build, dev, image and deploy tasks for Maven, Gradle or JBang projects.

Getting started

The guides assume a JDK with JAVA_HOME set and Apache Maven, plus an IDE; the documentation's attribute file lists Java 21 or 25 as the supported versions. The Quarkus CLI is the most convenient entry point. It is available through SDKMAN!, Homebrew, Chocolatey, Scoop and Mise, or as a jar installed with JBang. With SDKMAN! or Homebrew:

sdk install quarkus
brew install quarkusio/tap/quarkus

The Homebrew formula does not pull in a JDK, so that you can use whichever one you prefer. Once the CLI is installed, create a project. Coordinates can be given as group:artifactId:version, and omitted parts fall back to defaults:

quarkus create app com.foo:bar

The getting-started guide's generated project contains a Maven structure, a GreetingResource endpoint on /hello, a test, a landing page on http://localhost:8080, example Dockerfiles for native and JVM modes under src/main/docker, and an application configuration file. Start dev mode with the CLI, the Maven wrapper or the Gradle wrapper:

quarkus dev
./mvnw quarkus:dev
./gradlew --console=plain quarkusDev

While dev mode is running, the Dev UI at http://localhost:8080/q/dev-ui/ shows installed extensions, configuration and endpoints, all updated live as you code. Dev mode also listens for a debugger on port 5005; -Dsuspend waits for one to attach and -Ddebug=false turns it off. Extensions are added from the CLI:

quarkus ext add kubernetes health

Tests run with the usual build tool command. The guide notes that, with Maven, the Surefire plugin version must be set explicitly because the default version does not support JUnit as Quarkus needs:

./mvnw test

For a native executable, either use the CLI or pass the native flag to Maven. Adding a container build lets you produce a Linux binary without GraalVM installed, and the second command below also builds a container image:

quarkus build --native
./mvnw install -Dnative
./mvnw package -Dnative -Dquarkus.native.container-build=true -Dquarkus.container-image.build=true

Container images for JVM builds come from the CLI's image command:

quarkus image build

Use cases

REST and microservices on Kubernetes

The framework's stated home is cloud native services: JAX-RS endpoints, Hibernate ORM for persistence, and Kubernetes and SmallRye Health extensions that the CLI adds in one command, as its own example shows. The generated Dockerfiles and the image commands cover the packaging side.

Serverless and scale-to-zero

The native-image guide names serverless functions, CLI tools and scale-to-zero environments as the cases where native executables shine, because cold starts matter there. It also mentions dense container deployments and edge devices with tight RAM budgets, and small container images.

Long-running, throughput-heavy services

For services that stay up and handle sustained load, the same guide recommends JVM mode, since the JIT can outperform native code on long-running workloads, with the Leyden AOT cache as a middle ground for teams on JDK 24 or later who want faster startup and full JVM tooling such as debuggers, profilers and JFR.

Event-driven and reactive systems

The reactive architecture guide frames Quarkus around reactive systems: asynchronous message passing, elasticity and resilience. With messaging extensions and Dev Services for Kafka, AMQP, Pulsar and RabbitMQ, an event-driven service can be developed against real brokers that the framework starts for you.

How it compares

The natural comparison is with Spring Boot, the most widely used Java framework for the same kind of service. The Quarkus native-image guide itself cites a Spring versus Quarkus performance comparison from the project's benchmark repository as the source of its figures; those numbers are the Quarkus team's, and anyone choosing between the two should run their own workload. The structural differences are clearer: Quarkus builds on Jakarta and MicroProfile standards and moves wiring to build time, while Spring has its own programming model and a much larger ecosystem of Spring-specific libraries.

Against plain Jakarta EE application servers, Quarkus uses many of the same APIs but packages applications as standalone jars or native binaries rather than deploying them into a server. Against Vert.x, which Quarkus uses underneath, it adds dependency injection, configuration, extensions and tooling on top of the reactive toolkit.

Things to know before adopting

• Native builds have costs. The native guide puts native compilation at 3 to 10 minutes with 4 to 8 GB of RAM on the build host, warns that reflection and dynamic class loading need explicit configuration, and shows lower peak throughput than the JVM in its own benchmark. Windows native builds have their own toolchain requirements.
• Dev mode is not production. The documentation insists dev mode must never be used in production. Its class-loading model differs from a packaged application, and some features, such as the gRPC reflection service, are on by default only in dev mode.
• Dev Services need a container runtime. Most Dev Services require Docker or Podman, local or remote; without one, you configure services yourself. The default startup timeout is 60 seconds, adjustable with quarkus.devservices.timeout, and quarkus.devservices.enabled=false turns them all off. If you opt in to Testcontainers' reusable instances, Quarkus will not reset database state between runs unless you configure it to.
• CDI is a subset. ArC implements part of CDI and adds non-standard features, so libraries or code depending on full CDI behaviour may need changes.
• Remote Docker needs a different native flag. With a remote daemon, use quarkus.native.remote-container-build=true instead of the local container build, because volume mounts do not work remotely.
• Check JDK support for your version. The documentation lists Java 21 or 25 as supported, while the README's badge shows a JVM range of 17 to 25; the guides for your Quarkus release are the authority.
• Frequent releases mean migrations. Quarkus ships often, and the project collects migration notes in the migration guides on its GitHub wiki, with a separate release planning page. Budget time for upgrades, particularly across minor versions.
• Extensions vary in maturity. The CLI can list extensions with their support scope, and the documentation keeps an extension maturity matrix, so check the status of the extensions you plan to depend on.

Project activity

As of November 2026 the quarkusio/quarkus repository has about 16,000 stars on GitHub and around 3,350 forks. It was created in July 2018, is written in Java and is licensed under Apache-2.0. The most recent release at the time of writing is 3.40.1.1, published on 19 October 2026, and the main branch is pushed to daily. Discussion happens on the project's Zulip chat, and build instructions for contributors are in the contribution guide in the repository.

The source is at github.com/quarkusio/quarkus, and the guides and reference documentation are at quarkus.io.

[![Featured on TechLogHub](https://techloghub.com/badge-neutral.svg)](https://techloghub.com/open-source/quarkus?utm_source=techloghub_badge&utm_medium=referral&utm_campaign=readme)