← Blog

The open-source Flagsmith alternative: no server, flags in your repo

The open-source Flagsmith alternative: no server, flags in your repo

dif is the open-source Flagsmith alternative that keeps every flag as a Markdown file in your repo, so there is no Django server, no PostgreSQL, and no admin dashboard to run. Flagsmith is a solid, established open-source tool. It ships a Django backend, a React admin UI, and a PostgreSQL database that your application talks to. dif deletes all three. A flag is one .md file next to the code it changes, reviewed in a pull request, versioned in git.

Both tools are open source. dif runs from your repo with nothing separate to host; Flagsmith is a server you can self-host or pay to have hosted. The split is where the flag lives: a row in a Postgres table your server serves, or a file in your repo your CI validates. This post covers what changes when you move that split, what you give up, and where Flagsmith still wins.

Key Takeaways

  • dif keeps flags as Markdown files in your repo. Flagsmith stores flags in a PostgreSQL database served by a Django admin API.
  • Both are open source. dif is MIT licensed with no server to run. Flagsmith is self-hostable free with no feature limits, but you operate Django, Postgres, and the React admin.
  • Flagsmith Cloud starts at $45/month for the Start-Up tier (up to 15,000 MAU). dif Cloud is $50/month for 1M events with unlimited seats and no per-MAU tier.
  • Flagsmith supports 15+ language SDKs. dif’s SDK is JavaScript and TypeScript, with React and Svelte adapters.
  • dif emits a context.json a coding agent reads on session start. Flagsmith’s admin UI cannot pass that state to an agent.

Why teams look for a Flagsmith alternative

Flagsmith works. Teams go shopping for one of four reasons.

Running the server. Flagsmith is a Django app plus a React admin UI plus a PostgreSQL database. Self-hosting means patching that stack, backing up Postgres, and owning an on-call for the admin API.

Drift. The flag is a row in a database served over an API. The code that reads it lives in a repo. Nothing links the two, so a Flagsmith flag can outlive the feature it gated because deleting it is a dashboard task nobody owns.

The tier ceiling. Flagsmith Cloud’s Start-Up tier caps at 15,000 monthly active users, Growth at 80,000. The bill jumps at each threshold: $45/mo to $149/mo to $300/mo, then to a $3,999/year Enterprise contract.

Admin-only rule changes. Every rule change goes through the admin UI. A junior engineer cannot change a flag in a pull request the way they change a config file, so the flag workflow lives outside code review.

dif as the alternative in one paragraph

dif takes the flag out of the database and makes it a file. dif init writes a dif/ directory next to your source. Each flag is a Markdown file with YAML frontmatter (id, owner, variants, weights) and prose below (the brief, the decision, the learning). dif validate runs in CI. dif build compiles the active files into a typed client your app imports. The flag lives with the code, is reviewed in a pull request, and its history is the git history. See the feature flags in your repo page for the full model.

The model, side by side

Flagsmith is a service. The Django admin API stores flag rules in Postgres, and your app queries them over HTTPS. A rule change is a POST to that API from the dashboard, and every client that polls or streams sees the change. That earns you an operator UI and a change that takes effect without a deploy.

dif is a file format. The flag is a Markdown file in dif/flags/active/. Changing a rule is editing that file and merging. The application imports a generated TypeScript client, and the SDK computes assignment locally by hashing the user ID. No service to call, no database to keep in sync.

Flagsmith’s model is optimized for an operator changing a flag right now from a UI. dif’s model is optimized for a codebase where a flag is a change to code review, and where the reviewer wants to see the rule and the call site in the same pull request.

Feature comparison

DimensiondifFlagsmith
Where flags liveMarkdown files in your repoPostgreSQL, served by a Django admin API
Server to runNoneDjango + React admin UI + PostgreSQL
LicenseOpen source (MIT)Open source, 100% self-hostable free
Admin UINone; pull request reviewYes, React admin app
Language SDK breadthJavaScript and TypeScript, with React and Svelte adapters15+ languages (Python, Java, Go, Ruby, .NET, Flutter, others)
Cloud entry price$50/mo, 1M events, unlimited seats$45/mo Start-Up, up to 15,000 MAU; $149/mo Growth to 80,000 MAU
Self-hosting costNo server; the repo is the source of truthFree, but you host Django, Postgres, and the admin
Change a flagEdit the file, open a PR, merge, deployChange in the admin UI; SDK picks up the new rule
Agent-readable stateYes (context.json)No; state lives behind an authenticated API
Remote config and segmentationFrontmatter audiencesMature: remote-config values, segments, MCP server for AI feature management

Where Flagsmith wins

Flagsmith earns four rows outright.

Broad language SDKs. If your backend is Ruby, Java, Python, .NET, or Flutter as well as JavaScript, Flagsmith already ships an SDK for each. dif does not close that gap.

The admin UI. A non-engineering flag owner, a growth PM changing a rollout percentage or a support engineer flipping an ops kill switch, gets a dashboard designed for the job. dif has no dashboard; a rule change goes through code review.

Remote configuration. Flagsmith stores arbitrary values keyed by flag and segment, so a rollout can carry a threshold, a copy string, or a config blob. dif’s frontmatter is not tuned for a large remote-config store.

The MCP server for AI feature management. Flagsmith ships an MCP server so an assistant can read and change flags over the Flagsmith API, alongside the admin UI.

Where dif wins

The flag is the file. dif/flags/active/new-checkout.md is the whole thing. Opening it answers “why does this exist” without a dashboard. Deleting it is a commit.

---
id: new-checkout
status: active
owner: sam@acme.com
surface: checkout
audience:
  include:
    - device_type: [mobile, tablet]
