Quarkus Insights #258: Quarkus Feature Flags
By
This summary was generated using AI, reviewed by humans - watch the video for the full story.
Quarkus Insights #258: Quarkus Feature Flags
Feature flags are an essential tool in modern software engineering, enabling teams to toggle capabilities, roll out changes incrementally, and mitigate production incidents with runtime kill switches. While robust ecosystem solutions like OpenFeature and Unleash exist, enterprise developers often seek a simpler, more "Quarkus-idiomatic" way to evaluate dynamic configuration without heavy external infrastructure dependencies.
In episode 258, host Georgios Andrianakis welcomes Quarkus core developer Martin Kouba to showcase Quarkus Feature Flags—a lightweight, extensible extension designed to provide a unified API, rich CDI integration, and out-of-the-box support for database-backed flags, security identity context, and server-side rendering.
Quarkus News
Georgios kicked off the stream with a quick operational update:
* Security Releases: In response to CVE discoveries uncovered by automated coding agents across open source repositories, new maintenance and patch releases were shipped: 3.39.2, alongside LTS releases 3.33.2 and 3.27.5.2.
* Quarkus 4 Road Ahead: An initial alpha/preview of Quarkus 4 is targeted for release toward the end of the month, which will include key architectural evolutions and migration guidance.
Why Quarkus Feature Flags?
Quarkus already provides integration extensions for OpenFeature (quarkus-openfeature) and Unleash (quarkus-unleash). However, Martin explained the motivation behind building a dedicated, first-class feature flags extension:
-
Zero Infrastructure Overhead: Start directly in your application without needing external flag management servers or paid SaaS subscriptions.
-
Tight Quarkus Integration: Leverage native Quarkus paradigms like CDI beans, Dev UI inspection/editing, Hibernate ORM entities, and Qute server-side templates.
-
Dynamic Runtime Evaluation vs. Static Config: Unlike standard MicroProfile Config properties (which are resolved at build-time or startup), feature flags evaluate dynamically on every request based on runtime context (e.g., authenticated user identity, time of day, client IP, or database records).
Core Architecture: Flags, Providers, and Evaluators
The Quarkus Feature Flags model is built around three primary concepts:
| Component | Purpose |
|---|---|
|
Represents a feature toggle identified by a unique |
|
The source where flags originate (e.g., relational databases, static code annotations, config files, or remote services). Providers can configure caching rules (such as Time-to-Live / TTL). |
|
The dynamic engine that computes a flag’s runtime value based on contextual parameters (e.g., percentage rollouts, user roles, timezones). |
All Service Provider Interfaces (SPIs) are standard CDI beans annotated with @Identifier qualifiers, making them easily discoverable and customizable by application developers and extension authors. Furthermore, SPI implementations leverage non-blocking Mutiny Uni types under the hood to ensure seamless execution in reactive and event-loop environments.
Key Modules & Integrations
Quarkus Feature Flags offers modular building blocks out of the box:
-
Hibernate ORM / Panache: Expose JPA entities as flag sources using simple annotations (
@DBFlag). -
Security Integration: Built-in evaluators resolve flags against the active
SecurityIdentity(e.g., username hashing for gradual percentage rollouts). -
Qute Template Engine: Conditional rendering directly within HTML/Qute templates via
{if flag:isEnabled('flag-id')}or string lookups. -
Cron / Scheduling: Enable or disable features based on cron expressions (e.g., active only during specific business hours or days).
-
OpenFeature SPI Bridge: Provides a basic bridge for OpenFeature compliance where needed.
Live Demo: Flags in Action
Martin walked through a live demo using a sample application available on GitHub: mkouba/flags-insights. The demo illustrated multiple real-world feature flag patterns:
1. Database-Backed Feature Switches & Dev UI
Using a Panache entity mapped to a database table, Martin demonstrated enabling and disabling an announcement banner. In Quarkus Dev UI, developers can inspect all registered flags, view metadata, and modify values live in the database without restarting the application or redeploying code. Configurable TTL caching ensures the database is not hammered on every evaluation.
2. Gradual Rollouts with Security Identity
To release a beta feature gradually, an evaluator (quarkus-security-username-rollout) uses the logged-in user’s identity to determine whether the user falls within a configured rollout percentage (e.g., 50%). By modifying the rollout percentage metadata at runtime, access expands dynamically across the user base.
3. Code-First Flags via Bytecode Transformation
For lightweight use cases, developers can annotate static fields or methods with @RegisterFlag:
public class TipsFlags {
@RegisterFlag
public static int dashboardTipsShown = 3;
}Quarkus transforms class bytecode at build-time so that reads to the static field automatically delegate to the dynamic flag evaluation runtime.
4. Custom Evaluators & Security Augmentation
Martin showed how to implement a custom ThemeFlagEvaluator that checks the user’s timezone (augmented onto the SecurityIdentity via a custom SecurityIdentityAugmentor) to automatically switch between light and dark CSS themes.
5. Emergency Maintenance Kill Switch with Vert.x Routes
Using the programmatic Flags injection API inside a Eclipse Vert.x HTTP route filter, Martin demonstrated an emergency maintenance mode that checks for the presence of a filesystem trigger file and immediately short-circuits incoming traffic with an HTTP 503 response.
Key Takeaways
-
Lightweight & Idiomatic: Provides dynamic feature flag evaluation without the overhead of external microservices or third-party SaaS infrastructure.
-
Dynamic Contextual Evaluation: Flags evaluate at runtime using caller context (security identity, time of day, custom metadata) rather than fixed startup configuration.
-
First-Class Dev UI Support: Inspect, debug, and update database and config flags directly from the browser during development.
-
Built on CDI & Reactive Foundations: Flag providers and evaluators are CDI beans returning Mutiny
Uniinstances, making extension straightforward. -
Multiple Flag Types: Supports boolean switches, numeric limits, string selectors, and decimal thresholds.
-
Code-First Convenience: Use
@RegisterFlagon static fields to let Quarkus handle bytecode transformation and evaluation plumbing automatically. -
Built-In Caching: Built-in TTL cache support protects relational databases and external backends from redundant evaluation overhead.
-
Seamless Qute Integration: Evaluate feature flags directly within server-side templates for conditional UI rendering.
-
Extensible SPI: Easily integrate with custom databases, AWS Systems Manager Parameter Store, HashiCorp Consul, or custom REST backends.
-
Community Feedback Driven: The extension is actively gathering community feedback, bug reports, and use cases to steer upcoming roadmap enhancements.
Conclusion
Quarkus Feature Flags brings a clean, developer-friendly approach to feature toggling, balancing the simplicity of code-first annotations with the power of dynamic, CDI-driven runtime evaluators. Whether you need a quick kill switch, user-segmented canary rollouts, or database-driven dynamic configuration, the extension fits naturally into the Quarkus programming model.
