In this tutorial, you will learn how to manage application settings in Quarkus. Instead of hardcoding values, you will use configuration properties. You will also learn how Quarkus supports different profiles (dev, test, prod) so that your app can behave differently depending on where it runs.

Prerequisites

Before you begin, make sure that you have installed:

A JDK, version 17 or later. See the prerequisites in the Getting Started with Quarkus CLI tutorial.
The Quarkus CLI. See Step 1 in the Getting Started with Quarkus CLI tutorial.

Step 1. Create a Quarkus Project with REST and JSON support

Create a new Quarkus Project with the REST Jackson extension. Execute the following command in your project directory.

quarkus create app com.ibm.developer:module-four \
  --extension=quarkus-rest-jackson

This creates a new project called module-four with the Quarkus REST extension already included. Adding JSON support means that your endpoints can speak the same format that most modern applications and APIs use, making integration easy.

Step 2. Modify the example resource class

Open the src/main/java/org/acme/GreetingResource.java file and replace the content with the following:

package com.ibm.developer;

import java.util.Map;

import org.eclipse.microprofile.config.inject.ConfigProperty;

import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;

@Path("/greeting")
public class GreetingResource {

    @ConfigProperty(name = "greeting.message", defaultValue = "Hello, Quarkus!")
    String message;

    @GET
    @Produces(MediaType.APPLICATION_JSON)
    public Map<String, String> greeting() {
        return Map.of("message", message);
    }
}

The class is a REST resource, which means it defines an HTTP endpoint that clients can call.

The @Path("/greeting") annotation makes the class available at the URL /greeting.

The @ConfigProperty annotation injects a value from the configuration (application.properties). If no value is set, it falls back to the default "Hello, Quarkus!".

The greeting() method is exposed as an HTTP GET endpoint because of @GET.

The method produces JSON (@Produces(MediaType.APPLICATION_JSON)), so responses are automatically serialized to JSON.

The method returns a simple JSON object with one key/value pair: "message": "<configured text>".

Open src/main/resources/application.properties and add:

greeting.message=Hello from configuration!
quarkus.http.port=8081

In this file, we:

Defined a custom message for our greeting endpoint.
Changed the HTTP port from the default 8080 to 8081.

Now, start the app in dev mode:

quarkus dev

Then, call the endpoint:

curl http://localhost:8081/greeting

Your application runs on port 8081 and responds with the custom greeting message.

The application.properties file is the central place to manage your app’s settings. Small changes here can completely alter how your app runs, without touching code.

Why external configuration matters

Applications need to change their behavior depending on where they run. For example:

In development, you might use an in-memory database.
In test, you want to start services automatically (Dev Services).
In production, you connect to a real PostgreSQL cluster.

If you hardcode these values in code, you will constantly recompile and risk mistakes. By using configuration files and profiles, Quarkus makes it easy to adjust behavior without touching the source code.

Step 3. Work with profiles

Profiles let you switch between environments easily. Instead of one big config file, you have context-aware settings that Quarkus activates automatically.

Quarkus supports three main profiles by default:

dev runs when you start quarkus dev.
test runs during ./mvnw test.
prod runs when you build and package your app.

Set different values per profile by prefixing the property in the src/main/resources/application.properties file:

%dev.greeting.message=Hello from Dev Profile!
%test.greeting.message=Hello from Test Profile!
%prod.greeting.message=Hello from Prod Profile!

When you call /greeting in dev mode, you will see the dev message Hello from Dev Profile!.

quarkus dev

Next let us try the test mode.

Replace the GreetingResourceTest.java file with the following which reads the message text from the application.properties file.

package com.ibm.developer;

import io.quarkus.test.junit.QuarkusTest;
import org.junit.jupiter.api.Test;

import static io.restassured.RestAssured.given;
import static org.hamcrest.CoreMatchers.is;

import org.eclipse.microprofile.config.inject.ConfigProperty;

@QuarkusTest
class GreetingResourceTest {

    @ConfigProperty(name = "greeting.message", defaultValue = "Hello, Quarkus!")
    String message;

    @Test
    void testHelloEndpoint() {
        given()
          .when().get("/greeting")
          .then()
             .statusCode(200)
             .body("message", is(message));
    }

}

You can now press Ctrl+C to stop the dev mode.

Run ./mvnw test to make sure the test passes indicating that during tests, the test message is used.

./mvnw test

Finally, run the following command to simulate the prod profile mode.

quarkus dev -Dquarkus.profile=prod

You should see the prod profile message Hello from Prod Profile! when you access the endpoint from a different terminal.

curl http://localhost:8081/greeting

Note: When you package and run the Quarkus application as an executable JAR, the prod profile is automatically active.

Step 4. Override configuration with environment variables

In real deployments, you often don’t want to touch the JAR file or its properties file. Quarkus allows overriding configuration with environment variables.

For example, run:

export QUARKUS_HTTP_PORT=9090

quarkus dev

Now your app runs on port 9090, even though application.properties says 8081. You can test this with:

curl http://localhost:9090/greeting

Why this matters: This makes it easy to adjust settings per environment, especially in containers and Kubernetes. You can deploy the same application image to many places but configure it differently at runtime.

Step 5. Explore advanced configuration options

Knowing that configuration is flexible in Quarkus helps you plan ahead. You start simple with application.properties, and later you can grow into advanced scenarios without changing your whole application.

So far, you’ve worked with the basics: application.properties, profiles, and environment variables. But Quarkus supports much more. You can:

These are powerful options when your applications grow more complex. You don’t need them yet, but it’s good to know they exist.

Summary

You learned how Quarkus uses external configuration through application.properties to make applications portable across environments, and how profiles (dev, test, prod) enable context-aware settings that activate automatically. You also discovered that environment variables can override configuration at runtime, allowing you to deploy the same application image to different environments with different settings, which is especially valuable in containerized and Kubernetes deployments.

Configuring Quarkus applications

Configuring Quarkus applications