variants:
  - id: "off"
    weight: 90
  - id: "on"
    weight: 10
metrics:
  primary: completed_checkout
  guardrails:
    - refund_rate
---

## Brief

Ramping to 25% once the guardrails hold for a week. Owner is Sam.

No server, no PostgreSQL, no admin UI. Nothing to patch, back up, or pay on-call for. dif init scaffolds the dif/ directory and a generated client, and the CLI and SDK are the whole runtime.

Pull-request review is the approval flow. dif validate runs in CI, so a broken flag fails the pull request like a broken build.

Agent-readable state through context.json. dif build writes every active flag and each surface’s latest learning to a file the coding agent reads on session start. See context.json explained for how the agent uses it.

Flat pricing that does not scale per MAU. dif Cloud is $50/month for 1M events with unlimited seats. A ten-person team and a fifty-person team pay the same base price.

Who should switch, and who should stay on Flagsmith

Stay on Flagsmith if any of these are true:

  • Your backend is a mix of Ruby, Java, Python, or .NET and you need every service on a supported SDK today. dif’s SDK is JavaScript and TypeScript with React and Svelte adapters.
  • A non-engineering flag owner is the primary user of the tool. A growth PM changing a rollout percentage from a dashboard is Flagsmith’s model, not dif’s.
  • You need a large remote-config store keyed by segment and want a running server to serve it to many clients over the network.

Switch to dif if any of these are true:

  • The flag is a code-review artifact. A rule change should get a PR review next to the call site it gates.
  • You are tired of operating the Flagsmith server, or self-hosting is more infra than you want to own. dif’s whole runtime is the CLI and the 5 kB SDK.
  • A coding agent works with your flags. Claude Code, Cursor, or any agent reads context.json on session start. See the agent skills docs for authoring flags with an agent in the loop.

What migration looks like

Migration is per-flag. The format is small enough that porting by hand is often faster than automation.

Install the CLI and scaffold the workspace:

npm install -g @dif.sh/cli
dif init

Pick one active Flagsmith flag. Recreate it as a Markdown file in dif/flags/active/. Map the fields:

  • feature_name becomes dif’s id
  • enabled and per-environment values become variants and weights
  • Segments become dif’s audience.include and audience.exclude blocks
  • Multivariate values become named variants with weights

A Flagsmith call in TypeScript:

import flagsmith from "flagsmith";

if (flagsmith.hasFeature("new-checkout")) {
  return <NewCheckout />;
}
return <LegacyCheckout />;

The dif equivalent:

import "./dif/generated/client";
import { dif } from "@dif.sh/sdk";

if (dif("new-checkout") === "on") {
  return <NewCheckout />;
}
return <LegacyCheckout />;

Run dif validate in CI. If the port is broken, the CI check catches it in the same pass that would catch a bad flag file:

$ dif validate

E004  dif/flags/active/new-checkout.md
      Weights do not sum to 100 (got 95).

E011  src/checkout/index.tsx:42
      dif("new-checkout") returns variant "off" | "on".
      Comparison against boolean will never match.

2 errors, 0 warnings.

Fix both. Merge the pull request. Port one flag a week, delete the Flagsmith call site as you go, and shut off the Flagsmith server the day the last flag lands. The feature flags in git post covers the day-to-day workflow once the flags live in the repo.

FAQ

Is dif a Flagsmith alternative? Yes. Both are open source and both handle feature flags. The difference is where the flag lives: dif stores each flag as a Markdown file in your repo; Flagsmith stores flags in a PostgreSQL database served by a Django admin API.

Can I self-host dif? Yes, and there is nothing to host for the core flag workflow. The CLI and SDK are MIT licensed and run entirely from your repo. dif Cloud is an optional hosted analytics layer at cloud.dif.sh; you can skip it entirely.

How do dif’s SDKs compare to Flagsmith’s? Flagsmith wins on breadth: SDKs for 15+ languages including Python, Java, Go, Ruby, .NET, and Flutter. dif’s SDK is JavaScript and TypeScript with React and Svelte adapters. For a JS or TS stack, dif fits; for polyglot backends, Flagsmith fits.

What is the cheapest feature-flag tool? Both cores are free. Flagsmith is free to self-host its server; dif has nothing separate to host, since the CLI and SDK run locally in your repo. For managed cloud, Flagsmith’s Start-Up tier is $45/month for up to 15,000 MAU (see Flagsmith pricing). dif Cloud is $50/month for 1M events with unlimited seats. dif’s price does not step up by MAU; Flagsmith’s does at 15k, 80k, and above.

Does dif have a dashboard? No. The flag is a file in your repo, and changing it is a pull request. ls dif/flags/active/ is the state of everything in flight.

What is the tradeoff with dif? Rolling back a flag is a merge and a deploy, not a sub-second dashboard toggle. If your build takes ten minutes, your worst-case kill is ten minutes. For a payment path that needs a sub-second kill switch, keep a streaming flag service for that one flag.

Try dif as your Flagsmith alternative

The Flagsmith alternative worth considering is the one that fits your model. If the flag is a code-review artifact, if your team already lives in git, and you would rather not run a Django server to hold a few dozen boolean rows, dif is the shorter path. If you need broad backend-language SDKs or a dashboard for a non-engineering owner, stay on Flagsmith.

Install the CLI and scaffold a project. No account, no API key, no admin.

npm install -g @dif.sh/cli
dif init

dif init writes the dif/ directory, a generated TypeScript client, and the managed agent guidance blocks. From there, dif new drafts a flag, dif validate runs in CI, and dif build compiles the active files. The docs cover the CLI and SDK, and the open-source LaunchDarkly alternative and best feature flag tools 2026 posts cover the wider comparison landscape.