Managing feature flags and runtime configuration without excessive build-time restrictions

[gigi]

We use Quarkus to build multiple applications for many clients.
Each client has a different set of enabled or disabled features, which we control via feature flags.

Sometimes, however, we hit build-time restrictions.
As I understand, the Quarkus ecosystem generally suggests having separate builds with specific features enabled or disabled.
But in our case, we support a large matrix of feature combinations across 100+ clients — maintaining separate builds for each combination is not feasible.

Some extensions (e.g., OpenTelemetry) provide negative runtime flags such as
quarkus.otel.sdk.disabled=false,
which allows keeping the functionality in the build but activating it only when needed.
This seems quite reasonable, especially for those coming from frameworks like Spring, where runtime flexibility is common.

However, many Quarkus extensions resolve configuration strictly at build time.
A real-world example is named Redis clients. Some of our features define their own Redis connections, e.g.:

quarkus.redis.feature-1-redis.hosts=redis://localhost:6379
quarkus.redis.feature-2-redis.hosts=redis://localhost:6389

and then we inject them like this:

@Inject
@RedisClientName("feature-1-redis")
RedisDataSource redisDataSource;

The dilemma:
If a feature is disabled for a particular client (or not yet configured), we must not connect to that Redis instance.
But if the client-specific Redis connection is missing (or dummy), our health checks fail.
If we try to obtain a RedisDataSource programmatically, it seems the bean is removed during the build phase — likely because there’s no direct injection for that named client, so it’s not retained in the final build.

We can’t simply disable the Redis health check globally (quarkus.redis.health.enabled=false), since some Redis connections should be monitored.
That means we’d have to write custom health checks or manage all Redis configurations manually, which defeats the simplicity of using Quarkus.

So my questions are:

What is the recommended Quarkus way to handle such cases — where we have dynamic, client-specific features but want to avoid build-time restrictions?

Is there a way to mark some named clients (like Redis) as unremovable or conditionally available at runtime?

Should we move more functionality to runtime initialization, or is there a Quarkus-native pattern for this kind of feature-flag-driven, multi-tenant setup?

Thank you in advance for your guidance!

[quarkus-bot[bot]]

/cc @radcortez (config)

[radcortez]

If a feature is disabled for a particular client (or not yet configured), we must not connect to that Redis instance.
But if the client-specific Redis connection is missing (or dummy), our health checks fail.

If there is a valid injection point required by the current configuration, the injection point must be satisfied, meaning that a valid connection must exist.

If we try to obtain a RedisDataSource programmatically, it seems the bean is removed during the build phase — likely because there’s no direct injection for that named client, so it’s not retained in the final build.

How are you doing this? Redis connection configuration is runtime, so if you have a valid connection configuration, a bean is available for it, unless there is a bug. Health checks should only be available to valid Redis connections.

What is the recommended Quarkus way to handle such cases — where we have dynamic, client-specific features but want to avoid build-time restrictions?

Take a look at https://quarkus.io/guides/datasource#datasource-active. Redis should work similarly. You should be able to use InjectableInstance and then query all available Redis connections.

Also @Unremoveable and @LookupIfProperty may help with your case:

• https://quarkus.io/guides/cdi-reference#eliminate_false_positives
• https://quarkus.io/guides/cdi-reference#declaratively-choose-beans-that-can-be-obtained-by-programmatic-lookup

[radcortez]

@gigi I've opened a PR that should help with this case: #50897

Do you want to try it out? Thanks!

[gigi]

Hi @radcortez,
Sorry, I had a lot of work…)

quarkus.redis.simple.hosts -> OK
quarkus.redis."simple".host -> same as quarkus.redis.simple.hosts

I think it should be .hostS not .host for the second line.

It seems we should not use the quoted variant because Quarkus won't start at all:

The application contains a @RedisClientName("simple"), but the application configuration does not configure this redis client configuration with that name. You must at least configure quarkus.redis."simple".hosts.

We also encountered another bug, and I still don’t have a precise idea why it happens.
We have YAML config like this:

...
quarkus:
  redis:
    hosts: redis://dummy:6379
    max-pool-size: 20
    max-pool-waiting: 100
    tournament:
      hosts: redis://dummy:6379
...

And code that uses a named client:

@ApplicationScoped
public class RedisLeaderboardProvider implements LeaderboardProvider {
    private static final String REDIS_TOURNAMENT_CLIENT_NAME = "tournament";
    ...
    public RedisLeaderboardProvider(
        @RedisClientName(REDIS_TOURNAMENT_CLIENT_NAME) RedisDataSource dataSource) {
        this.redisDataSource = dataSource;
    }
}

When we use QUARKUS_REDIS__TOURNAMENT__HOSTS in some environments, it is not overridden, and we see a failed health check:

