////
This guide is maintained in the main Quarkus repository
and pull requests should be submitted there:
https://github.com/quarkusio/quarkus/tree/main/docs/src/main/asciidoc
////
= How dev-mode differs from a production application

include::./attributes.adoc[]

This document explains how the dev-mode in Quarkus differs from a production application.

== Intro

Quarkus provides a dev-mode (explained in more detail xref:maven-tooling.adoc#dev-mode[here] and link:gradle-tooling#dev-mode[here]) which greatly aids
during development but should *NEVER* be used in production.

[[architectural-differences]]
== Architectural differences

Feature sets aside, the Quarkus application that is run under dev-mode differs architecturally from the production application (i.e. the one that is run using `java -jar ...`).

In dev-mode, Quarkus uses a ClassLoader hierarchy (explained in detail xref:class-loading-reference.adoc[here]) that enables the live reload of user code
without requiring a rebuild and restart of the application.

In a production application, the aforementioned class loading infrastructure is entirely absent - there is a single, purpose built ClassLoader that loads (almost) all classes and dependencies.

== Dev-mode features

In keeping with the mantra of providing developer joy, Quarkus provides a host of features when dev-mode is enabled. The most important features are:

=== Live reload

This mightily important feature needs no introduction and has already been mentioned in the <<architectural-differences, architectural differences>> section.

=== Dev UI

Quarkus provides a very useful xref:dev-ui.adoc[UI] accessible from the browser at `/q/dev`. This UI allows a developer to see the state of the application, but
also provides access to various actions that can change that state (depending on the extensions that are present).
Examples of such operations are:

* Changing configuration values
* Running Database migration scripts
* Clearing of caches
* Running scheduled operations
* Building a container

=== Error pages

In an effort to make development errors very easy to diagnose, Quarkus provides various detailed error pages when running in dev-mode.

=== Database import scripts

The `quarkus-hibernate-orm` extension will run the `import.sql` script in `src/main/resources` when Quarkus is running in dev-mode. More details can be found xref:hibernate-orm.adoc#dev-mode[here].

=== Dev Services

When testing or running in dev-mode Quarkus can even provide you with a zero config database out of the box, a feature we refer to as Dev Services.
More information can be found xref:datasource.adoc#dev-services[here].

=== Swagger UI

The `quarkus-smallrye-openapi` extension will expose the Swagger UI when Quarkus is running in dev-mode. Additional information can be found xref:openapi-swaggerui.adoc#dev-mode[here].

=== GraphQL UI

The `quarkus-smallrye-graphql` extension will expose the GraphiQL UI when Quarkus is running in dev-mode. More details can be found xref:smallrye-graphql.adoc#ui[here].

=== Health UI

The `quarkus-smallrye-health` extension will expose the Health UI when Quarkus is running in dev-mode. xref:smallrye-health.adoc#ui[This] section provides additional information.

=== Mock mailer

The `quarkus-mailer` extension will enable an in-memory mock mail server when Quarkus is running in dev-mode. See xref:mailer-reference.adoc#testing[this] for more details.


=== gRPC

* The gRPC Reflection Service is enabled in dev mode by default. That lets you use tools such as `grpcurl`. In production mode, the reflection service is disabled. You can enable it explicitly using `quarkus.grpc-server.enable-reflection-service=true`.

* In dev-mode, `quarkus.grpc.server.instances` has no effect.

=== Others

There might be other configuration properties (depending on the extensions added to the application) that have no effect in dev-mode.


== Performance implications

In dev-mode minimizing the runtime footprint of the application is not the primary objective (although Quarkus still starts plenty fast and consumes little memory even in dev-mode) - the primary objective
is enabling developer joy.
Therefore, many more classes are loaded and build time operations also take place every time a live-reload is performed.

In contrast, in a production application the main objective for Quarkus is to consume the least amount of memory and startup in the smallest amount of time.
Thus, when running the production application, build time operations are not performed (by definition) and various infrastructure classes needed at build time are not present at all at runtime.
Furthermore, the purpose built ClassLoader that comes with the xref:maven-tooling.adoc#fast-jar[fast-jar] package type ensures that class lookup is done as fast as possible while also keeping
the minimum amount of jars in memory.

== Security implications

Perhaps the most important reason why dev-mode applications should not be run in production is that the dev-mode allows reading information that could be confidential (via the Dev-UI)
while also giving access to operations that could be destructive (either by exposing endpoints that should not be available in production application or via the Dev-UI).

== Native executable

When a native executable is created (explained in detail xref:building-native-image.adoc[here]), it is *always* built from a production application.
