This page documents the feature flag system used to control application behavior through environment variables. Feature flags enable different deployment modes (hosted vs. self-hosted), optional features (social login, Ollama integration), and environment-specific configurations.
For general environment variable configuration, see Environment Variables. For Next.js-specific configuration including route-specific behavior, see Next.js Configuration.
The Sim platform implements a strict feature flag system that enforces configuration consistency across deployment environments. All feature toggles must derive their values from environment variables rather than hardcoded constants, ensuring that:
The feature flag configuration lives in `apps/sim/lib/core/config/feature-flags.ts` and is validated on every CI run to enforce naming conventions and prevent hardcoded boolean values.
Sources: .github/workflows/test-build.yml44-77
Sources: .github/workflows/test-build.yml44-77
The CI pipeline enforces two critical rules for feature flags:
Feature flags must not be assigned hardcoded true or false values. All boolean feature flags must derive their values from environment variables.
The validation uses Perl multiline regex to catch both single-line and multi-line assignments:
Sources: .github/workflows/test-build.yml52-59
All boolean feature flags must follow the naming convention is[FeatureName]. This makes the flag's purpose immediately clear and distinguishes it from getter functions.
The validation script checks for exports that don't start with is or get:
Sources: .github/workflows/test-build.yml62-69
The validation runs before linting, testing, and building, ensuring that feature flag violations prevent the entire build from proceeding.
Sources: .github/workflows/test-build.yml44-113
Feature flags typically follow these patterns when reading from environment variables:
| Pattern | Use Case | Example |
|---|---|---|
| Boolean from 'true' string | Simple on/off toggle | process.env.IS_HOSTED === 'true' |
| Boolean from presence | Check if defined | Boolean(process.env.FEATURE_KEY) |
| Boolean from URL presence | Service availability | Boolean(process.env.OLLAMA_BASE_URL) |
| String with fallback | Configuration value | process.env.APP_MODE ?? 'production' |
| Negation | Disable by default | process.env.DISABLE_FEATURE !== 'true' |
Based on the architecture and deployment patterns, the system likely includes flags such as:
Sources: Inferred from .github/workflows/test-build.yml44-77 .github/workflows/i18n.yml89 and system architecture
The validation script uses Perl with the -0777 flag to enable multiline matching, catching patterns like:
The regex pattern export const (is[A-Za-z]+)\s*=\s*\n?\s*(true|false)\b matches:
export const keywordistrue or falseThe validation uses grep with extended regex to find all exported constants that don't follow the naming convention:
This catches incorrectly named flags like:
enableFeature (should be isFeatureEnabled)hostedMode (should be isHosted)socialLogin (should be isSocialLogin)Sources: .github/workflows/test-build.yml44-77
When validation fails, the CI pipeline provides clear error messages:
❌ Feature flags must not be hardcoded to boolean literals!
Found hardcoded flags:
isHosted = true
isSocialLogin = false
Feature flags should derive their values from environment variables.
❌ Feature flags must use 'is' prefix for boolean flags!
Found incorrectly named flags:
hostedMode
socialLoginEnabled
Example: 'hostedMode' should be 'isHostedMode'
✅ All feature flags are properly configured
Sources: .github/workflows/test-build.yml58-77
Feature flags are imported throughout the application to conditionally enable features:
The isHosted flag likely controls major behavioral differences:
Sources: Inferred from .github/workflows/i18n.yml89 and system architecture
Feature flags are designed to work with Docker's multi-environment deployment model:
This allows the same image to be deployed with different feature configurations:
Sources: docker/app.Dockerfile71-86
When adding a new feature flag:
Use the 'is' prefix for boolean flags
Add a descriptive environment variable
Document the flag in the environment variables page (see Environment Variables)
Test locally before committing:
Let CI validate - the build will fail if conventions are violated
Combine flags for complex conditions:
Use appropriate defaults for different deployment scenarios:
Sources: Inferred from validation patterns in .github/workflows/test-build.yml44-77
Feature flag validation occurs at step 6, immediately after dependency installation and before any code quality checks. This fail-fast approach prevents invalid configurations from wasting CI time on subsequent steps.
Sources: .github/workflows/test-build.yml1-120
The Sim feature flag system enforces strict conventions through CI/CD automation:
| Aspect | Requirement | Enforcement |
|---|---|---|
| Values | Must derive from environment variables | Perl regex validation |
| Naming | Boolean flags use 'is' prefix | Grep pattern matching |
| Timing | Validated before lint/test/build | CI workflow ordering |
| Failure | Blocks PR merge | GitHub branch protection |
| Documentation | Self-documenting through naming | Convention enforcement |
This approach ensures that the platform remains flexible across deployment environments while maintaining code quality and preventing configuration drift.
Sources: .github/workflows/test-build.yml44-77 .github/workflows/ci.yml1-311
Refresh this wiki
This wiki was recently refreshed. Please wait 6 days to refresh again.