Gate a view, a background task, or an API response behind a flag, and change its state from the dashboard instead of a deploy.
A feature flag is a runtime switch in your code that decides whether a piece of functionality is visible or active, without requiring a new deployment.
Instead of shipping a feature straight to every user the moment it merges, you wrap it in a flag. The code reaches production immediately, but stays off until you decide to turn it on — for one user, a percentage of traffic, or everyone at once.
Merge and ship to production every day, and keep unfinished work safely behind a flag instead of a long-lived branch.
Turn a feature on for 5% of traffic first, watch for errors, then widen the rollout instead of flipping a switch for everyone at once.
Target specific accounts or user IDs so a handful of people can try a feature before it reaches everyone else.
If a feature misbehaves in production, turn it off from the dashboard in seconds — no rollback, no redeploy.
Separate "deployed" from "released." Code can sit in production, inactive, until you decide it is ready.
Multiple engineers can merge into main continuously without waiting on each other's features to be release-ready.
The same flag key, evaluated with a different user context, can return a different result for every visitor — without a second deployment.
pip install flagpilot
Add the package to your project.
pip install flagpilot
Create one client at app startup and reuse it across requests.
client = FlagPilot(api_key="fk_secret_xxxx", environment="production") client.initialize()
Call evaluate() inside a view or background task.
is_enabled = client.evaluate("new_dashboard_v2", user_id="user_123")Use the boolean result to decide what the view returns.
if is_enabled:
render_new_dashboard()
else:
render_old_dashboard()On startup, the SDK fetches your project's flag configuration once and stores it in an in-memory cache. Every evaluate() call after that reads from the cache, not the network, so checking a flag is effectively free.
The cache refreshes in the background on a polling interval, so a change you make in the dashboard shows up in connected clients within seconds, without blocking any request.
If the API is temporarily unreachable — a network blip, or a cold start before the first fetch completes — evaluation falls back to a safe default instead of throwing, so a flag outage never becomes a feature outage.
The same client works in a Flask view, a FastAPI route handler, or a Django view — no framework-specific plugin needed.
Evaluation reads from an in-process cache that refreshes in the background, not a live request on every check.
The client is built to be shared safely across worker threads in a WSGI/ASGI server.
The client ships with inline type hints, so evaluate() signatures work cleanly with mypy and IDE autocomplete.
initialize() completes in under 100ms, so it doesn't noticeably slow down app boot in Flask, FastAPI, or Django.
The same client works in traditional WSGI apps and in ASGI frameworks like FastAPI.
is_enabled = client.evaluate("new_dashboard_v2", user_id="user_123")
if is_enabled:
render_new_dashboard()Secret API keys belong on your server only. Client-side code should use a public client key that can't modify flags.
Percentage rollouts hash the user ID you pass in. A stable ID means the same user always gets the same result.
A flag that never gets removed becomes a permanent branch in your code. Treat flags as temporary scaffolding, not config.
Once a rollout reaches 100% and stays there, delete the flag and the old code path along with it.
It's far cheaper to catch a bug at 5% of traffic than to catch it at 100%.
A key like new-checkout-flow-v2 is easier to audit six months later than test123.
Every SDK stays under 10KB and evaluates from an in-process cache, so adding flags never becomes a performance conversation.
Every action available in the dashboard — creating flags, updating rollouts, reading audit history — is also a documented REST endpoint.
Script flag creation and rollout changes from your terminal or CI pipeline, using the same operations the dashboard performs.
A native MCP server lets Cursor, Claude Code, or any MCP-compatible assistant create and toggle flags directly from a prompt.
Flags that haven't been evaluated recently, or have sat at 100%/0% for months, are surfaced automatically instead of silently rotting in your codebase.
No sales calls, no seat-based pricing negotiations — sign up, get an API key, and evaluate your first flag in the same session.
Evaluation logic must never slow down your app or disrupt a user flow — here's what that looks like in practice.
Install FlagPilot in Python in under a minute.