Flagsmith: Open Source Feature Flags and Remote Config Without the LaunchDarkly Bill

Feature flags are one of those engineering practices that feel optional until you've shipped a broken feature to everyone at once and spent the next three hours on an emergency rollback. Once you've experienced that, you start thinking about how to separate deployment from release — push code whenever it's ready, turn it on for real users only when you're confident.

LaunchDarkly is the category leader and it's excellent. It's also expensive — pricing that made sense when you had ten flags and a hundred users starts hurting at scale. Flagsmith is the open source alternative: the same feature flag and remote config workflow, BSD-3-Clause licensed, self-hostable for free with no user or request limits, or available as managed cloud starting at $45/month.

What Flagsmith is

Flagsmith is an open-source feature flag and remote configuration platform. It lets you toggle features on or off in production without deploying new code, target flags to specific users or segments based on traits, run percentage-based rollouts, and change application configuration values at runtime. It's written in Python (Django) on the backend with a React frontend, BSD-3-Clause licensed, and has 6,300+ GitHub stars.

The core value proposition: decouple deployment from release. Deploy code continuously, control who sees new features through flag targeting. Ship faster because new code is off by default. Roll back instantly by flipping a flag — no code change, no redeployment, no waiting for pipelines.

Flagsmith covers three categories of use:

• Feature flags — boolean on/off controls for features, per environment, per user, per segment
• Remote configuration — string, number, or JSON values you can change at runtime without a deployment
• A/B testing and multivariate flags — percentage-based rollouts and variant testing across user segments

The license — BSD-3-Clause

Flagsmith uses the BSD 3-Clause license — one of the most permissive OSI-approved open source licenses available. No commercial-use restrictions, no multi-tenant clauses, no logo requirements. Self-host it, fork it, modify it, use it in commercial products — BSD 3-Clause permits all of it without any conditions beyond attribution.

This matters in the feature flag space because several competitors use source-available licenses or have moved to more restrictive terms. Flagsmith's core functionality stays open, always — the team has committed to this explicitly. Enterprise governance features (audit logs, SAML SSO, role-based access control, change requests) require an Enterprise license, but the core flag management is BSD-3-Clause forever.

How feature flags work in Flagsmith

The mental model is straightforward. You create a flag in the Flagsmith dashboard, set its default state per environment (development, staging, production), and query it in your application code via an SDK:

# Python SDK
from flagsmith import Flagsmith

flagsmith = Flagsmith(environment_key="your-env-key")

# Simple boolean flag
flags = flagsmith.get_environment_flags()
if flags.is_feature_enabled("new_dashboard"):
    render_new_dashboard()
else:
    render_legacy_dashboard()

# Remote config value
api_rate_limit = flags.get_feature_value("api_rate_limit")  # returns 100, or whatever you set in dashboard

For user-level targeting, you pass an identity:

# Target flags to a specific user with traits
flags = flagsmith.get_identity_flags(
    identifier="user-123",
    traits={"plan": "pro", "country": "sk", "days_since_signup": 14}
)

if flags.is_feature_enabled("pro_export_feature"):
    # Only Pro users see this
    enable_export()

The SDK caches flag state locally. Evaluation happens in-process — no network round-trip on each flag check. Flags update in the background and propagate globally in under 100ms.

Environments and targeting

Flagsmith organizes flags across environments — development, staging, production, or any custom environments you define. The same flag can be on in development, rolling out to 10% in staging, and off in production. Each environment has its own API key.

Segments let you target groups of users based on traits: "all users on Pro plan", "users who signed up in the last 30 days", "users in the EU". Create a segment, assign a flag to it, and every user matching the trait criteria gets the flag — without code changes.

Percentage rollouts let you gradually increase exposure: start a new feature at 1% of users, watch error rates, expand to 10%, then 50%, then full rollout. If something goes wrong, set it back to 0% — instant rollback without a deployment.

Multivariate flags support A/B and multivariate testing: define variants with string or JSON values, assign percentages, and different users get different variants consistently. Track which variant each user got for analysis.

Remote configuration

This is the underrated half of Flagsmith. Feature flags are boolean — on or off. Remote config is a flag with a value — a string, number, or JSON object you can change at runtime.

Practical examples:

• Change the number of items per page without a deployment: items_per_page = 25 → 50
• Update copy, colors, or promotional banners in real time
• Control rate limits, timeouts, or cache TTLs without touching code
• Store entire JSON configs for complex feature behavior: {"max_file_size_mb": 10, "allowed_types": ["pdf", "csv"]}
• Version prompt templates for AI features without redeploying

The last one is increasingly relevant: teams building LLM features use remote config to iterate on system prompts, model parameters, and temperature settings in production without code changes. Update the prompt, watch the results, roll back if needed — same deploy-free workflow as feature flags.

The Edge Proxy

For latency-sensitive applications, Flagsmith ships an Edge Proxy — a lightweight service you deploy close to your application. It caches all flag data locally and evaluates flags in-process with sub-millisecond latency, no network call to the Flagsmith API. The proxy syncs with the API in the background.

This is particularly valuable for server-side applications where flag evaluation happens on every request — you get the developer experience of Flagsmith without adding latency to your request path.

SDK support

