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 BSD-3-Clause and free to self-host, with enterprise governance features under a separate licence, and you operate Django, Postgres, and the React admin.

Flagsmith Cloud has a free plan (50,000 requests a month, 1 team member) and a Start-Up plan at $45/month (1,000,000 requests, 3 team members). dif Cloud is $50/month for 1M events with unlimited seats and has no free 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 gives an agent its Management API through an MCP server.

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 prices by API requests and team members. Free covers 50,000 requests a month and 1 member. Start-Up is $45/mo for 1,000,000 requests and 3 members. Scale-Up is $300/mo for 5,000,000 requests. Enterprise is a quote.

Rule changes outside code review. Every rule change goes through the admin UI or the API. 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/experiments/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

Dimension	dif	Flagsmith
Where flags live	Markdown files in your repo	PostgreSQL, served by a Django admin API
Server to run	None	Django + React admin UI + PostgreSQL
License	Open source (MIT)	Open source (BSD-3-Clause), free to self-host; enterprise features licensed separately
Admin UI	None; pull request review	Yes, React admin app
Language SDK breadth	JavaScript and TypeScript, with React and Svelte adapters	15+ languages (Python, Java, Go, Ruby, .NET, Flutter, others)
Cloud entry price	$50/mo, 1M events, unlimited seats	Free plan with 50,000 requests and 1 member; $45/mo Start-Up with 1M requests and 3 members
Self-hosting cost	No server; the repo is the source of truth	Free, but you host Django, Postgres, and the admin
Change a flag	Edit the file, open a PR, merge, deploy	Change in the admin UI; SDK picks up the new rule
Agent-readable state	Yes (`context.json`)	Through its MCP server and Management API, with a key
Remote config and segmentation	Frontmatter audiences	Mature: remote-config values, segments, MCP server for AI feature management

For a row-by-row table with a dated source for each Flagsmith claim, see dif vs Flagsmith.

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/experiments/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
hypothesis: >
  The new checkout lifts completed checkouts on mobile and tablet.
audience:
  include:
    - device_type: [mobile, tablet]
variants:
  - id: "off"
    weight: 90
  - id: "on"
    weight: 10
metrics:
  primary: completed_checkout
  guardrails:
    - refund_rate
created: 2026-09-01
---

## 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, dif build writes the 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.

Pricing with no seat limit. 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/experiments/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";

const checkout = dif("new-checkout", {
  off: () => <LegacyCheckout />,
  on: () => <NewCheckout />,
});
return checkout();

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
error E005 dif/experiments/active/new-checkout.md:1:1: variant weights sum to 95, expected 100
  help: Distribute the variants so the weights total 100.
warning W001 src/checkout/index.tsx:42:1: orphan ref: `new_checkout` is not an active experiment
  help: Either create the experiment or remove the dif() call.

✗ 1 error(s), 1 warning(s)

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 has a free plan with 50,000 requests a month and 1 team member, and its Start-Up plan is $45/month for 1,000,000 requests and 3 team members (see Flagsmith pricing). dif Cloud is $50/month for 1M events with unlimited seats and has no free tier. Flagsmith meters API requests and team members; dif Cloud meters events.

Does dif have a dashboard? No. The flag is a file in your repo, and changing it is a pull request. ls dif/experiments/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 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.

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