Flagward
Open sourceDjango + Redis, self-hostable, MIT licensed

Ship the deploy today.
Release the feature when you are ready.

Flagward separates deploying code from releasing it. Your SDK downloads the rules once and evaluates them inside your process in under a millisecond — and when you flip a flag, the change streams to every connected client over SSE.

app.flagward.com · free to try · no card

Flagward · production

live

new-checkout

Boolean · one-page checkout

checkout-cta

Multivariate · call to action

Change anything here. The app renders the new value in the same frame — nothing was fetched.

acme.shop/checkout

Express checkout

One page. One tap.

new-checkout
Apple Pay
Google Pay
Merino crew · 1×$128.00
Free returns within 30 days

Rendered from a locally evaluated flag — no request was made.

That is not a video. Flip the switch — the checkout on the right is reading the flag you just changed.

<1ms
local evaluation
SSE
real-time propagation
MIT
open source
docker compose up
The problem

Shipping code and releasing a feature are two different decisions

Most teams are forced to make them at the same moment. That single coupling is what turns a launch into a deploy window and a bug into an incident.

A release is a deploy

The feature goes live when the pipeline finishes. Timing a launch means timing a merge, and a rollback means another deploy.

With Flagward

Merge whenever the code is ready. Release by flipping a switch, at the moment you choose.

Rolling back takes minutes you do not have

Something breaks in production. Revert, rebuild, redeploy — and hope nothing else rode along in that commit.

With Flagward

Force the flag off. The override bypasses every rule, reaches connected clients immediately, and lands in the audit trail with its reason.

Every flag check costs a round trip

A flag service you call over HTTP puts the network on your render path — and takes your app down with it when it is unreachable.

With Flagward

Rules are downloaded once and evaluated in your process. A check costs nothing, works offline, and the user's context never leaves the client.

How it works

Four steps, and only one of them touches the network

Flagward is a control plane, not a dependency in your request path. The rules travel to your process once; after that, an evaluation is a function call.

  1. 01

    Create the flag

    In the dashboard, inside a project and an environment. You pick the key — it is the exact string your code will pass to useFlag.

    key: "new-checkout"
  2. 02

    The SDK downloads the rules

    Once, on init, authenticated with the environment's API key. One key scopes the SDK to one environment and nothing else.

    GET /api/v1/sdk/flags/
  3. 03

    Your app evaluates locally

    The evaluator runs in your process against the context you pass. No network on the render path, and no user attributes leaving the client.

    useFlag("new-checkout") → true
  4. 04

    Changes stream back in real time

    Flip a flag, adjust a rollout or pull the kill switch, and the new snapshot is pushed to every connected SDK over SSE.

    event: flags.updated

One trade-off, stated plainly. In a browser, local evaluation means the rules travel to the client — anyone can open devtools and read that you target plan == "enterprise". Do not put a secret in a targeting rule. When the rules themselves must stay server-side, Flagward also exposes remote evaluation via POST /api/v1/sdk/evaluate/.

Live demo

One flag, six users, and a kill switch

This is a real evaluator running in your browser with Flagward's rules. Change the state, the targeting, the rollout percentage or the override, and watch who the flag resolves to — and why.

new-checkoutproduction
2/6 users see it

Flag state

The configured on/off switch for this environment.

Targeting rule

plan in "pro,enterprise"

Rollout

60%

Each user gets a stable bucket from their id, so raising the percentage only ever adds people.

Kill switch

Forces the value and bypasses every rule.

Evaluate as

acme.shop/checkout

Checkout — step 2 of 3

Payment details

legacy
Card number
Expiry / CVC
Billing address

Two more steps before the order is placed.

Rendered from a locally evaluated flag — no request was made.

Evaluation · Bruno

ROLLOUT_EXCLUDED

useFlag("new-checkout") → false

Matched "Paid plans, gradual rollout" but bucket 97 is outside the 60% rollout

SDK trace

Waiting — change a control to see an evaluation.

Every value on screen — the variant, the reason, the bucket — comes straight out of the evaluation. Nothing here is scripted.

Features

Everything a release needs, and nothing it does not

Flagward is deliberately small: a control plane for flags, a fast local evaluator, and enough visibility to know what your users are actually being served.

Local evaluation

Rules are evaluated in your process, not over HTTP. A flag check never blocks on the network and keeps working when Flagward is unreachable.

Real-time propagation

Every change streams to connected SDKs over SSE. No polling interval to tune, no waiting for a cache to expire.

Kill switch with an audit trail

Force a flag on or off during an incident. The override bypasses every rule, records its reason, and lifting it restores the exact configuration you had.

Targeting and rollouts

Boolean and multivariate flags, strategy rules built from attribute conditions, and percentage rollouts on stable per-user buckets.

Environments and API keys

Each environment carries its own API key, and a key scopes an SDK to that environment and nothing else.

Organizations, projects, roles

Multi-tenant from the model up. Access comes from memberships only — a foreign row answers 404, superuser or not.

Monitoring

Connected SDKs, evaluation volume, the evaluation log and the full override trail, all on one page.

Self-hostable

Django, Redis and Postgres, one docker compose up away. MIT licensed, and your flag data stays on your infrastructure.

SDKs

Install one package. Read a flag on the next line.

Every adapter carries the same evaluator, so a rule resolves identically whichever you use — and an adapter re-exports the core, so you install one package, not two.

terminal
npm install @flagward/react

React 18+. Authenticate with the environment's API key from the dashboard — a key scopes the SDK to one environment and nothing else.

Source: basb7/flagward-sdk-js →
app.tsx
import { FlagwardProvider, useFlag } from "@flagward/react";

function App() {
  return (
    <FlagwardProvider apiKey={process.env.NEXT_PUBLIC_FLAGWARD_KEY} host="https://app.flagward.com">
      <Checkout />
    </FlagwardProvider>
  );
}

function Checkout() {
  const { value, isLoading } = useFlag("new-checkout");

  // `value` is undefined until the first snapshot arrives, and stays
  // undefined for a key this environment does not have.
  if (isLoading) return <LegacyCheckout />;

  return value ? <NewCheckout /> : <LegacyCheckout />;
}
Self-host

Run it yourself, or let us run it

Flagward is open source and self-hostable by design. The hosted dashboard is the same software with the operations taken off your plate.

  • Django 6.1 + Redis + PostgreSQL, all in the compose file
  • MIT licensed — fork it, audit it, run it where you want
  • Your flag data and your users' attributes stay on your infrastructure
  • Or skip all of it and use the hosted dashboard at app.flagward.com

Flagward ships with development defaults so it runs out of the box. They are not safe for a deployment — read SECURITY.md before exposing an instance.

terminal
git clone https://github.com/basb7/flagward.git
cd flagward
docker compose up

# Dashboard   http://localhost:3000
# API         http://localhost:8000

Your next release does not need a deploy window

Create an organization, add a project and an environment, and wrap your first component. The flag you create in the dashboard is readable from your app on the same afternoon.