Flagsmith supports 15+ official SDKs: JavaScript/TypeScript, Python, Go, Ruby, PHP, Java, .NET, iOS/Swift, Android/Kotlin, Flutter, Rust, Elixir, Node.js, and more. Each SDK supports both server-side and client-side evaluation modes. The OpenFeature provider means Flagsmith works with the OpenFeature standard if you want to keep your flag evaluation code vendor-neutral.

MCP Server for AI agents

Worth highlighting for teams building AI-assisted workflows: Flagsmith ships an official MCP Server that lets AI agents manage feature flags directly from IDEs and CI/CD pipelines. An agent can read current flag states, toggle flags, and adjust remote config values as part of an automated deployment workflow — without leaving the agentic loop. This is a newer capability that maps well to AI-first development workflows where you want the LLM to manage flag state during a deployment.

Self-hosting Flagsmith

Docker Compose is the standard path for self-hosting. Flagsmith requires PostgreSQL and optionally Redis for caching:

# Clone and start
git clone https://github.com/Flagsmith/flagsmith.git
cd flagsmith/docker
docker compose -f docker-compose.yml up -d

The default Docker Compose setup includes the API, frontend, PostgreSQL, and an NGINX proxy. For production you'll want to configure:

• A proper PostgreSQL instance with backups
• SMTP for user invitations and notifications
• Traefik or Nginx in front for HTTPS
• Optionally Redis for the Edge Proxy caching layer

Self-hosted Flagsmith has no user limits, no request limits, and no feature limitations on the core platform. You pay for infrastructure, not for usage. Enterprise features (SAML SSO, audit logs, RBAC, change requests, scheduled flags) require an Enterprise license — but for most teams the open source core covers everything they need.

Minimum server size: 1 CPU core and 2GB RAM for a small team. The API is lightweight and the main resource consumer is PostgreSQL.

Terraform provider

Flagsmith has an official Terraform provider, which deserves a mention for DevOps-first teams. Managing flags as code means:

resource "flagsmith_feature" "new_dashboard" {
  feature_name = "new_dashboard"
  project_id   = var.project_id
  description  = "New dashboard redesign"
  type         = "STANDARD"
  default_enabled = false
}

resource "flagsmith_feature_state" "new_dashboard_production" {
  environment_key = var.prod_environment_key
  feature_id      = flagsmith_feature.new_dashboard.id
  enabled         = false  # off in production until ready
}

Flags live in version control. Changes go through pull requests. State is auditable. No configuration drift between environments. For teams already managing infrastructure as code with Terraform, this is the natural way to manage flags too.

Flagsmith vs the alternatives

vs LaunchDarkly — LaunchDarkly is the category leader: mature, polished, deeply integrated with every CI/CD tool imaginable, with the best analytics and experimentation features in the space. It's also priced for enterprises — the cost becomes significant at scale. Flagsmith covers the core use cases (flags, targeting, rollouts, remote config) at a fraction of the cost or free when self-hosted. LaunchDarkly wins on depth and ecosystem; Flagsmith wins on cost and data ownership.

vs Unleash — Unleash is the other major open source feature flag platform, also Apache 2.0 licensed. Unleash has strong enterprise features and is particularly well-regarded for large-scale deployments in regulated industries. Flagsmith has a cleaner UI, better remote config story, and a more approachable onboarding. Both are solid choices — evaluate based on your specific scale and compliance requirements.

vs GrowthBook — GrowthBook is open source and focused on A/B testing and experimentation with feature flags as a secondary capability. If your primary use case is statistical experimentation and conversion optimization, GrowthBook is worth considering. If you want feature flags with targeting and remote config with experimentation as a secondary feature, Flagsmith fits better.

vs self-built — some teams build their own feature flag system with Redis and a config service. This works until it doesn't — you end up building targeting, environments, audit logs, SDKs, and a dashboard. Flagsmith gives you all of that, maintained by a dedicated team, for free when self-hosted. The opportunity cost of building and maintaining your own flag system is almost never worth it.

Who it's for

Good fit:

• Teams practicing continuous deployment who want to separate deploy from release
• Organizations with compliance or data residency requirements that rule out SaaS flag tools
• Teams currently paying LaunchDarkly and looking for a cost-effective alternative
• DevOps-first teams who want to manage flags as code via Terraform
• Teams building LLM features who want to iterate on prompts and model params without redeploying
• Anyone who has ever done a 2am rollback by reverting a commit and redeploying

Not the right fit:

• Teams primarily needing deep statistical experimentation — GrowthBook or LaunchDarkly are better
• Very small teams with simple release processes where flags add complexity without proportional value
• Teams that need enterprise governance features (SAML, RBAC, audit logs) on the open source tier — those require the Enterprise license

My take

Feature flags are one of those practices that feel like overhead until they save you. The first time you ship a bad feature to 100% of users and have to roll it back via a deployment, you'll want a flag. The first time you graduate a feature from 1% to 100% over a week, watching metrics the whole way, you'll understand why the category exists.

Flagsmith is the right open source answer to this problem. BSD-3-Clause with no commercial restrictions, self-hostable for free with no usage limits, 15+ SDKs, and a clean UI that non-engineers can use. The remote config capability extends the value beyond pure feature toggling — being able to change application behavior at runtime without a deployment is genuinely useful for everything from copy changes to AI prompt tuning.

For any team running self-hosted infrastructure and doing continuous deployment, Flagsmith is a natural addition to the stack. One more Docker Compose deployment, and you gain the ability to deploy code confidently and control releases deliberately — which is, ultimately, what CI/CD is supposed to give you.