Quarkus 4 RC1 makes remote development a CLI workflow and formalizes shutdown phases

Quarkus 4.0.0.CR1 is a smaller release than the first beta, but two of its changes clarify how teams will work with the next major line: remote live reload now has a first-class CLI entry point, and extensions can join graceful shutdown through the new service lifecycle.

What changed after Beta1

Beta1 carried the broad migration burden: Java 21 became the baseline, Netty 4.2 and Vert.x 5 moved the networking foundation, and major framework updates included Hibernate ORM 8, Jackson 3 and CDI 5. RC1 does not replace that migration checklist. Instead, its release changelog adds operational APIs on top of it.

The new quarkus dev --remote option removes a tooling split. Before RC1, CLI users had to fall back to ./mvnw quarkus:remote-dev or ./gradlew quarkusRemoteDev. The merged change routes the CLI command to the correct Maven or Gradle task while preserving dev-mode handling for clean and offline builds, debug options, application parameters and system properties.

Teams still have setup work. The remote application must be packaged as a mutable JAR and launched with remote development enabled. The live-reload URL and password continue to come from quarkus.live-reload.url and quarkus.live-reload.password, supplied in configuration or with -D properties. The proposed setup command that would write those settings automatically was not included, and JBang projects remain unsupported.

A shutdown contract for extensions

RC1 also adds onGracefulPreShutdown(Runnable) and onGracefulShutdown(Runnable) to the service start context. The design issue assigns different jobs to the phases: pre-shutdown is where a service can fail health checks or otherwise withdraw from traffic; graceful shutdown is where it begins its actual drain and cleanup work.

That distinction matters for extension authors. The work is part of Quarkus’s broader service start/stop infrastructure, which is replacing recorder-oriented lifecycle code with a dependency graph for starting and stopping services. RC1 migrates existing graceful-shutdown consumers toward the runtime service API and deprecates the build-time-only path.

What teams should test

Application teams evaluating Quarkus 4 should rerun the full Beta1 migration rather than treating RC1 as a drop-in update. Remote-development users should test both Maven and Gradle projects against a mutable-JAR deployment, with credentials kept in configuration rather than copied into shell history. Extension maintainers should verify that readiness changes happen in pre-shutdown and resource draining happens in the shutdown phase. That ordering is now an explicit contract instead of extension-specific lifecycle wiring.