SRHCK01001: Reporting health down status: {"status":"DOWN","checks":[{"name":"Startup Health Check","status":"DOWN","data":{"Beans":272,"JPA Entities":40,"Health Checks":3,"Health Checks Errors":"io.quarkus.redis.runtime.client.health.RedisHealthCheck_ClientProxy","Error Summary":"Failed to warm up 1 health checks"}}]}

We have to use QUARKUS_REDIS_TOURNAMENT_HOSTS.

BUT
some deployments work properly with QUARKUS_REDIS__TOURNAMENT__HOSTS. Its the same jvm build, same Helm chart, but different set of enabled/disabled envs. This is driving me crazy, and I still don’t know the exact reason for this :)

By the way, if you have any better ideas on how to handle these scenarios, I’d be happy to hear them :)

I understand the problem you were trying to solve using quotes, but it seems they cause a lot of headaches. Maybe it’s better to avoid dots in key names entirely :)
If I remember correctly, Spring doesn’t handle mapping from environment variables properly in this case either.

@gigi I've opened a PR that should help with this case: #50897
Do you want to try it out? Thanks!

Wow… so fast! Yes, we’d like to try it. This will solve our the Feature Flag approach with Redis.

By the way, is it possible to create a named Redis client at runtime (so we can use all provided defaults and health checks out of the box)?

Sorry for asking so many questions. We’re trying to use Quarkus for an enterprise SaaS platform, so we have many requirements and sometimes unusual use cases :)

[radcortez]

I think it should be .hostS not .host for the second line.

Correct. Sorry for the error

It seems we should not use the quoted variant because Quarkus won't start at all:

This should work. I did try it out with your reproducer, and it works. Just added a explicit injection point to client2:

    @Inject
    @RedisClientName("client2")
    RedisDataSource client2;

Then, without quotes:

🌀 java -Dquarkus.redis.client2.hosts=redis://localhost:6379 -jar target/quarkus-app/quarkus-run.jar
Application is starting up!
===========================================
Named Redis Client: client2
Effective hosts value: redis://localhost:6379
===========================================
Named Redis Client: default
Effective hosts value: redis://dummy:6379
--- Trying to select client2 connection ---
ds2 found: true
--- Trying to select client3 connection from runtime ---
ds3 found: false
--- Trying to select client4 connection from runtime ---
ds4 found: false
--- All redis host properties detected ---
quarkus.redis.client2.hosts = redis://localhost:6379
quarkus.redis.hosts = redis://dummy:6379
__  ____  __  _____   ___  __ ____  ______
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/
2025-11-07 13:11:56,043 INFO  [io.quarkus] (main) code-with-quarkus 1.0.0-SNAPSHOT on JVM (powered by Quarkus 999-SNAPSHOT) started in 0.303s. Listening on: http://0.0.0.0:8080
2025-11-07 13:11:56,046 INFO  [io.quarkus] (main) Profile prod activated.
2025-11-07 13:11:56,046 INFO  [io.quarkus] (main) Installed features: [cdi, redis-client, smallrye-context-propagation, smallrye-health, vertx]

With quotes:

🌀 java -Dquarkus.redis."client2".hosts=redis://localhost:6379 -jar target/quarkus-app/quarkus-run.jar
Application is starting up!
===========================================
Named Redis Client: client2
Effective hosts value: redis://localhost:6379
===========================================
Named Redis Client: default
Effective hosts value: redis://dummy:6379
--- Trying to select client2 connection ---
ds2 found: true
--- Trying to select client3 connection from runtime ---
ds3 found: false
--- Trying to select client4 connection from runtime ---
ds4 found: false
--- All redis host properties detected ---
quarkus.redis.client2.hosts = redis://localhost:6379
quarkus.redis.hosts = redis://dummy:6379
__  ____  __  _____   ___  __ ____  ______
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/
2025-11-07 13:12:37,470 INFO  [io.quarkus] (main) code-with-quarkus 1.0.0-SNAPSHOT on JVM (powered by Quarkus 999-SNAPSHOT) started in 0.319s. Listening on: http://0.0.0.0:8080
2025-11-07 13:12:37,473 INFO  [io.quarkus] (main) Profile prod activated.
2025-11-07 13:12:37,473 INFO  [io.quarkus] (main) Installed features: [cdi, redis-client, smallrye-context-propagation, smallrye-health, vertx]

some deployments work properly with QUARKUS_REDIS__TOURNAMENT__HOSTS. Its the same jvm build, same Helm chart, but different set of enabled/disabled envs. This is driving me crazy, and I still don’t know the exact reason for this :)

This is because you must use the same configuration style, meaning that if you use the quoted format, you must use the quoted format for the same name across all sources, so you cannot mix quoted and unquoted configuration when referring to the same name.

