Feature Flags & Configuration
Relevant source files
The following files were used as context for generating this wiki page:
FixOps utilizes a flexible configuration system coupled with a robust feature flag architecture to manage application behavior, module availability, and environment-specific overrides. The system is designed to support both local YAML-based overlays and enterprise-grade feature flagging providers, allowing for dynamic control of the security decision engine's hot paths and experimental capabilities.
The configuration management logic centralizes the loading of environment variables and overlay files, while the feature flag registry provides a standardized interface for various providers. This dual-layered approach ensures that FixOps can transition seamlessly between a standard "demo" mode and a highly customized "enterprise" deployment.
Configuration Overlay System
FixOps employs an OverlayConfig system that merges default settings with user-provided overrides. This system is responsible for defining data directories, authentication strategies, and pipeline requirements.
Architecture and Loading Logic
The configuration is primarily driven by the load_overlay function, which attempts to resolve an overlay file (typically fixops.overlay.yml) from various paths, including the current working directory and a dedicated configuration directory.
The system ensures that critical paths like archive_dir and analytics_dir are properly mapped to the execution mode (e.g., demo vs. production).
Sources: core/configuration.py:45-99, apps/api/app.py:180-200
Key Configuration Elements
| Field | Type | Description |
|---|---|---|
mode | string | Execution mode: 'demo' or 'enterprise'. |
auth | dict | Map containing the authentication strategy (token/jwt) and header. |
data_directories | dict | Paths for artifacts, analytics, and evidence storage. |
toggles | dict | Boolean flags for features like strict_validation or capture_feedback. |
required_inputs | list | List of stages (design, sbom, etc.) needed for a pipeline run. |
Sources: core/configuration.py:105-150, config/feature_flags.example.yml:50-70
Feature Flag Architecture
The Feature Flag system allows for fine-grained control over specific modules and business logic without requiring code changes or service restarts.
Provider Registry and Factory
The architecture uses a factory pattern to instantiate flag providers. The FlagProviderFactory determines which implementation to use based on the presence of specific configuration keys, such as launch_darkly API keys.
The LocalProvider serves as the fallback, reading flags directly from the YAML configuration, while the LaunchDarklyProvider (if implemented) would interface with external SaaS for real-time updates.
Sources: core/flags/registry.py:5-20, core/flags/provider_factory.py:10-35
Categorization of Flags
Flags are organized by priority and functional area:
- P0: Critical Flags: Includes the global
kill_switch, risk model selection, and LLM provider toggles (OpenAI, Anthropic, Google). - P1: Module Flags: Controls the activation of pipeline modules such as
guardrails,compliance, andexploit_signals. - P2: Operational Flags: Manages rate limits, offline modes, and entitlement-based features.
- Branding Flags: Allows dynamic rebranding of the product name (e.g., "FixOps" to "Aldeci"), primary colors, and logos.
Sources: config/feature_flags.example.yml:25-100
Dynamic Rollouts and Experiments
The system supports complex rollout strategies through multi-variant experiments and percentage-based targets.
Percentage Rollouts
Features can be gradually released to a subset of tenants using a hash-based percentage logic.
fixops.feature.llm.sentinel:
percentage: 25
value: true
hash_key: tenant_id
Sources: config/feature_flags.example.yml:110-115
Multi-variant Experiments (A/B Testing)
Risk models and other algorithmic components can be tested against each other by defining variants and their respective traffic splits.
Conclusion
The configuration and feature flag system in FixOps provides the necessary abstraction to manage enterprise complexity. By decoupling feature activation from deployment and centralizing environment settings via the overlay system, developers can safely iterate on high-risk modules—such as LLM integrations and risk scoring models—while maintaining operational stability through circuit breakers and global kill switches.
Sources: core/configuration.py:10-30, config/feature_flags.example.yml:40-45