In same environments, work and others don't because it is subject to the iteration order of keys. The YAML file name is unquoted as quarkus.redis.tournament.hosts and environment QUARKUS_REDIS__TOURNAMENT__HOSTS, which gets converted back to quarkus.redis."tournament".hosts. So when iterating the list of names, you get one from the YAML source and the other from the EnvSource. The first one found is the style we use to retrieve the remaining configuration. The issue here is that a source like SystemProperties, both quarkus.redis.tournament.hosts and quarkus.redis."tournament".hosts. are totally different, so we need to query the exact String as it was set in the source. I have considered doing a double lookup with quoted or unquoted, but it can explode into a huge number of lookups depending on the mapping tree, so I've used this approach.

I understand the problem you were trying to solve using quotes, but it seems they cause a lot of headaches. Maybe it’s better to avoid dots in key names entirely :)
If I remember correctly, Spring doesn’t handle mapping from environment variables properly in this case either.

Yes, unfortunately, I think there is no good solution for this. My recommendation is to only use quotes when the name is a multiple segment path and use the same style when configuring the name across multiple sources.

By the way, is it possible to create a named Redis client at runtime (so we can use all provided defaults and health checks out of the box)?

Even with that PR, it would still require the name available at build time, either with an injection point name or a configuration property name, to be able to create the runtime connection.

It should be possible to lift that restriction, but that is something we have to discuss. My concern was to keep it consistent with what the JDBC extension is doing, which will always require build-time configuration because of the datasource kind.

Sorry for asking so many questions. We’re trying to use Quarkus for an enterprise SaaS platform, so we have many requirements and sometimes unusual use cases :)

No worries. We are here to help :)

[gigi]

java -Dquarkus.redis."client2".hosts=redis://localhost:6379 -jar target/quarkus-app/quarkus-run.jar

Interesting.
It doesn't work only when we put the quoted client name into application.properties.

quarkus.log.level=debug
quarkus.redis.hosts=redis://dummy:6379
quarkus.redis."simple".hosts=redis://dummy:6379
#quarkus.redis."client2".hosts=redis://dummy:6379
# - The application contains a @RedisClientName("client2"), but the application configuration does not configure this redis client configuration with that name. You must at least configure `quarkus.redis."client2".hosts`.
quarkus.redis.client2.hosts=redis://dummy:6379

Is this expected behavior?
I pushed a reproduction here: https://github.com/gigi/quarkus-redis-bugs/blob/main/src/main/resources/application.properties#L3

java -jar target/quarkus-app/quarkus-run.jar

2025-11-07 16:03:37,218 DEBUG [io.qua.run.uti.NoopShutdownScheduledExecutorService] (vert.x-eventloop-thread-1) shutdownNow() not allowed on managed executor service
2025-11-07 16:03:37,220 DEBUG [io.qua.thread-pool] (main) loop: 1, remaining: 60000000000, intervalRemaining: 5000000000, interruptRemaining: 10000000000
The application contains a @RedisClientName("simple"), but the application configuration does not configure this redis client configuration with that name. You must at least configure `quarkus.redis."simple".hosts`.
2025-11-07 16:03:37,221 DEBUG [io.qua.run.Application] (main) Stopping application

So when iterating the list of names, you get one from the YAML source and the other from the EnvSource

Hmm… If I understand correctly, the boot/merge order depends on how the environment variables are provided.
So if the JAR reads the unquoted name from YAML first, then the system environment override __TOURNAMENT__ is ignored — and vice versa? I'll review the passed envs...

It should be possible to lift that restriction, but that is something we have to discuss. My concern was to keep it consistent with what the JDBC extension is doing, which will always require build-time configuration because of the datasource kind.

Yes, yor PR will work for our initial use case.

For the multitenant database approach, we are using Hibernate multitenant connection appoach, which allows us to create connections at runtime using remote config per tenant.
Now I'm trying to implement something similar for other data sources.

[radcortez]

Is this expected behavior?

No. This is an issue with the current extension, which should be fixed in the proposed PR #50897

Hmm… If I understand correctly, the boot/merge order depends on how the environment variables are provided.
So if the JAR reads the unquoted name from YAML first, then the system environment override __TOURNAMENT__ is ignored — and vice versa? I'll review the passed envs...

Yes. The rule is to always use the same style for all the related configuration names. If you have quarkus.redis.one.hosts, then you use unquoted version of Env QUARKUS_REDIS_ONE_HOSTS. If you have a quoted version quarkus.redis."two".hosts, then you have to use the quoted Env QUARKUS_REDIS__TWO__HOSTS. You can use the quoted / unquoted with different names, but you cannot mix quoted and unquoted within the same name.

For the multitenant database approach, we are using Hibernate multitenant connection appoach, which allows us to create connections at runtime using remote config per tenant.

Let me discuss this with the rest of the team.