# Flagger.gg > Flagger.gg is a hosted feature-flag service for teams whose code is written by AI agents. Agents create, flip and roll back flags through MCP (hosted at mcp.flagger.gg, or stdio), the flagger CLI and the API; apps check flags with the Go and Node SDKs; every change has guardrails and an audit trail; people approve in the Release console. Sign up at https://app.flagger.gg/signup?utm_source=llms.txt&utm_medium=referral&utm_campaign=llms_txt. No public pricing. It is built from the flag system that runs Sandboxer and Transformer in production, from North Bay Ventures. Flagger.gg is not the Flux/CNCF Flagger (fluxcd/flagger, flagger.app), a Kubernetes progressive-delivery operator, and not a Discord bot. Live today: - Hosted service: api.flagger.gg (API /v1 and SDK /sdk/v1), app.flagger.gg (the console), mcp.flagger.gg (MCP over Streamable HTTP). - Release console: flags not live first, a live switch per row, bulk changes, approval requests, each flag's history; every view is in the URL. - SDKs: Go (flagger.gg/go) and Node (@flaggergg/node). Flags are evaluated in your app from an in-memory ruleset (disk cache, then fetch, then a stream with a 5 s polling fallback); checks never make a network call and end users are never sent to Flagger.gg. Unknown, not loaded or errored means off. Apps register their flags ({key, summary, description, owner, notReady}) at start; a deploy never overwrites a state someone set. Shadow mode compares answers with an existing system before cutover. Public package installs (npm and `go get`) are in development. - CLI: flagger login | list | get | create | set | target | kill | bulk | revert | eval | requests | request | approve | decline | tokens | import | mcp, with --json everywhere. - MCP tools (hosted and stdio): flags_list, flag_get, flag_create, flag_set, flag_target, flag_kill, flags_bulk, flag_revert, flag_eval, requests_list, request_get. Tools are listed only when the token allows them; there is no approve tool. - Agent tokens: one project, a list of environments, actions read | create | target | rollout | kill | request, 90-day expiry, stored as hashes, revocable. Agents must give a note on every write and can attach a run. - Policy per project: auto-live (agents' changes apply at once; new flags start on unless not ready) or approvals (new flags start off; in production agents can roll out up to a cap, 10% by default, and anything wider, or on, becomes a request a person approves; requests expire after 72 hours). Protected flags refuse agents except kill. - Five states: off (no one), admins, targets (listed users and workspaces, plus admins), percent (a sticky share of users, plus admins), on (everyone). Rules are kept when the state changes. - Targeting: user ids (exact) or verified emails (case-insensitive), workspace ids, percent 0-100. Percent bucket: first 4 bytes of sha256(key + ":" + userId), big-endian, mod 100, below the percent. Shared test vectors run in both SDKs and the service. - Audit log: every change by a person, agent token, admin token, SDK registration or import, with run, before, after and note. - Import: an app's existing flags with their history (flagger import). - Test helpers: withFlag, setFlagOverride, bothFlagStates (Node), and flaggertest in Go. In development (not available yet): flags tied to metrics, guarded rollouts with automatic rollback, experiments, segments and richer targeting, scheduled changes, automated stale-flag cleanup, SDKs beyond Go and Node (browser/React, Python, mobile), public npm and `go get` installs, SSO. Flagger.gg is a hosted service and is not open source. Environments are production and development (no staging, by design). Operated by North Bay Opco I, Inc. (a Delaware corporation), 777 Brickell Ave, Suite 500 PMB 1074, Miami, FL 33131. Contact: support@northbayventures.com. Privacy: privacy@northbayventures.com. The index of these pages: https://flagger.gg/llms.txt --- # Flagger.gg: feature flags for AI agents URL: https://flagger.gg/ Updated: 2026-10-30 Your agents create, flip and roll back flags through MCP, the CLI and SDKs. Every change has guardrails and an audit trail, and humans approve. Get started How it works Flagger.gg is a hosted feature-flag service for teams whose code is written by AI agents, built from the flag system that runs Sandboxer and Transformer in production. Flagger.gg is not the Flux/CNCF Flagger (flagger.app), the Kubernetes operator. agent sessionproduction Example: an AI agent creates the flag checkout_v2 with the MCP tool flag_create, ships the new checkout behind if (flag("checkout_v2", ctx)), and asks for it to go on with flag_set. The project requires approval, so a person approves in the Release console and checkout_v2 turns on. # agent: ship the new checkout behind a flag › flag_create {key:"checkout_v2", summary:"New checkout"} ✓ created in every environment · off // src/checkout.ts if (flag("checkout_v2", ctx)) { return renderCheckoutV2(cart); } › flag_set {key:"checkout_v2", state:"on"} pending_approval · waiting for a person in the Release console… checkout_v2 → on · approved by a person Built for agents ## Agents do the flag work. People decide what goes live. Coding agents now write and merge much of the code. Flagger.gg gives them the same flag controls a person has, inside limits you set, and keeps a person in charge of what customers see. ### Create, flip and roll back Agents create flags, change their state and roll them back through the hosted or stdio MCP server, the flagger CLI and the API, with the same verbs a person uses. ### Ship behind flags An agent wraps new code in a flag check with the Go or Node SDK, so unfinished work merges and deploys switched off. ### Guardrails and an audit log Each agent gets its own token, scoped to one project, chosen environments and actions, that you can revoke. Bad changes are rejected and unknown flags are off. Every change records which agent made it, the run, the before and after, and why. ### Humans approve Run in auto-live mode, where agents' changes apply at once, or turn approvals on: agents ask, and a person turns flags live from the Release console, one at a time or in bulk. Also built in ## The release tools you'd expect. In development ### Releases tied to metrics Watch errors, latency and your own metrics next to each rollout, and roll back automatically when a guarded metric regresses. ### Targeting, rollouts and experiments Turn a flag on for named users or workspaces and roll it out to a sticky percentage today. Experiments, segments and richer targeting are in development. Live today ## Everything you need to ship behind flags. Flagger.gg is a hosted service you can use now, built from the flag system that runs Sandboxer and Transformer in production. Live ### Release console Flags that aren't live yet come first, with a live switch per row, bulk changes, approval requests and each flag's full history. Live ### Go and Node SDKs Flags are evaluated in your app from an in-memory ruleset that streams updates, with no network call per check. Unknown flags are off. Live ### CLI and MCP The flagger CLI and an MCP server, hosted or on stdio, with eleven tools: list, get, create, set, target, kill, bulk, revert, eval and requests. Live ### Agent tokens One token per agent, limited to a project, environments and actions, with a 90-day expiry. Agents must leave a note on every change. Live ### Auto-live or approvals Per project: let agents' changes apply at once, or require a person for anything wider than the rollout cap you set. Live ### Audit log and import Every change, by a person, an agent or a deploy, in one searchable log. Import your existing flags with their history. In development ## What we're adding next. These aren't live yet. Sign up and tell us what matters to your team. In development ### Guarded rollouts Step a rollout up as metrics stay healthy, and roll back automatically when they don't. In development ### Experiments and segments Compare variants on the metrics you pick, and define audiences once to reuse across flags. In development ### More SDKs Libraries beyond Go and Node, with the same off-by-default rules and shared test vectors. Guides ## Learn how agents ship behind flags. Answers to the questions teams ask when agents start writing their code. All guides · Comparisons ### Feature flags for AI coding agents Why every agent change should land behind a flag, and how agents create, roll out and kill flags safely. ### An MCP server for feature flags Eleven flag tools over MCP, scoped by token, with a note on every write and no approve tool. ### Kill switches Turn a broken feature off for everyone in seconds, without a redeploy. FAQ ## Questions about Flagger.gg. ### What is Flagger.gg? Flagger.gg is a hosted feature-flag service for teams whose code is written by AI agents. Agents create, flip, roll out and kill flags through an MCP server, the flagger CLI and the API, using scoped agent tokens. Apps check flags locally with the Go and Node SDKs, and every change is in an audit log with the agent's run and note. ### Is Flagger.gg the Flux/CNCF Flagger? No. The Flux/CNCF Flagger (fluxcd/flagger, flagger.app) is a progressive-delivery operator for Kubernetes. Flagger.gg is a hosted feature-flag service for AI agents, from North Bay Ventures. The two are unrelated. ### Can I sign up today? Yes. Sign up at app.flagger.gg with an email link or Google. Each account gets its own organization and a project in auto-live mode, with production and development environments. ### Which AI agents work with Flagger.gg? Any agent that speaks MCP, such as Claude Code, Codex and Cursor, through the hosted server at mcp.flagger.gg or flagger mcp on stdio. Agents that run shell commands can use the CLI with --json. See the setup guide. ### Is Flagger.gg open source? No. Flagger.gg is a hosted service. If you need to self-host, see Unleash, Flagsmith and PostHog compared. ## Get started. Sign up, add an SDK key to your app and give your agents a token. Sign up --- # Brand URL: https://flagger.gg/brand/ Updated: 2026-10-30 Brand kit The Flagger.gg mark, colors, type and rules, with every file to download. Use it to write about Flagger.gg, link to us or put us on a slide. Download the kit (.zip)Brand sheet (.txt) ## The mark: a flag that's a switch A flagpole whose flag is a toggle switch, switched on. A feature flag is exactly that: a switch you raise on a release, and Flagger.gg is where your agents flip it. The pole is neutral, the switch is green because green means on, and the knob is a cut-out, so it always shows the background behind it. For dark backgrounds For light backgrounds One color App icon ## Lockups The wordmark is "Flagger.gg" in Inter Medium, converted to outlines and tracked -0.02em. ".gg" has the same weight and size as "Flagger" and is slightly muted, Muted #A1A1A8 on dark and Slate #5B5B63 on light, so it reads as the name with its domain. Use these files instead of typing "Flagger.gg" next to the mark. In running text, "Flagger.gg" is one color. Horizontal, dark Horizontal, light Stacked, dark Stacked, light ## Palette Night, Mist and On carry the brand. When a form asks for one brand color, use On, #3DDC97. On light backgrounds the switch turns Deep and green text turns Ink green, because the bright green is too light there. Night#0B0B0CBackground, ink on light Panel#141416Cards, header, drawers Raised#1C1C1FMenus, dialogs, inputs Border#2A2A2EHairlines, card edges Mist#E8EEF4Text and the pole on dark On#3DDC97The switch, links, buttons Off#2E2E33Off states, decoration only Warn#F5C451In development, warnings Muted#A1A1A8Secondary text; ".gg" on dark Paper#F6F8FALight background Deep#17A067The switch on light Slate#5B5B63".gg" in the wordmark on light Ink green#0E7C4EGreen text on light ### Contrast (WCAG 2.2) AA needs 4.5:1 for body text, and 3:1 for large text and for graphics such as the mark. |Pair |Ratio |Use | |Mist on Night |16.83:1 |AAA text | |On on Night (and Night on On) |11.13:1 |AAA text, buttons | |Warn on Night |12.08:1 |AAA text | |Muted on Night |7.66:1 |AAA text; the wordmark's ".gg" on dark | |Mist / On / Muted on Panel |15.74:1 / 10.41:1 / 7.17:1 |AAA text on cards | |Off on Night |1.46:1 |Decoration only, never text | |Slate on white / Paper |6.73:1 / 6.32:1 |AA text; the wordmark's ".gg" on light | |Night on Paper |18.48:1 |AAA text | |Deep on white / Paper |3.35:1 / 3.15:1 |Graphics (the mark), not body text | |Ink green on white / Paper |5.23:1 / 4.92:1 |AA text and links on light | |On on Paper |1.66:1 |Fails: never use the bright green on light | ## Type Inter, free under the SIL Open Font License. Medium (500) for headings, buttons and the wordmark, with tight tracking: -0.02em for the wordmark and about -0.035em for big headlines. Regular (400) for body text. Code and flag keys use the system monospace. Feature flags for AI agents. Inter Regular for body text: every flag starts off, and a deploy never overwrites a state someone set. agent.auto_merge on ### Writing the name - Write Flagger.gg: a capital F, the rest lowercase, with ".gg" always attached. Not "Flagger", "FlaggerGG" or "Flagger.GG". - Lowercase stays in the domain and URLs (flagger.gg, app.flagger.gg) and in code: the flagger CLI, @flaggergg/node, flagger.gg/go, X-Flagger-* headers and FLAGGER_* variables. - Flagger.gg is a feature-flag service. It isn't the Flux/CNCF Flagger, the Kubernetes operator. ## Clear space Keep empty space around the mark at least as tall as the switch, about half the mark's height. Around a lockup, keep at least the height of the capital F. The dashed line is the minimum clear space: one switch height on every side. ## Minimum size - Mark: 16 px tall on screen, 6 mm in print. - Below 24 px, use the pixel-tuned icons (icon-16.svg, icon-32.svg and the favicons). They have a heavier pole, a flag flush on the pole and, at 16 px, a square knob. - Horizontal lockup: 24 px tall. Stacked lockup: 64 px tall. 16 and 32 px, and 16 px enlarged ## Do's and don'ts ### Do - Use the dark files on Night or other dark backgrounds, and the light files on white or Paper. - Use the one-color mark for single-color printing, embossing or busy photos. - Keep the switch on, with the knob on the right, and green. - Scale from the SVGs, keeping proportions. ### Don't - Recolor the switch, or use the bright green on light backgrounds. - Flip the switch off, move the knob or fill it with a color other than the background. - Stretch, skew, rotate, outline, or add shadows or gradients. - Retype "Flagger.gg" next to the mark in another font; use a lockup. ## Downloads flagger-brand-kit.zip has everything below plus the brand sheet, README.txt. The contact sheet (1800 × 3550 PNG, 370 KB) shows the whole kit on one page. |File |Kind |Format | |mark-for-dark-bg.svg |Mark |SVG, 295 B | |mark-for-light-bg.svg |Mark |SVG, 295 B | |mark-one-color-night.svg |Mark |SVG, 295 B | |mark-one-color-white.svg |Mark |SVG, 295 B | |mark-transparent-for-dark-bg-1024.png |Mark |1024 × 1024 PNG, 25 KB | |mark-transparent-for-light-bg-1024.png |Mark |1024 × 1024 PNG, 25 KB | |flagger-horizontal-for-dark-bg.png |Lockup |1748 × 340 PNG, 46 KB | |flagger-horizontal-for-dark-bg.svg |Lockup |SVG, 7 KB | |flagger-horizontal-for-light-bg.png |Lockup |1748 × 340 PNG, 44 KB | |flagger-horizontal-for-light-bg.svg |Lockup |SVG, 7 KB | |flagger-stacked-for-dark-bg.png |Lockup |1312 × 960 PNG, 53 KB | |flagger-stacked-for-dark-bg.svg |Lockup |SVG, 7 KB | |flagger-stacked-for-light-bg.png |Lockup |1312 × 960 PNG, 51 KB | |flagger-stacked-for-light-bg.svg |Lockup |SVG, 7 KB | |app-icon-rounded-1024.png |App icon |1024 × 1024 PNG, 29 KB | |app-icon-rounded.svg |App icon |SVG, 377 B | |app-icon.svg |App icon |SVG, 369 B | |icon-16.svg |App icon |SVG, 283 B | |icon-32.svg |App icon |SVG, 333 B | |avatar-dark-1024.png |Avatar |1024 × 1024 PNG, 16 KB | |avatar-dark-256.png |Avatar |256 × 256 PNG, 3 KB | |avatar-dark-512.png |Avatar |512 × 512 PNG, 7 KB | |avatar-light-1024.png |Avatar |1024 × 1024 PNG, 15 KB | |avatar-light-256.png |Avatar |256 × 256 PNG, 3 KB | |avatar-light-512.png |Avatar |512 × 512 PNG, 7 KB | |og-1200x630.png |Social |1200 × 630 PNG, 46 KB | |x-header-1500x500.png |Social |1500 × 500 PNG, 33 KB | |apple-touch-icon.png |Favicon |180 × 180 PNG, 3 KB | |favicon-16x16.png |Favicon |16 × 16 PNG, 297 B | |favicon-32x32.png |Favicon |32 × 32 PNG, 716 B | |favicon.ico |Favicon |16 + 32 ICO, 1 KB | |favicon.svg |Favicon |SVG, 333 B | |icon-192.png |Favicon |192 × 192 PNG, 5 KB | |icon-512.png |Favicon |512 × 512 PNG, 13 KB | --- # Compare URL: https://flagger.gg/compare/ Updated: 2026-11-03 compare Flagger.gg is a hosted feature-flag service built for teams whose code is written by AI agents. These pages compare it with other flag tools, say where each one is stronger, and link to each vendor's own docs so you can check every claim. ### LaunchDarkly vs Flagger.gg LaunchDarkly vs Flagger.gg, fairly: LaunchDarkly for experiments, broad SDKs and rich targeting; Flagger.gg when AI agents ship your code in Go or Node. ### Datadog feature flags vs Flagger.gg Datadog Feature Flags (from its 2025 purchase of Eppo) tie flags to Datadog's metrics. Flagger.gg is a standalone flag service with agent access over MCP. ### Unleash, Flagsmith and PostHog alternatives Unleash, Flagsmith and GrowthBook are open source and self-hostable; PostHog bundles flags with analytics. How they compare with Flagger.gg. ### GrowthBook, Statsig and ConfigCat alternatives GrowthBook, Statsig and ConfigCat compared with Flagger.gg from each vendor's docs: hosting, local evaluation, experiments, SDKs, MCP servers and CLIs. ### Cloudflare Flagship vs Flagger.gg Cloudflare Flagship evaluates flags inside Workers at the edge. Flagger.gg evaluates in memory in Go and Node apps and gives AI agents scoped MCP access. ## Guides New to flags, or to flags for agents? Start with the guides. --- # Features URL: https://flagger.gg/features/ Updated: 2026-10-30 Flagger.gg is the feature-flag system built for AI agents: agents create, flip and roll back flags, every change has guardrails and an audit log, and people approve what goes live. Everything marked live works today in the hosted service; the rest is in development. Live today ### Agents create, flip and roll back flags Agents use the same verbs as people: list, get, create, set, target, kill, bulk, revert and eval, through MCP, the flagger CLI or the API, for example flagger create checkout_v2 --summary "New checkout". Live today ### Hosted and stdio MCP server Connect any agent to mcp.flagger.gg with its token, or run flagger mcp on stdio. Agents only see the tools their token allows, and there is no approve tool. Live today ### Agent tokens Each agent gets its own token for one project, a list of environments and the actions you pick (read, create, target, rollout, kill, request), with a 90-day expiry. Tokens are stored as hashes and can be revoked any time. Live today ### Release console A person turns flags live from the console. Flags that aren't live yet come first, each with a line on what changes for customers, a live switch, bulk changes and the flag's history. Live today ### Auto-live or approvals Per project. In auto-live mode agents' changes apply at once. With approvals on, agents can roll out to a cap you set per environment, and anything wider waits for a person to approve the request. Live today ### Guardrails on every change A bad state, a percentage outside 0 to 100 or a target list with nobody on it is rejected. Protected flags refuse agents except for the kill switch, and unknown flags are off, so mistakes fail safe. Live today ### Five flag states off for no one, admins for your admins, targets for named users and workspaces, percent for a sticky share of users, and on for everyone. Live today ### Sticky percentage rollouts A user's bucket comes from a SHA-256 hash of the flag key and user id, so the same user stays in or out as you raise the percentage from 0 to 100. Live today ### User and workspace targeting Target user ids or verified emails (matched without case) and workspace ids. Rules are kept when the state changes. Live today ### Kill switch and revert One call sets a flag off for everyone and keeps its rules. Revert rolls a flag back to its previous state, or to any point in its history. Live today ### Audit log Every change, by a person, an agent, an admin token or a deploy, is stored with who made it, the agent's run, when, the state and rules before and after, and a note. Agents must give one. Live today ### Go and Node SDKs Flags are evaluated in your app against an in-memory ruleset that streams updates and is cached on disk, so a check never makes a network call. Unknown, not yet loaded or errored means off. Live today ### Flags declared in code Your app registers its flags with a key, description, owner and summary when it starts. The console shows which flags are in code, and a deploy never overwrites a state someone set. Live today ### Evaluation stays in your app The SDKs download your rules and decide locally. The users you check flags for are never sent to Flagger.gg. Live today ### Test helpers withFlag forces a flag for one test, setFlagOverride for longer, and bothFlagStates runs a test with the flag off and then on, in both SDKs. Live today ### Import and shadow mode Import an app's existing flags with their history, then run the SDK in shadow mode, which compares its answers with your current system before you switch. Live today ### Shareable views Every console view, filter and open flag has its own address, so a reload or a shared link shows the same thing. In development ### Flags tied to metrics Watch error rates, latency and your own business metrics next to each flag's state and rollout. In development ### Guarded rollouts with auto-rollback Step a percentage rollout up on a schedule and switch the flag off automatically if a guarded metric regresses. In development ### Segments and richer targeting Define an audience once, such as beta workspaces or internal staff, reuse it across flags, and target on more attributes. In development ### Experiments Split users between variants and compare them on the metrics you pick. In development ### More SDKs Libraries for more languages beyond Go and Node, with the same off-by-default rules and shared test vectors. ## Want a say in what comes next? Sign up, ship your first flag, and tell us how your team and its agents work. Sign up --- # Guides URL: https://flagger.gg/guides/ Updated: 2026-11-03 guides Plain answers to the questions teams ask about feature flags, and about feature flags when AI agents write and ship the code. Each guide starts with the answer, then the detail, with real commands from Flagger.gg's CLI, MCP tools and SDKs. ## Guides ### What is a feature flag? A feature flag is a switch in your code that turns a feature on or off, for everyone or chosen users, without a deploy. How flags work, with examples. ### Feature flags for AI coding agents Why every change an AI coding agent ships should land behind a flag, and how agents create, roll out and kill flags with scoped tokens and an audit log. ### Let Claude Code, Codex and Cursor ship behind flags Set up Claude Code, Codex or Cursor to ship behind feature flags: a scoped agent token, Flagger.gg's MCP server, and instructions to create and kill flags. ### An MCP server for feature flags, used safely Flagger.gg's MCP server gives agents 11 feature-flag tools, hosted or on stdio. Tools follow token scope, writes need a note, there's no approve tool. ### Kill switches: roll back a bad release in seconds A kill switch is a feature flag you turn off at once, no deploy. Kill a bad release in seconds with Flagger.gg's CLI, MCP tool or console, then revert. ### Percentage rollouts and sticky bucketing How to roll a feature out to a percentage of users so each user keeps the same answer as you widen it: sticky hash bucketing, with Go and Node examples. ### Trunk-based development with AI agents With AI agents shipping many changes in parallel, feature flags replace long-lived branches: each agent merges small changes to main and ships them dark. ### Feature flags vs a staging environment Staging tests a copy of production; flags test the real thing with a few real users first. When teams skip staging and ship to production behind a flag. ### Testing both sides of a flag Test code behind a feature flag with the flag on and off. Flagger.gg's Go and Node SDKs include bothFlagStates, withFlag and setFlagOverride helpers. ### Flag cleanup and flag debt Flag debt is old flags left in code after a feature is fully on. How to find stale feature flags, remove them safely, and archive them in Flagger.gg. ### A feature flag CLI for AI agents The flagger CLI lets AI agents create, roll out and kill feature flags from a shell: --json on every command, stable exit codes, a note on each write. ### An audit trail for agent flag changes See which AI agent changed a feature flag, in which run and why. Flagger.gg records the actor, run, note, before and after, client and IP on every change. ### Local evaluation: why flag checks shouldn't call the network Why flag checks shouldn't call the network: Flagger.gg's Go and Node SDKs evaluate in memory from a streamed ruleset, with a disk cache for outages. ### Moving off an in-house flag table: import, shadow, cut over Move from a homegrown feature flag table to a flag service in four steps: import flags with history, shadow both systems, cut over, then clean up. ### Self-serve feature flags for startups What a startup needs from a self-serve feature flag service: sign-up without a sales call, local evaluation, a kill switch, an audit log, agent access. ### Give an AI agent scoped access to production flags Give an AI agent least-privilege access to production feature flags: a token per agent, scoped to one project, chosen environments and actions. ### Human approval for AI agent flag changes Require a person to approve wide production flag changes made by AI agents, while small rollouts, targeting and kills still apply at once. ## Comparisons How Flagger.gg compares with other flag tools, fairly, with links to each vendor's own docs. All comparisons ### LaunchDarkly vs Flagger.gg LaunchDarkly vs Flagger.gg, fairly: LaunchDarkly for experiments, broad SDKs and rich targeting; Flagger.gg when AI agents ship your code in Go or Node. ### Datadog feature flags vs Flagger.gg Datadog Feature Flags (from its 2025 purchase of Eppo) tie flags to Datadog's metrics. Flagger.gg is a standalone flag service with agent access over MCP. ### Unleash, Flagsmith and PostHog alternatives Unleash, Flagsmith and GrowthBook are open source and self-hostable; PostHog bundles flags with analytics. How they compare with Flagger.gg. ### GrowthBook, Statsig and ConfigCat alternatives GrowthBook, Statsig and ConfigCat compared with Flagger.gg from each vendor's docs: hosting, local evaluation, experiments, SDKs, MCP servers and CLIs. ### Cloudflare Flagship vs Flagger.gg Cloudflare Flagship evaluates flags inside Workers at the edge. Flagger.gg evaluates in memory in Go and Node apps and gives AI agents scoped MCP access. --- # How Flagger.gg works URL: https://flagger.gg/how-it-works/ Updated: 2026-10-30 docs / how it works Agents put new work behind flags and change them through MCP, the CLI and the API, inside guardrails. People approve what goes live. Checks run in your app with no network call, and anything Flagger.gg doesn't recognize is off. Everything on this page works today in the hosted service. Flags tied to metrics, guarded rollouts, experiments, segments and SDKs beyond Go and Node are in development. Sign up to start. ## The agent loop - The agent creates a flag for the work it's starting, with the MCP tool flag_create, the CLI or the API. The flag is created in every environment. - It ships behind the flag. The new code path sits behind a flag check, so it can merge and deploy straight to production switched off. - It reads and flips flag state to try the change on its own team, and rolls it back with the kill switch or flag_revert if something looks wrong. Every change goes through the same checks and lands in the audit log with a note. - A person approves. With approvals on, turning a flag on for everyone becomes a request that someone on your team approves in the Release console. In auto-live mode the agent's change applies at once. ## Declare flags in code Your app declares the flags it uses with a key, a summary, a description and an owner, and the SDK registers them when it starts. Keys are lowercase letters, digits and underscores, starting with a letter, up to 63 characters. ``` const flagger = createFlagger({ sdkKey: process.env.FLAGGER_SDK_KEY, defs: { new_billing_page: { summary: "Redesigned billing page", description: "…", owner: "payments" }, }, }); await flagger.start(); ``` A registered flag that doesn't exist yet is created; a flag someone already switched is never overwritten by a deploy. The console marks which flags are in code, so the code and the flag list can't quietly drift apart. A flag can also carry a "not ready" reason, which keeps it from being turned on by mistake. ## States Each flag is in exactly one of five states per environment: |State |Who sees the feature | |off |No one | |admins |Your admins only | |targets |The users and workspaces in the rules, plus admins | |percent |A sticky share of users, plus admins | |on |Everyone | A typical rollout moves off → admins → targets → percent → on, and then the flag is removed from the code. ## Targeting rules Rules are stored with every flag, whatever its state, so switching state never loses a target list. - Users: user ids, matched exactly, or emails, matched without regard to case. Only verified emails count. - Workspaces: workspace ids, matched against every workspace the user belongs to. - Percent: 0 to 100. ### How percentage buckets work For a flag in percent, take the first 4 bytes of sha256(key + ":" + userId), read them as a big-endian number, and take that modulo 100. The user is in if the result is below the percentage. The same user always lands in the same bucket for a flag, so raising the percentage only ever adds people. Both SDKs and the service run the same shared test vectors. ## Checking a flag ``` if (flagger.flag("new_billing_page", { userId, email, isAdmin, workspaceIds })) { // new code path } ``` In Go it's client.Enabled("new_billing_page", subject). The check is synchronous and reads an in-memory ruleset. The SDK loads the last good ruleset from disk, fetches the current one, and then follows a stream of changes, falling back to polling every 5 seconds. A check never makes a network call, and the people you check flags for are never sent to Flagger.gg. A flag that is unknown, not yet loaded or hit an error is off. A caller with no user id only sees flags that are on. ## Changing a flag People use the Release console at app.flagger.gg. Agents and scripts use the API at api.flagger.gg/v1, the CLI or MCP, which all map to the same calls: |Request |Does | |GET …/flags |Lists flags, not live first | |POST …/flags |Creates a flag in every environment | |PATCH …/flags/{key} |Sets state and rules, with a note | |POST …/flags/{key}/target |Replaces, adds or removes targets | |POST …/flags/{key}/kill |Sets the flag off and keeps its rules | |POST …/flags/{key}/revert |Rolls back to the previous state, or to any event in its history | |POST …/flags/bulk |Turns several flags on in one transaction | |POST …/flags/{key}/eval |Says whether a flag is on for a given user, and why | A bad state, a percentage outside 0 to 100, or targets with nobody listed is rejected. Each change writes the new state, a history entry and an audit-log entry together. ## Auto-live and approvals Each project picks one of two modes: - Auto-live: agents' changes apply at once, and new flags start on unless they carry a "not ready" reason. - Approvals: new flags start off. In production an agent can target people and roll out up to a cap you set (10% by default). Turning a flag on for everyone, or rolling out past the cap, becomes a request that a person approves or declines in the Release console. Requests expire after 72 hours. Protected flags refuse every agent change except the kill switch, in both modes. ## Agents, tokens and MCP Each agent gets its own token from the console, scoped to one project, a list of environments and the actions you choose: read, create, target, rollout, kill and request. Tokens expire after 90 days and can be revoked any time. Agents must give a note with every change, and can attach the run they're part of. The MCP server is hosted at mcp.flagger.gg and also runs on stdio with flagger mcp. Its tools are flags_list, flag_get, flag_create, flag_set, flag_target, flag_kill, flags_bulk, flag_revert, flag_eval, requests_list and request_get. An agent only sees the tools its token allows, and there is no approve tool: approving is a person's job. ## CLI ``` flagger login flagger list [--not-live] flagger get flagger create --summary "..." flagger set [--percent N] [--users a,b] [--workspaces x,y] flagger target [--users a,b] [--workspaces x,y] [--add|--remove] flagger kill flagger revert [--to ] flagger eval --user u flagger requests flagger approve ... flagger import --project p --env e --from flags.json ``` Every command takes --json. flagger login signs a person in with a device code; agents use FLAGGER_TOKEN. ## Audit log The audit log records every change across your organization: who or what made it (a person, an agent token, an admin token, an SDK registration or an import), the agent's run, when, the state and rules before and after, and the note. Filter it by project, environment, flag, agent, person or run; every filter is in the URL. ## Tests - withFlag(key, on, fn) runs fn with the flag forced on or off. - setFlagOverride(key, on) forces a flag for longer, such as a whole test file. - bothFlagStates(key, fn) runs fn with the flag off, then on, so both code paths stay tested until the flag is removed. Go has the same helpers in flaggertest. ## Good habits - Off by default. A missing or unknown flag is off, so a deploy never turns on unfinished work by accident. - Check on the server. The server decides and enforces; the UI only hides what the server already refuses. - No secrets in flags. Flags hold state and targeting, never keys or tokens. - Remove when done. Once a feature is on for everyone and stable, delete the flag and the old code path. More in the guides: the MCP server, setting up Claude Code, Codex and Cursor, kill switches, percentage rollouts and testing both sides of a flag. --- # What is a feature flag? URL: https://flagger.gg/guides/what-is-a-feature-flag/ Updated: 2026-10-31 A feature flag is a switch in your code that turns a feature on or off, for everyone or for chosen users, without a deploy. You ship the code dark, then turn it on for admins, a list of users, a percentage or everyone, and turn it off in seconds if something breaks. ## How a feature flag works A flag is a named condition around a code path. The code for both paths ships in the same deploy, and the flag decides at run time which one a given user gets: ``` if (flagger.flag("new_checkout", { userId, email, isAdmin })) { return renderNewCheckout(cart); } return renderCheckout(cart); ``` The flag's state lives outside the code, in a flag service. Changing it changes what users see within seconds, with no build, no deploy and no rollback of the code. That separates two things that used to be one step: deploying code and releasing a feature. "Feature flag", "feature toggle", "feature switch" and "feature gate" all mean the same thing. ## Who sees the feature A flag is more than on or off. In Flagger.gg each flag has one of five states in each environment: |State |Who sees the feature | |off |No one | |admins |Your admins only | |targets |Listed users (by id or verified email) and workspaces, plus admins | |percent |A sticky share of signed-in users, plus admins | |on |Everyone, including anonymous visitors | A typical release walks the flag up that table: admins first, then a few named customers, then 10% and 50%, then everyone. See percentage rollouts for how the percentage stays sticky. ## Where the check runs A good flag check is fast and can't take your app down. Flagger.gg's Go and Node SDKs keep the whole ruleset in memory and evaluate each check locally and synchronously, with no network call. Rule changes stream to the SDK within a second, and the last good ruleset is cached on disk, so a restart during an outage serves the last rules. The users you check flags for are never sent to Flagger.gg. More on local evaluation. Failures are safe by design: a flag that is unknown, not loaded yet or hit an error is off. ## What teams use flags for - Dark launches: merge unfinished work to main and deploy it switched off. - Gradual rollouts: expose a change to a few users, watch it, widen it. - Kill switches: turn off a broken feature at once, without a redeploy. See kill switches. - Beta access: turn a feature on for named customers or workspaces. - Agent-written code: when AI agents ship many changes a day, each one lands behind its own flag. See feature flags for AI agents. ## FAQ ### What's the difference between a feature flag and a feature toggle? None. They're two names for the same thing: a switch in code whose state is set outside the code. ### Do feature flags slow down my app? Not if they're evaluated locally. Flagger.gg's SDKs check flags against an in-memory ruleset, so a check is a lookup and a few comparisons, with no network call. ### What happens if the flag service is down? With Flagger.gg, your app keeps serving the rules it already has in memory, and a restart loads the last good ruleset from disk. A flag the SDK doesn't know is off. ### When should I remove a feature flag? Once the feature is on for everyone and stable, delete the flag and the old code path. Old flags left in code are flag debt; see flag cleanup. ### Can I sign up for Flagger.gg today? Yes. Sign-up is open at app.flagger.gg with an email link or Google, and each account gets its own project with production and development environments. --- # Feature flags for AI coding agents URL: https://flagger.gg/guides/feature-flags-for-ai-agents/ Updated: 2026-11-02 When agents write and ship most of the code, every change they make should land behind a flag, so a human or the agent can turn it off without a redeploy. Flagger.gg lets agents create, flip, roll out and kill flags through MCP, the CLI and the SDKs, using scoped agent tokens. Every change records which agent made it, in which run and why. ## Why agents need flags Coding agents such as Claude Code, Codex and Cursor now open, merge and deploy a large share of changes. Review can't catch everything at that pace, so the safety net has to move from "before merge" to "after deploy": ship the change switched off, turn it on for a few people, and turn it off at once if it misbehaves. That only works if the agent itself can do the flag work: create the flag for the change it's making, wrap the new code in a check, move the flag through admins and targets, and kill it when a check fails. Flags designed for people clicking in a dashboard don't give agents that, or give them full admin power with no record of which agent did what. To see one agent build in a Sandboxer sandbox, ship behind a Flagger.gg flag and launch on Transformer, read how Sandboxer, Flagger.gg and Transformer work together. ## The agent loop - Create a flag for the change. The agent calls flag_create over MCP, or flagger create, with a summary of what changes for customers and a note on why. In auto-live mode a new flag starts on unless it carries a not-ready reason, so an agent shipping dark passes one; with approvals on, new flags start off. - Ship behind it. The new code path sits behind flag("key", ctx) in Node or client.Enabled("key", sub) in Go, and merges to main. - Widen it step by step. Admins, then named users or workspaces, then a percentage, then everyone, checking its work at each step with flag_eval. - Kill or revert if checks fail. flag_kill turns it off for everyone; flag_revert rolls back to the previous state. The run is taken from FLAGGER_RUN (or --run), so every step lands in the audit log under the same run: ``` flagger create search_v2 --summary "New search ranking" --not-ready "ranking not tuned yet" --note "ticket 412" --json flagger set search_v2 admins --note "try on the team first" --json flagger set search_v2 percent --percent 10 --note "admins look good" --json flagger kill search_v2 --note "error rate up after 10%" --json ``` ## Guardrails for agents - Scoped agent tokens. Each agent gets its own flg_agent_… token for one project, a list of environments and the actions you pick: read, create, target, rollout, kill, request. Tokens expire after 90 days, are stored as hashes and can be revoked any time. - A note on every write. Agent writes without a note are refused. The run (from --run, FLAGGER_RUN or the MCP client) is recorded too. - Auto-live or approvals, per project. In auto-live mode (the default) agents' changes apply at once. With approvals on, agents in production can roll out up to a cap (10% by default); turning a flag on for everyone becomes a request a person approves in the Release console. There is no approve tool for agents. See human approval for agent changes. - Protected flags. Mark payments or sign-in flags protected and agents can only kill them. - Rate limits. 30 writes a minute per agent token; with approvals on, also 5 changes to one flag an hour. Kill is exempt. - Unknown means off. A typo in a flag key can't turn anything on. ## Which agent did what, and why Every change, by a person, an agent token, an admin token, a deploy's code registration or an import, writes an audit row with who, which run, the state and rules before and after, the client (console, CLI, MCP, API) and the note. The org audit log filters by agent, flag, run and person, and every filter is in the URL, so "everything the backend agent changed in run 1832" is one link. More in the audit trail for agent flag changes. ## How agents connect - MCP: hosted at mcp.flagger.gg (Streamable HTTP, the agent token as a bearer) or flagger mcp on stdio, with the same 11 tools. See the MCP server guide. - CLI: every command takes --json and prints one JSON object; errors are {"error":{"code","message"}}. Exit codes: 0 done, 2 waiting for approval, 1 error. See the CLI guide. - API: api.flagger.gg/v1 with the token as a bearer. Step-by-step setup for Claude Code, Codex and Cursor is in this guide. ## FAQ ### How do AI coding agents use feature flags? They create a flag for each change, ship the new code behind it switched off, widen it step by step while checking their work, and kill or revert it if something fails. With Flagger.gg they do this through MCP tools or the CLI with a scoped token. ### Can an agent turn a feature on for everyone by itself? In auto-live mode, yes, within its token's actions. With approvals on, an agent in production can go up to the rollout cap (10% by default), and anything wider becomes a request a person approves. ### Can an agent approve its own change? No. There is no approve tool and agent tokens can't approve. Approving is done by a person in the Release console or with a person's own flagger login. ### How do I know which agent changed a flag? Each agent has its own named token, and every change records the token, the run, the before and after, and the agent's note. Filter the audit log by agent, run or flag. ### Which agents work with Flagger.gg? Any MCP client, such as Claude Code, Codex and Cursor, and any agent that can run a shell command and read JSON. --- # Let Claude Code, Codex and Cursor ship behind flags URL: https://flagger.gg/guides/claude-code-codex-cursor-feature-flags/ Updated: 2026-11-02 Make an agent token scoped to one project, its environments and the actions the agent may take. Add Flagger.gg's MCP server to the agent: hosted at mcp.flagger.gg with the token as a bearer, or flagger mcp on stdio. Then tell the agent to put new code behind a flag, create it with a note, and kill it if checks fail. ## Steps - Sign up and open your project. Each account gets a project with production and development environments, in auto-live mode. Turn approvals on in the project's settings if you want a person to sign off on anything wider than the rollout cap. - Make an agent token. In the console's Tokens page, create an agent token named after the agent ("Claude Code, backend repo"), pick the environments and the actions it may use (read create target rollout kill request), and copy the flg_agent_… secret. It's shown once and expires after 90 days. - Add the MCP server to your agent. Use the snippet for your client below. The agent then sees only the tools its token allows. - Tell the agent how to ship. Add the instructions below to your CLAUDE.md, AGENTS.md or Cursor rules. - Check the audit log. Every change the agent makes shows its token name, run and note in the console's audit log. ## Claude Code ``` claude mcp add --transport http flagger https://mcp.flagger.gg \ --header "Authorization: Bearer flg_agent_…" ``` This uses Claude Code's HTTP transport for remote MCP servers. ## Codex ``` # ~/.codex/config.toml [mcp_servers.flagger] url = "https://mcp.flagger.gg" http_headers = { Authorization = "Bearer flg_agent_…" } ``` ## Cursor ``` // .cursor/mcp.json { "mcpServers": { "flagger": { "url": "https://mcp.flagger.gg", "headers": { "Authorization": "Bearer ${env:FLAGGER_TOKEN}" } } } } ``` Cursor reads remote MCP servers from .cursor/mcp.json in the project or ~/.cursor/mcp.json, and fills in ${env:FLAGGER_TOKEN} from your environment, so the token stays out of version control (Cursor's MCP docs). ## Local stdio instead Clients that prefer a local server can run flagger mcp, which serves the same tools on stdio and calls api.flagger.gg with FLAGGER_TOKEN (or the token from flagger login). The run recorded for each write is the tool's run input, else FLAGGER_RUN, else the MCP client's name. ## Instructions for the agent ``` ## Feature flags (Flagger.gg) - Put every user-facing change behind a new flag. Create it with flag_create: a snake_case key, a one-line summary of what changes for customers, and a note. Pass notReady with a reason so it starts off until the work is done. - Check the flag in code: flagger.flag("key", ctx) (Node) or client.Enabled("key", sub) (Go). - Roll out with flag_set: admins, then targets, then percent. Explain with flag_eval. - If tests, errors or checks fail after a change, call flag_kill with a note at once. - If a change returns pending_approval, stop and report the request URL; never retry it. ``` With the CLI instead of MCP, a change that needs approval exits with code 2, and flagger request --wait waits for the decision. ## FAQ ### Does Claude Code support feature flags? Claude Code has no flag system of its own, but it can use one through MCP. Add Flagger.gg's hosted MCP server with claude mcp add --transport http and an agent token, and it can create, roll out and kill flags. ### Can Cursor use an MCP server for feature flags? Yes. Add https://mcp.flagger.gg to .cursor/mcp.json with the agent token in an Authorization header. ### Should each agent get its own token? Yes. A token per agent, or per repo, keeps the audit log readable and lets you revoke one agent without stopping the others. See scoped agent tokens for which actions to give each one. ### What can't the agent do? It can't approve requests, archive or protect flags, change policy or make tokens, and it can only kill protected flags. Its token also limits it to one project, its environments and its actions. --- # An MCP server for feature flags, used safely URL: https://flagger.gg/guides/feature-flags-mcp-server/ Updated: 2026-11-02 Flagger.gg's MCP server gives agents 11 flag tools, hosted (Streamable HTTP at mcp.flagger.gg) or local (flagger mcp). Tools appear only when the agent token's actions allow them, every write needs a note, kill is always allowed, and there is no approve tool, so agents can't approve their own changes. ## Connect an agent - Create an agent token in the console, scoped to one project, its environments and its actions. - Point the agent at the server: https://mcp.flagger.gg with Authorization: Bearer flg_agent_…, or run flagger mcp on stdio with FLAGGER_TOKEN set. - List the tools from your client. The agent sees only the tools its token's actions allow. - Make a first change with a note, such as flag_create for the work it's about to ship, and find it in the audit log. Client-by-client snippets for Claude Code, Codex and Cursor are in this setup guide. New to MCP itself? North Bay Ventures' plain guide to MCP explains clients, servers and tools. ## The 11 tools project and env are optional on every tool and default to the token's project and production. Each write takes note (required for agents) and an optional run. |Tool |Input |Needs action | |flags_list |{notLive?, state?} |read | |flag_get |{key}: the flag, its history and pending requests |read | |flag_eval |{key, context: {userId?, email?, isAdmin?, workspaceIds?}} → {on, reason} |read | |requests_list |{status?} |read | |request_get |{id} |read | |flag_create |{key, description, summary, owner, notReady?, note} |create | |flag_set |{key, state?, users?, workspaces?, percent?, confirmNotReady?, note} |target or rollout | |flag_target |{key, users?, workspaces?, mode: replace | add | remove, note} |target | |flags_bulk |{keys, state: on | admins, note} |target or rollout | |flag_revert |{key, toEvent?, note} |target or rollout | |flag_kill |{key, note} |kill | Each tool's output is the API's JSON answer, as structuredContent and as text. A change that needs a person comes back as a normal result with status: "pending_approval" and the request; API errors come back as isError results with {error:{code,message}}. ## What keeps it safe - Scope decides the tool list. A token with only read and kill sees six tools and can't create or roll out anything. - No approve tool. Approving is human-only, in the Release console or with a person's own flagger login. - Notes and runs. Writes without a note are refused for agents. The run is the tool's run input, else FLAGGER_RUN or the X-Flagger-Run header, else the MCP client's name. - Approvals mode. With approvals on, an agent in production can roll out up to the cap (10% by default); on, bulk on and wider percentages become requests. - Protected flags refuse agents except flag_kill. - Rate limits: 30 writes a minute per agent token, and with approvals on, 5 changes to one flag an hour. Kill is exempt. ## Hosted or stdio Both serve the same tools. The hosted server is stateless Streamable HTTP: POST gets a JSON answer, and the Mcp-Session-Id returned at initialize only carries the client's name for the run. Stdio (flagger mcp) calls api.flagger.gg with FLAGGER_TOKEN or the token stored by flagger login. The same operations are on the flagger CLI, with --json output. ## FAQ ### Is there an MCP server for feature flags? Yes. Flagger.gg's MCP server is hosted at mcp.flagger.gg and also runs locally as flagger mcp, with 11 tools to list, read, create, set, target, bulk-change, revert, kill and explain flags and to read approval requests. Several other flag vendors publish MCP servers too. ### Can an agent approve its own flag change over MCP? No. There is no approve tool, and agent tokens can't approve through the API either. ### Why can't my agent see flag_create? Its token doesn't have the create action. Tools are listed only when the token's actions allow them. ### Does the MCP server need a session? No. Hosted MCP is stateless; requests without a session id work. --- # Kill switches: roll back a bad release in seconds URL: https://flagger.gg/guides/kill-switch/ Updated: 2026-11-03 A kill switch is a flag you can turn off at once, without a deploy. In Flagger.gg, flagger kill , the flag_kill tool or the console turns a flag off for everyone, on protected flags too. The change reaches your SDKs within a second, and kill is never rate-limited. ## Kill a feature, step by step - Ship the change behind a flag. A kill switch only exists if the code path is wrapped in a flag check. Unknown or errored flags are off, so the fallback path is the safe one. - Kill it. Run flagger kill --note "why", call flag_kill over MCP, or switch it off in the Release console. The flag goes off for everyone and keeps its rules. - Confirm it's off. flagger eval --user explains the answer for one user; it should say off. - Fix, then bring it back. When the fix is deployed, flagger revert restores the state before the kill, rules included, or walk it up again from admins. ``` flagger kill checkout_v2 --note "500s on /checkout since 3:02 PM" --json flagger eval checkout_v2 --user usr_123 --json flagger revert checkout_v2 --note "fix deployed in #881" --json ``` ## How fast it takes effect Flagger.gg's SDKs hold the ruleset in memory and follow a server-sent event stream. After every change the service pushes the new ruleset within a second; if the stream is down, the SDK polls every 5 seconds. There's no build, no deploy and no cache to purge. ## Kill always works - Anyone who can write, a person or a token with the kill action, can kill any flag, including protected flags that otherwise refuse agents. - Kill is exempt from agent rate limits and never needs approval, in auto-live or approvals mode. - It writes an audit row with who, which run, the state before and the note, so the post-mortem starts with the facts. Give the agents that ship your code the kill action, and tell them to kill their own flag the moment a check fails after a change. ## A kill switch for an AI agent's deploys When an AI agent ships code, the kill switch is the flag around each change it made, not the agent process. Give every agent change its own flag and a run id, and you can turn off one change, or everything one run shipped, without touching the rest. - Tag the agent's writes with its run. Set FLAGGER_RUN (or pass --run) in the agent's environment, so every flag it creates or changes records which run did it. Over MCP, the run is the tool's run input, else FLAGGER_RUN on stdio or the X-Flagger-Run header on the hosted server. - Find what the run changed. The console's audit log filters by run, agent, flag and actor (/audit?run=), and so does GET /v1/audit?run=. Each row shows the flag, the state before and after, and the agent's note. - Kill those flags. Run flagger kill for each one. Kill works on protected flags, skips approvals and rate limits, and reaches your apps within a second. - Stop the agent's flag access if you need to. Revoke its agent token on the console's Tokens page. From then on, every call with that token gets 401 unauthorized. Revoking doesn't undo what the agent already changed, so kill first, then revoke. ``` export FLAGGER_RUN="run_8812 https://ci.example.com/runs/8812" flagger set search_v3 percent --percent 10 --note "roll out PR #912 to 10%" --json # later, if the run's changes misbehave: flagger kill search_v3 --note "p95 latency doubled after run_8812" --json ``` Flagger.gg turns off features, not agents. Stopping an agent's other actions, like its access to your repo or cloud, is a job for the tools that granted that access. ## Automatic rollback In development Rolling a flag back automatically when error rates or other metrics regress is in development. Today a kill is a person's or an agent's call, made with one command. ## FAQ ### How do I turn off a broken feature instantly without redeploying? Put the feature behind a flag, then turn the flag off. With Flagger.gg, flagger kill turns it off for everyone and your apps see the change within a second. ### What's the difference between kill and setting a flag off? Both end in off and keep the rules. Kill is always allowed for anyone who can write, works on protected flags and skips rate limits and approvals. ### Can an AI agent use the kill switch? Yes, if its token has the kill action. It's the one change an agent can always make, even on protected flags. ### What's a kill switch for AI agent deploys? It's a flag around each change an agent ships, so a person or the agent can turn that change off in seconds without a redeploy. In Flagger.gg, give the agent's token the kill action and tag its writes with a run, so you can find and kill everything one run changed. ### How do I undo a kill? flagger revert (or flag_revert) rolls back to the state before the latest change. With approvals on, a revert that widens the flag past the agent's cap becomes a request. --- # Percentage rollouts and sticky bucketing URL: https://flagger.gg/guides/percentage-rollouts/ Updated: 2026-10-31 A percentage rollout turns a feature on for a share of users, chosen by a stable hash so each user keeps the same answer as you widen it. Flagger.gg buckets each user by the first 4 bytes of sha256(key:userId) mod 100, so going from 10% to 25% keeps the first 10%. Anonymous users stay off until the flag is fully on. ## Roll out step by step - Start with admins. flagger set new_search admins --note "team first" turns it on for your admins only. - Go to a small percentage. flagger set new_search percent --percent 10 --note "admins fine". Admins stay on. - Check who's in. flagger eval new_search --user usr_123 says whether one user is on, and why. - Widen it. Raise the percentage in steps (25, 50) as your checks stay healthy. Every user already in stays in. - Turn it on for everyone, then remove the flag. flagger set new_search on, and once it's stable, delete the flag and the old code path. ## How sticky bucketing works For a flag in percent, Flagger.gg computes a bucket from 0 to 99 for each user: ``` bucket = first 4 bytes of sha256(key + ":" + userId), read big-endian, mod 100 on = bucket < percent ``` For example, for the key new_search, usr_456 lands in bucket 22 and usr_123 in bucket 48. At 10% neither is in; at 25% usr_456 is; at 50% both are. Because a user's bucket never changes for a flag, raising the percentage only ever adds people, and lowering it removes the most recently added first. The key is part of the hash, so the same user lands in different buckets for different flags: your first 10% isn't the same 10% on every rollout. Both SDKs and the service run the same shared test vectors, so Go, Node and the service's eval always agree. ## In code The check is the same as for any flag; the SDK does the bucketing locally. ``` // Go on := client.Enabled("new_search", &flagger.Subject{UserID: user.ID, Email: user.VerifiedEmail}) b := flagger.Bucket("new_search", user.ID) // 0-99, for logs or debugging ``` ``` // Node / TypeScript const on = flagger.flag("new_search", { userId: user.id, email: user.verifiedEmail }); const { reason } = flagger.explain("new_search", { userId: user.id }); // e.g. "bucket 37 ≥ 10%" ``` ## Rules worth knowing - Anonymous users are off for every state but on: with no user id there's nothing stable to hash. - Admins are always in for admins, targets and percent. - Rules are kept. Switching from percent to admins and back keeps the percentage and targets. - Agents and the cap. With approvals on, an agent in production can set percent up to the cap (10% by default) on its own; above that it files a request a person approves. Lowering a percentage is always allowed. In development Scheduled rollouts (1 → 5 → 25 → 100% on a timer) and guarded rollouts that watch metrics and roll back on their own are in development. ## FAQ ### How do I do a percentage rollout with feature flags? Put the feature behind a flag, set it to a percentage such as 10%, check your metrics, then raise it in steps to 100%. With Flagger.gg: flagger set percent --percent 10. ### What is sticky bucketing? Assigning each user to a fixed bucket with a stable hash of the flag key and user id, so the same user always gets the same answer at the same percentage, and stays in as the percentage rises. ### Does a percentage rollout work for logged-out visitors? Not in Flagger.gg: callers with no user id see only flags that are fully on. ### How do I do a percentage rollout with the Go SDK? Set the flag to percent and call client.Enabled(key, &flagger.Subject{UserID: id}). The Go SDK buckets locally with flagger.Bucket(key, userID), the same function the service uses. --- # Trunk-based development with AI agents URL: https://flagger.gg/guides/trunk-based-development-ai-agents/ Updated: 2026-10-31 Trunk-based development means everyone, agents included, merges small changes to main many times a day, with unfinished work hidden behind flags. With agents producing many changes in parallel, flags replace long-lived branches: each agent ships dark, and the flag decides when the feature is live. ## Why agents push teams to trunk Several agents working at once on long-lived branches means merge conflicts, stale branches and big-bang merges nobody can review. Trunk-based development avoids that: every change is small, merges to main quickly and deploys. What isn't ready yet is merged anyway, behind a flag that's off. The flag, not the branch, becomes the unit of release. Code reaches production continuously; customers see a feature when its flag says so. It's one of the working habits of an AI-native company, where agents are part of the team from day one. ## Declare flags in code In Flagger.gg each app declares the flags it uses, and the SDK registers them when it starts. A flag that doesn't exist yet is created; a state someone set is never overwritten by a deploy. A flag can carry a not-ready reason, which keeps it off and refuses to turn it on without an explicit confirmation: ``` const flagger = createFlagger({ sdkKey: process.env.FLAGGER_SDK_KEY, defs: { bulk_invoices: { summary: "Customers can send invoices in bulk", description: "New bulk send flow in billing", owner: "billing", notReady: "PDF export not done", }, }, }); await flagger.start(); ``` In auto-live mode (the default) a newly registered flag starts on unless it carries a not-ready reason, which is how an agent merges unfinished work safely. When the work is done, the agent removes the reason in a later change, and the flag can be turned on. Turning a not-ready flag on needs confirmNotReady (--confirm-not-ready in the CLI), and bulk changes refuse it. ## See what's waiting to go live The Release console lists "Not live yet: N" first, with each flag's one-line summary of what changes for customers, so a person can see at a glance what the agents have merged and turn features live one at a time or in bulk. The console also marks which flags are registered by code, so flags an agent created through the API show as "not in code yet" until a deploy registers them. ## Habits that keep trunk healthy - One flag per change, named for what it does, with an owner. - Test both paths while the flag exists; see testing both sides of a flag. - Remove the flag once the feature is on for everyone; see flag cleanup. - Give agents the kill action, so a bad change on trunk is switched off in seconds. ## FAQ ### What is trunk-based development? A way of working where everyone merges small changes to one main branch at least daily, instead of keeping long-lived feature branches. Unfinished work is hidden behind feature flags. ### Does trunk-based development work with AI coding agents? Yes, and it suits them: agents make many small changes in parallel, and flags let each one merge and deploy dark without waiting for the others. ### How does an agent merge unfinished work safely? It wraps the work in a flag and gives the flag a not-ready reason, so the flag stays off and can't be turned on by mistake until the reason is removed. ### Who decides when the feature goes live? Your choice per project: in auto-live mode the agent can, and with approvals on, turning a flag on for everyone in production needs a person's approval. --- # Feature flags vs a staging environment URL: https://flagger.gg/guides/feature-flags-vs-staging/ Updated: 2026-10-30 Staging tests a copy of production; flags test the real thing with a few real users first. Many teams keep a development environment and skip staging, shipping to production behind a flag and widening it as checks pass. Flagger.gg has production and development environments, and no staging, by design. ## What each one tests | |Staging environment |Feature flag in production | |Data |A copy, often stale or synthetic |Real data | |Traffic |Your team and test scripts |Real users, a few at a time | |Infrastructure |Similar to production, rarely identical |Production itself | |Rolling back |Redeploy |Turn the flag off, in seconds | |Cost |A second copy of everything to run and keep in sync |A check in the code | Staging catches problems that only appear once code is deployed. It misses the ones that only appear with real data, real load and real users, and those are the ones flags are good at containing. ## Shipping without staging A common pattern, and the one Flagger.gg is built around: - Develop and test locally and in a development environment, where agents may do anything. - Merge and deploy to production with the new code behind a flag that's off. - Turn it on for admins, then targets (named users or workspaces), then a percent. - Turn it on for everyone, or kill it if anything breaks. Each Flagger.gg project has two environments, production and development, each with its own SDK key, flag states and rules. Flags are project-wide, so a flag created in one exists in both. ## When staging is still worth it - Database migrations and infrastructure changes that can't be hidden behind a flag. - Integrations with partners who need a sandbox to test against. - Regulated releases that require sign-off on a separate environment. Flags don't replace tests or code review either; they limit how many people a mistake reaches and how long it lasts. ## FAQ ### Do I need staging if I use feature flags? Often not. Many teams keep local and development environments, ship to production behind a flag, and widen it as checks pass. Keep staging for changes flags can't hide, like schema migrations. ### Can feature flags replace a staging environment? For most application changes, yes: a flag lets you test in production with admins or a few users first. They don't replace tests, review or staging for infrastructure changes. ### Does Flagger.gg have a staging environment? No, by design. Each project has production and development. ### Is testing in production safe? It's safe when exposure is limited and reversible: admins first, then a small sticky percentage, with a kill switch that takes effect within a second. --- # Testing both sides of a flag URL: https://flagger.gg/guides/testing-feature-flags/ Updated: 2026-10-30 Test the code with the flag on and with it off. Flagger.gg's SDKs include helpers for this: bothFlagStates runs a test twice, withFlag forces a state for one test, and setFlagOverride pins one. Go has the same in flaggertest, and a nil client is valid with everything off. ## Steps - Run the test in both states. Wrap any test that touches flagged code in bothFlagStates, so both paths stay covered for as long as the flag exists. - Force a state where only one matters. Use withFlag for a single test that needs the flag on (or off). - Pin a flag for a whole file with setFlagOverride, and clear it afterwards. - Delete the helpers with the flag. When the flag is removed, the off branch of each test goes with it. ## Node / TypeScript ``` import { test } from "node:test"; import assert from "node:assert/strict"; import { flagger } from "../src/flags.js"; test("checkout total", () => flagger.bothFlagStates("checkout_v2", async (on) => { const total = await checkoutTotal(cart); assert.equal(total, on ? 95 : 100); })); test("v2 shows the discount", () => flagger.withFlag("checkout_v2", true, async () => { assert.match(await renderCheckout(cart), /discount/); })); flagger.setFlagOverride("checkout_v2", true); // pin it flagger.setFlagOverride("checkout_v2", undefined); // clear it ``` ## Go ``` import ( "testing" "flagger.gg/go/flaggertest" ) func TestCheckoutTotal(t *testing.T) { flaggertest.BothFlagStates(t, client, "checkout_v2", func(t *testing.T, on bool) { want := 100 if on { want = 95 } if got := checkoutTotal(cart); got != want { t.Fatalf("got %d, want %d", got, want) } }) } func TestDiscountShown(t *testing.T) { flaggertest.WithFlag(t, client, "checkout_v2", true, func(t *testing.T) { // runs with checkout_v2 forced on }) flaggertest.SetFlagOverride(t, client, "other_flag", false) // until t.Cleanup } ``` A nil *flagger.Client is valid, and every flag on it is off, so tests and tools that never call New work without a key. ## How overrides behave - Overrides win in every SDK mode, including shadow and local. - They're per client and in memory: they never reach Flagger.gg or change a flag for anyone else. - explain reports "override" as the reason when an override decided the answer (Go). - To test the real rules instead, load a ruleset directly with setRules (Node) or SetRules (Go). ## FAQ ### How do I unit test code behind a feature flag? Run the test with the flag on and with it off. In Flagger.gg's SDKs, bothFlagStates does both in one call. ### Do tests need a Flagger.gg key or network access? No. With an empty SDK key the SDKs make no network calls, overrides are in memory, and in Go a nil client is valid with every flag off. ### Should I test every combination of flags? Usually not. Test each flag's two states where its code runs; combinations only matter where two flags touch the same code. --- # Flag cleanup and flag debt URL: https://flagger.gg/guides/feature-flag-cleanup/ Updated: 2026-10-30 Flag debt is the old flags left in code after a feature is fully on. Flagger.gg shows which flags are still registered by code (inCode, refreshed by every deploy) and lets you archive a flag once its code is gone. Removing the flag from code is a small PR an agent can make. Automated cleanup PRs are in development. ## Why flag debt builds up Every flag doubles the paths through a piece of code. Once a feature is on for everyone and stable, the off path is dead code, its tests test nothing real, and the flag check is a place where a wrong click could still turn the feature off. Teams whose agents create a flag for every change accumulate flags faster than anyone remembers to remove them. ## Find stale flags - On for everyone, for a while. flagger list --state on --json lists flags fully on; each flag's history shows when it got there. - No longer in code. A flag is "in code" when an SDK registered it in that environment in the last 30 days. Each deploy's registration refreshes it, so a flag that stops being registered loses the mark after 30 days. - Never in code. Flags an agent created through the API or MCP show "Not in code yet" in the console until a deploy registers them; one that never gets there is usually abandoned. ## Remove a flag safely - Make sure the flag is on in production and has been stable. - Delete the flag check and the old code path, its entry in your flag declarations, and the off branch of its tests. This is a small, mechanical PR, a good task for a coding agent. - Deploy. Once no app registers the flag any more, archive it in the console. Archived flags are left out of the rules SDKs download, so a missed check falls back to off, which is why the code goes first. Archiving is for people and admin tokens; agents can't archive flags. ## Automated cleanup In development Stale-flag detection that opens a cleanup PR for an agent to finish is in development. Today the "in code" and "not in code yet" marks plus each flag's history tell you what to remove. ## FAQ ### What is feature flag debt? The cost of flags left in code after they've done their job: extra code paths, extra tests, and a switch that can still change behaviour by accident. ### How do I clean up old feature flags? Find flags that are fully on and stable, remove the check and the old code path, deploy, then archive the flag in your flag service. ### When should a feature flag be removed? Once it's been on for everyone long enough that you wouldn't turn it off, usually days to a few weeks. Long-lived operational flags, like kill switches for a dependency, are the exception. ### Can an AI agent remove feature flags? It can make the code change, which is the bulk of the work. In Flagger.gg, archiving the flag afterwards is done by a person or an admin token. --- # A feature flag CLI for AI agents URL: https://flagger.gg/guides/feature-flag-cli/ Updated: 2026-11-02 The flagger CLI gives agents and people the same flag commands from a shell: create, set, target, kill, bulk, revert and eval. Every command takes --json and prints one JSON object, with errors as {"error":{"code","message"}}, and exits 0 when done, 2 when a change is waiting for a person's approval and 1 on an error. Agent tokens must give a --note on every write, which lands in the audit log with the run. ## Why agents want a CLI A coding agent already works in a shell. A CLI that answers in JSON and signals outcomes with exit codes fits the loop it runs: make a change, check the result, decide the next step. The flagger CLI does the same things as Flagger.gg's MCP server and API. Use whichever your agent handles best; many agents use the CLI inside scripts and checks, and MCP in conversation. For the wider checklist, see North Bay Ventures' guide to making your product usable by AI agents. Commands: login, logout, whoami, list, get, create, set, target, kill, bulk, revert, eval, requests, request, approve, decline, tokens, import, mcp and version. approve and decline work for people only. In development Packaged installs of the CLI (npm, Homebrew and go install) are in development. Until then, agents can make the same changes through the hosted MCP server at mcp.flagger.gg or the API at api.flagger.gg. ## Ship a change behind a flag from the shell - Give the agent a token. Create an agent token in the console, scoped to one project, its environments and its actions (read create target rollout kill request). Set it as FLAGGER_TOKEN, or store it with flagger login --token -, which reads it from stdin. flagger whoami shows what the token can do. - Name the run. Set FLAGGER_RUN to the agent's thread or job id, optionally followed by a URL, or pass --run. Every change records it. - Create the flag dark. In auto-live mode, the default, a new flag starts on unless it has a not-ready reason, so give one for unfinished work: flagger create new_checkout --summary "New checkout page" --not-ready "Payment copy not reviewed" --note "Ships the new checkout dark". - Widen it in steps. flagger set new_checkout admins --note "Admins first", then flagger set new_checkout percent --percent 10 --note "Checks green". Turning on a flag that has a not-ready reason needs --confirm-not-ready. - Handle approval. If the project has approvals on and the change is wider than the agent may make alone, the CLI exits 2 and prints the request. flagger request --wait polls until a person decides. - Kill it if checks fail. flagger kill new_checkout --note "Error rate up after rollout" turns it off for everyone, works on protected flags and is never rate-limited. flagger revert new_checkout puts back the state before the latest change. ## JSON output and exit codes With --json, every command prints exactly one JSON object on stdout: the API's answer as it is. Errors keep the same shape everywhere. Output an agent can parse without guessing is one of the basics of writing documentation AI agents can use. ``` $ flagger kill new_checkout --note "Error rate up" --json {"status":"applied","flag":{"key":"new_checkout","state":"off", …}} $ flagger set new_checkout on --confirm-not-ready --note "Ready" --json {"status":"pending_approval","request":{"id":"req_…", …},"url":"…"} $ echo $? 2 $ flagger set new_checkout sideways --json {"error":{"code":"invalid_request","message":"state must be one of …"}} ``` |Exit code |Meaning | |0 |Done. The change is applied, or the read succeeded. | |2 |Waiting for approval. A request was filed for a person to approve. | |1 |Error. The error.code says which, for example not_ready, forbidden, needs_approval or rate_limited. | ## Flags on every command |Flag |Environment variable |Meaning | |--project p |FLAGGER_PROJECT |Project slug. Defaults to the token's project. | |--env e |FLAGGER_ENV |Environment. Defaults to production. | |--note text | |Why. Required for agent tokens on every write. | |--run id [url] |FLAGGER_RUN |The agent's thread or run. | |--json | |One JSON object on stdout. | |--url u |FLAGGER_URL |API base URL. Defaults to https://api.flagger.gg. | The token is FLAGGER_TOKEN, else the one flagger login stored in ~/.config/flagger/credentials.json. ## Ask why a flag is on flagger eval new_checkout --user usr_123 answers whether the flag is on for that user and why, for example bucket 37 ≥ 10%, admin, in targets or anonymous. Add --email, --admin or --workspaces to describe the user. flagger list --not-live shows the flags that aren't on for everyone yet, and flagger get shows a flag with its history and pending requests. ## FAQ ### Is there a feature flag CLI with JSON output for AI agents? Yes. Every flagger command takes --json and prints one JSON object, errors included, with exit codes 0 (done), 2 (waiting for approval) and 1 (error). ### How does an agent know a change needs a human? The CLI exits 2 and prints {"status":"pending_approval", …} with the request. The agent can wait with flagger request --wait or move on. ### Can an agent approve its own change from the CLI? No. approve and decline need a person's own sign-in; agent and admin tokens can't approve. ### Why does my agent's command fail without --note? Agent tokens must say why on every write. The note goes into the audit log with the run, so a person can see which agent changed what and why. ### Should my agent use the CLI or MCP? Either. They make the same changes under the same token rules. The CLI suits scripts and CI checks; MCP suits agents that call tools directly. --- # An audit trail for agent flag changes URL: https://flagger.gg/guides/agent-audit-log/ Updated: 2026-10-31 When AI agents change feature flags, you need to know which agent made each change, in which run and why. Flagger.gg records every change with the actor (a person, a named agent token, the code registry or an import), the run, a note, the state and rules before and after, the client and the IP. Agent tokens can't write without a note, and the org audit log filters by agent, flag, run and person. ## What each change records |Field |What it holds | |Actor |Who: a person (name and email), an agent token by its name (for example "Checkout agent"), an admin token, the code registry, an import or the system. | |Run |Which run of the agent: an id and an optional URL, such as the agent's thread or CI job. | |Note |Why, in the agent's or person's words. Required for agent tokens. | |From and to |The state and rules before and after the change. | |Client |Where it came from: console, cli, mcp, api or sdk. | |IP |The address the change was made from. | |Request |For an approved change, the approval request it came from, so you can see who asked and who approved. | Each flag also keeps its own history: changes, the code registry creating it, imports and approvals, newest first. ## How the run gets recorded Agents often run many sessions in parallel, so "an agent changed it" isn't enough; you want the session. Flagger.gg takes the run from, in order: - the run input on an MCP tool, or --run id [url] on the CLI; - the FLAGGER_RUN environment variable (CLI and stdio MCP), or the X-Flagger-Run header over HTTP; - for MCP, failing both, the client's name from initialize. Put a link to the agent's thread or job in the run's URL, and the audit row leads straight back to the conversation that made the change. ## Find a change - Console: the org audit log at /audit filters by project, environment, flag, agent, person and run, and every filter is in the URL, so a filtered view can be shared. A flag's drawer has a History tab. Times are shown in 12-hour Eastern. - CLI: flagger get prints a flag with its history and pending requests. - API: GET /v1/audit takes project, env, flag, agent (token id or name), actor (email), run and action, up to 200 entries a page with a cursor. ## Undo what an agent did Once you've found the change, flagger revert (or the flag_revert tool) puts back the state before the latest change, and --to goes back to any point in the history. If you need it off now, kill it. Both are recorded too. ## Guardrails next to the log An audit trail tells you what happened. These decide what can happen: - Agent tokens are scoped to one project, a list of environments and a set of actions, expire after 90 days and can be revoked. - With approvals on, an agent in production can roll out up to a cap (10% by default) on its own; wider changes become requests a person approves. There is no approve tool for agents. - Protected flags refuse agents except for kill. - Agent tokens are limited to 30 writes a minute, and with approvals on, 5 changes to one flag an hour. Kill is exempt. User ids and emails of the people using your app never reach Flagger.gg, because flags are evaluated inside your app. The log holds changes to flags, not your users' activity. ## FAQ ### How do I see which AI agent changed a feature flag? Open the audit log in the Flagger.gg console and filter by flag. Each row names the agent token, the run, the note, and the state before and after. ### Can an agent change a flag without saying why? No. Writes from agent tokens without a note are refused, over the API, the CLI and MCP. ### Can I see everything one agent session did? Yes, if the agent passes a run id. Filter the audit log by run to see every change that run made. ### Does the audit log include my users' data? No. Flags are evaluated inside your app, so your users' ids and emails never reach Flagger.gg. The log only holds targeting lists that people or agents typed into a flag. --- # Local evaluation: why flag checks shouldn't call the network URL: https://flagger.gg/guides/local-evaluation/ Updated: 2026-11-03 Local evaluation means your app decides whether a flag is on from rules it already holds in memory, so a flag check is a function call, not a network request. Flagger.gg's Go and Node SDKs load the ruleset once, keep it current over a stream, and save it to disk so a restart during an outage still serves the last rules. An unknown flag, or one checked before any rules load, is off. ## Why not call the network per check A request handler may check several flags. If each check asked a remote service, every page would wait on that service, and an outage there would become an outage in your app. Evaluating locally removes both problems: - Speed. A check reads memory and never blocks. - Resilience. If the flag service is unreachable, checks keep answering from the last rules. - Privacy. The user you're checking stays in your app. With Flagger.gg, your users' ids, emails and workspaces never reach Flagger.gg; it stores only the targeting lists people type in. ## How Flagger.gg's SDKs stay current - At start, the SDK loads the last-known-good ruleset from its cache file on disk. - It fetches the current rules, waiting up to 3 seconds the first time by default, and registers the flags declared in your code. - It opens a server-sent events stream. A change reaches the SDK within a second. - If the stream drops, it polls every 5 seconds and reconnects with backoff, from 1 second doubling to 30 seconds. - Every new ruleset is written to the cache file atomically, and replaces the loaded one only if it's newer. Checks don't wait for any of this. Until a ruleset has loaded, from disk or the network, every flag is off. Ready() (Go) and ready() (Node) tell you whether one has. ## In code ``` // Go: flagger.gg/go client := flagger.New(flagger.Options{SDKKey: os.Getenv("FLAGGER_SDK_KEY"), Defs: defs}) client.Start(ctx) // cache, then fetch (up to 3 s), register, then stream in the background on := client.Enabled("new_search", &flagger.Subject{UserID: user.ID}) ``` ``` // Node / TypeScript: @flaggergg/node const flagger = createFlagger({ sdkKey: process.env.FLAGGER_SDK_KEY, defs }); await flagger.start(); // never rejects for network errors const on = flagger.flag("new_search", { userId: user.id }); ``` Both SDKs share the same evaluation rules and run the same shared test vectors, so a percentage rollout puts a user in the same bucket in Go, in Node and in the service's eval. A nil Go client is valid, with every flag off. In development Public installs of both SDKs (npm and go get) are in development. ## The trade-offs - The ruleset lives on your server. Your server holds every flag's rules for its environment, including targeted user ids and emails. That's why local evaluation belongs in server code, with an SDK key that can only read rules and register flags. - Changes aren't instant everywhere. A change arrives within a second over the stream, or within about 5 seconds while polling. - Browsers. In development Flagger.gg has no browser SDK yet. Your server sends the browser a map of the flags that are on for that user (evaluatedFlags in Node, For in Go), which includes only flags registered in code. ## Other tools do this too Local evaluation in server SDKs is common. Unleash's docs say its "backend SDKs perform the flag evaluation locally" and, by default, refresh every 15 seconds (Unleash SDK overview). LaunchDarkly's server-side SDKs "evaluate feature flags using their cached ruleset" and receive changes over a streaming connection (LaunchDarkly: choosing an SDK type). Both cover far more languages than Flagger.gg's Go and Node, and both offer edge or proxy options: Unleash Edge, and LaunchDarkly's Relay Proxy and edge SDKs. Facts checked October 31, 2026. Cloudflare Flagship evaluates inside Workers at the edge, and over HTTP from its Go and Python SDKs; see Cloudflare Flagship vs Flagger.gg. Replacing a flag system you built yourself? The SDKs' shadow mode serves your old answer while comparing it with Flagger.gg's; see moving off an in-house flag table. ## FAQ ### Does checking a feature flag make a network call? Not with Flagger.gg's SDKs. Each check reads the ruleset already in memory; only fetching and streaming rule changes use the network, in the background. ### What happens to my flags if Flagger.gg is down? Checks keep answering from the rules in memory. If your app restarts during an outage, the SDK loads the last-known-good ruleset from disk, so flags don't all turn off. ### What does a flag return before the rules load? Off. An unknown flag, one checked before any ruleset loads, or any error means off. ### Does Flagger.gg see my users? No. Users are evaluated inside your app, so their ids and emails never reach Flagger.gg. ### How fast does a flag change reach my servers? Within a second over the stream, or within about 5 seconds if the SDK has fallen back to polling. --- # Moving off an in-house flag table: import, shadow, cut over URL: https://flagger.gg/guides/migrate-feature-flags/ Updated: 2026-11-01 Move off a homegrown flag table in four steps: import every flag with its history, run the new SDK in shadow beside the old table so it serves the old answer and logs every difference, cut over once the log stays clean, then delete the old table after a quiet week. With Flagger.gg, the import checks itself against your export, and one environment variable, FLAGGER_MODE, switches between shadow, the new answer and the rollback. ## What can go wrong in a flag migration A flag migration fails quietly. Nothing crashes; some users just get a different answer than they did yesterday. The usual causes: - State drift. Someone flips a flag in the old admin page after the export, and the two systems disagree. - Different bucketing. The old system hashes users into percentages one way and the new one another way, so a 20% rollout reaches a different 20%. - Different matching rules. One system matches user ids ignoring case and the other exactly, or one treats admins or anonymous visitors differently. - New-flag defaults. The new service creates a flag your code registers before the import has brought over its real state. The fix for all four is the same: copy the data exactly, then compare both systems' answers on real traffic before you trust the new one. Flagger.gg was built from the flag system that runs Sandboxer and Transformer in production, and its import, shadow mode and rollback switch exist for exactly this move. ## The four steps - Import flags and history. Export your flags table and its change log to Flagger.gg's import JSON (below) and import it with an admin token. Each new flag gets its source state, rules and timestamps in that environment, and every past change is copied in order with its original time and person. Import before any build with the SDK reaches production: in auto-live mode a flag your code registers first is created on. - Check the import. flagger import reads every flag back and requires the state, the user, workspace and percent rules, any not-ready hold and every source event to match your export. Any difference is printed and the command exits 1. --verify runs the same check later without importing. - Shadow both systems. Ship the SDK with your old evaluation passed in as local. In shadow mode the app keeps serving the old answer, asks Flagger.gg too and logs each confirmed difference. Leave it for two to three days, until the confirmed count stays at zero. - Keep both sides in step. While shadowing, make no flag changes, or send every change made in the old admin page to Flagger.gg's API as well (dual-write). Otherwise the two sides will rightly differ. - Cut over. Run --verify once more, set FLAGGER_MODE=flagger and redeploy or restart. Point the old admin page at the matching console URL, and send writes to Flagger.gg only. - Clean up after a quiet week. Drop the old flags and events tables and delete the old evaluation and admin code. Keep the flag definitions in code: the SDK registers them at each start. In development Public installs of the Go and Node SDKs (npm and go get) and of the CLI are in development. The import works today through the API, POST /v1/import/{project}/{env}, with an admin token made in the console. ## The import file One JSON object: your flags, and your events oldest first. States are off, admins, targets, percent and on, and rules always hold users, workspaces and a percent. ``` { "source": "my-app", "flags": [ {"key": "new_checkout", "description": "Rebuilt checkout", "owner": "payments", "summary": "New checkout page", "state": "percent", "rules": {"users": [], "workspaces": [], "percent": 20}, "createdAt": "2026-09-02T14:00:00Z", "updatedAt": "2026-10-28T16:30:00Z"} ], "events": [ {"key": "new_checkout", "at": "2026-10-28T16:30:00Z", "by": {"email": "ana@example.com"}, "from": {"state": "admins", "rules": {"users": [], "workspaces": [], "percent": 0}}, "to": {"state": "percent", "rules": {"users": [], "workspaces": [], "percent": 20}}, "note": "Admins looked fine"} ] } ``` ``` flagger import --project my-app --env production --from flags.json \ --not-ready "garna=Keep off until payouts are connected" # later, before cutover: flagger import --verify --project my-app --env production --from flags.json ``` |Result |When | |created |The key is new. It's created with the source's state in this environment, and off in the project's other environments. | |updated |The key exists, but only its code registration has touched it. It takes the source's state and rules. | |skipped |Someone changed the flag in Flagger.gg (changed in Flagger), or it already matches (unchanged). | |held |You passed --not-ready key=reason. The flag carries that hold in this environment, code registration never clears it, and only a person can. | The import is one transaction and changes no state the source didn't have. Re-running it is safe: events are matched on key, time and new state, so a second run copies nothing and writes nothing. ## Shadow mode and the rollback switch Both SDKs take your old evaluation as local (Go: Local). FLAGGER_MODE then picks which answer the app serves: |FLAGGER_MODE |Answer served |Flagger.gg asked? | |shadow |Your old table's |Yes: compared, and differences logged | |flagger |Flagger.gg's |Yes | |local |Your old table's only. This is the rollback. |No | If FLAGGER_MODE is unset, the mode is shadow whenever you pass local, so a forgotten variable can't switch you over early. A misspelled mode is an error at start. ``` import { createFlagger } from "@flaggergg/node"; export const flagger = createFlagger({ sdkKey: process.env.FLAGGER_SDK_KEY ?? "", defs: { new_checkout: { description: "Rebuilt checkout", summary: "New checkout page", owner: "payments" } }, local: (key, ctx) => oldFlag(key, ctx), // your table's answer: served in shadow and local mode }); await flagger.start(); flagger.shadowStats(); // {mode, compared, differed, transient, confirmed, logged, notLoaded, byKey} ``` ``` flags := flagger.New(flagger.Options{ SDKKey: os.Getenv("FLAGGER_SDK_KEY"), Defs: defs, Local: func(key string, sub *flagger.Subject) bool { return old.Enabled(key, sub) }, }) if err := flags.Start(ctx); err != nil { // bad options or a bad FLAGGER_MODE, never the network return err } ``` A difference is checked again 10 seconds later, because a change reaches your old cache and Flagger.gg's stream at different speeds. If it's gone by then it counts as transient. If it's still there it counts as confirmed and logs one line, at most once an hour per key, user and pair of answers. Each line carries the key, both answers, the user id (or only its hash, if you turn ids off) and never an email. "Zero differences" means confirmed stays at 0. To roll back after cutover, set FLAGGER_MODE=local and restart. The app answers from the old table, which you left in place until the clean-up step. No code change or data migration is needed. ## Settle the rules before you shadow Shadow mode finds differences; it's quicker to know the likely ones in advance. Flagger.gg's rules, which both SDKs and the service share through one set of test vectors: - An unknown flag, one checked before rules load, or any error is off. - Visitors with no user id see only flags that are on. - Admins get admins, targets and percent flags. - Targeted user ids match exactly; verified emails match ignoring case. UUID-shaped entries are lowercased when saved. - A user's percent bucket is the first 4 bytes of sha256(key + ":" + userId), big-endian, mod 100; see percentage rollouts. If your old system hashes users differently, a partly rolled-out flag will reach different users after the move. Shadow mode will show it. Either finish those rollouts (fully on or off) before you cut over, or accept that some users will see the feature change. ## FAQ ### How do I migrate from a homegrown feature flag system to a flag service? Import your flags and their history, run the new SDK in shadow beside the old table until the two agree on real traffic, switch the app to the new answer, then delete the old table after a quiet week. Keep the old table until then: it's your rollback. ### Will my flag history come across? Yes. Each event is copied with its original time, the person who made it (the email, id or name your export gives), the before and after state, and its note. ### What if I run the import twice? Nothing changes. Events are matched on key, time and new state, and a flag someone has changed in Flagger.gg since is skipped rather than overwritten. ### How long should I run shadow mode? Long enough to see every flag evaluated for real users. Two to three days with zero confirmed differences is a sensible bar. ### How do I roll back after cutting over? Set FLAGGER_MODE=local and restart. The app serves your old table's answers without asking Flagger.gg. --- # Self-serve feature flags for startups URL: https://flagger.gg/guides/feature-flags-for-startups/ Updated: 2026-11-01 A startup needs a flag service it can sign up for and wire in the same afternoon: SDKs for its own languages, flag checks that never call the network, a kill switch, and a record of who changed what. Pick by your constraints: an open-source tool if you must self-host, an analytics suite if you want flags next to your metrics, and Flagger.gg if AI agents write most of your code and you use Go or Node. ## What a small team actually needs Most startups don't need experiments, segments and twenty SDKs on day one. They need to ship to production behind a switch and turn it off fast. A short checklist: - Self-serve sign-up. An account, an SDK key and a first flag without talking to sales. - SDKs for your stack. Check the languages you run in production, server and client, before anything else. - Local evaluation. The SDK holds the rules in memory, so a flag check is a function call and an outage at the vendor doesn't stall your app. See local evaluation. - A safe default. When anything goes wrong, the feature is off, not on. - A kill switch that works in seconds without a deploy. See kill switches. - Sticky percentage rollouts, so each user keeps the same answer as you widen a rollout. - An audit log of who changed which flag, when and why. - Test helpers for running code with a flag on and off. ## Choosing by constraint |If you… |Look at | |must run the service on your own infrastructure |Open-source tools such as Unleash, Flagsmith and GrowthBook (compared) | |want flags next to product analytics or session replay |PostHog (compared) | |run experiments with statistical readouts now |GrowthBook, Statsig or LaunchDarkly (compared) | |need many SDKs, segments and rich targeting |LaunchDarkly or ConfigCat (LaunchDarkly, ConfigCat) | |already use Datadog for metrics |Datadog Feature Flags (compared) | |have AI agents writing most of your code, in Go or Node |Flagger.gg | These overlap. Several of the tools above now publish an MCP server too; the comparison pages link each vendor's own docs so you can check. ## What you get with Flagger.gg Flagger.gg is a hosted flag service built for teams whose code is written by AI agents. It's self-serve: sign up with an email link or Google, and each account gets its own organisation and a project with production and development environments. A welcome page walks you through making an SDK key for your app and an agent token for your coding agent. - Five states: off, admins, targets (named users or workspaces), percent and on. A percent bucket is sticky per user. - Local evaluation in the Go and Node SDKs, with a disk cache so a restart during an outage serves the last rules. Unknown or not loaded means off. - Agents as first-class users: 11 MCP tools, hosted at mcp.flagger.gg or on stdio, a CLI with --json on every command, and agent tokens scoped to one project, its environments and its actions. - Guardrails: a note on every agent write, protected flags agents can only kill, and an optional approvals mode where agents roll out up to a cap and a person approves anything wider. - An audit log of every change with its actor, run, note, before and after. See the audit trail. - Test helpers: withFlag, setFlagOverride and bothFlagStates, and flaggertest in Go. New projects start in auto-live mode: a flag your code registers, or an agent creates, starts on unless it carries a not-ready reason. Turn approvals on in the project's settings when you want a person to sign off on wide changes. In development Experiments, segments and richer targeting, flags tied to metrics with automatic rollback, SDKs beyond Go and Node, and public npm and go get installs. Until the SDKs are public, apps can read their rules over the HTTP API. ## Mistakes small teams make with flags - Defaulting to on. If the flag service is down or the flag is misspelled, the unfinished feature ships. Default to off. - Calling the network per check. It adds latency to every request and turns a vendor outage into yours. - Never removing flags. Old flags pile up as dead branches; see flag cleanup. - Testing one side. Code behind a flag has two paths; test both. See testing both sides of a flag. - Keeping a staging copy just for flags. Many teams ship to production dark instead; see flags vs staging. ## FAQ ### What is a good self-serve feature flag service for a startup? One you can sign up for and wire in without a sales call, with SDKs for your languages, local evaluation and a kill switch. Choose an open-source tool if you must self-host, an analytics suite if you want flags beside your metrics, and Flagger.gg if AI agents write your code in Go or Node. ### What are the best feature flag tools in 2026? The names that come up most are LaunchDarkly, Unleash, Flagsmith, PostHog, GrowthBook, Statsig, ConfigCat and Datadog. They differ on hosting, experiments and SDK coverage; our comparison pages lay them side by side from each vendor's docs. Flagger.gg is the one built around AI agents shipping code. ### Should a startup build its own feature flags? A flags table and an if get you started, and many teams begin there. The work comes later: sticky percentages, an audit log, a fast kill path, caching and tests. If you've already built one, see moving off an in-house flag table. ### Can I sign up for Flagger.gg without talking to sales? Yes. Sign-up is self-serve at app.flagger.gg, with an email link or Google. ### Is Flagger.gg open source or self-hostable? No. It's a hosted service. Its SDKs evaluate flags inside your app, so the users you check flags for are never sent to Flagger.gg. --- # Give an AI agent scoped access to production flags URL: https://flagger.gg/guides/scoped-agent-tokens/ Updated: 2026-11-02 Give each AI agent its own token, scoped to one project, only the environments it works in, and only the actions it needs, such as read and kill but not rollout. In Flagger.gg that is an agent token (flg_agent_…): it expires within 90 days, can be revoked at once, can't approve, archive or make tokens, and must leave a note on every write. Protect the flags an agent should never flip, and turn approvals on so wide production changes wait for a person. ## Why agents need their own scoped tokens An agent that shares a person's login or an all-powerful API key can do anything that person can, and the audit log can't tell the two apart. Least privilege for agents means three things: a separate identity per agent, a scope that covers only the project, environments and actions the task needs, and a short life with a quick way to revoke it. Flagger.gg has four kinds of credential, and only one is meant for agents: |Prefix |Kind |What it can do | |flg_sdk_… |SDK key |Read the ruleset and register code flags in one environment. Nothing else. | |flg_agent_… |Agent token |One project, a list of environments, and the actions you pick. Expires within 90 days. | |flg_admin_… |Admin token |Everything an org admin can do, except approve. Not for agents. | |flg_user_… |User token |Made by flagger login; acts as that person, including approve. Not for agents. | Every token is stored only as a SHA-256 hash and shown once, when it's created. ## Steps - Decide what the agent needs. A coding agent that ships its own changes usually needs read, create, target, rollout and kill. An on-call or monitoring agent may need only read and kill. Add request if the agent should be able to ask a person for changes it can't make itself. - Create one token per agent. In the console's Tokens page, or with the CLI as an org owner or admin, name the token after the agent so the audit log reads clearly, and pick its environments, actions and expiry: ``` flagger tokens create --kind agent --project shop \ --name "Claude Code, checkout repo" \ --envs development,production \ --actions read,create,target,rollout,kill,request \ --expires-days 30 ``` The secret is printed once. Agent tokens last 90 days at most; a token made with no actions can only read. - Hand the token to the agent, not to the repo. Put it in the agent's environment as FLAGGER_TOKEN, or in the MCP client's Authorization header, so it stays out of version control. - Check what the token can do. flagger whoami --json prints the token's name, project, environments and actions. Over MCP, the agent only sees the tools its actions allow: a token with read and kill sees flags_list, flag_get, flag_eval, requests_list, request_get and flag_kill, and nothing that turns a flag on. - Protect the flags an agent must never flip. A person turns on the Protected switch in the flag's drawer in the console (admin tokens can set it through the API). Agents can then only kill it. They can't edit its description, and any other change is refused, or with approvals on becomes a request for a person. - Turn approvals on for production if you want a person in the loop. In the project's settings, approvals mode lets agents roll out in production up to a cap (10% by default) and turns anything wider into a request a person approves. See human approval for agent changes. - Review, renew or revoke. The Tokens page shows each token's last use and expiry. Renew an agent token for another 90 days, or revoke it, and its next call fails with 401 unauthorized. ## What each action allows |Action |Allows |MCP tools it shows | |read |Every read: flags, history, evaluations, requests |flags_list, flag_get, flag_eval, requests_list, request_get | |create |Create flags; edit description, summary and owner |flag_create | |target |Targets, admins and off |flag_set, flag_target, flags_bulk, flag_revert | |rollout |percent and on |flag_set, flags_bulk, flag_revert | |kill |Turn a flag off for everyone at once |flag_kill | |request |File an approval request when a change needs a person |(none; changes return pending_approval) | A token needs the action for a change even to ask for it: an agent without rollout can't file a request to turn a flag on. The refusal is 403 forbidden and names the missing action. ## What no agent token can do - Approve or decline requests. Approval is for people only, and there is no approve tool in MCP. - Archive or protect flags, change the project's policy, or make, renew or revoke tokens. - Turn on a flag that carries a not-ready reason without passing confirmNotReady (--confirm-not-ready in the CLI); bulk changes refuse such flags. - Write without a note. Every agent write records the token's name, the run, the note, the state before and after, the client and the IP (see the audit trail). - Go past its rate limits: 30 writes a minute and, with approvals on, 5 changes to one flag an hour. Kill is exempt from both. ## Where the scope stops Agent tokens are scoped by project, environment and action, not by individual flag. To fence off single flags, protect them. Tokens last up to 90 days, rather than being minted for one session, so give each agent its own token and a shorter --expires-days if the work is short. Other services handle agent access differently. LaunchDarkly's hosted MCP server, for example, signs in with OAuth and acts with the permissions of the member who authorized it, so you limit it with that member's role, including custom roles (LaunchDarkly's hosted MCP docs, checked 2026-11-02). ## FAQ ### How do I give an AI agent safe access to production feature flags? Give it its own token, scoped to one project, the environments it works in and the actions it needs, with an expiry. Protect the flags it must never change, and turn approvals on so anything wider than a small rollout waits for a person. ### Can I give an agent read-only access to flags? Yes. An agent token with only the read action can list flags, read their history and explain evaluations, and its MCP client sees no write tools. A token created with no actions gets read alone. ### Can an agent token approve its own change? No. Only a person can approve, signed in to the console or using a flagger login user token. Agent and admin tokens can't approve. ### How long does an agent token last? 90 days at most, or less if you set an expiry when you create it. You can renew it for another 90 days or revoke it at once from the Tokens page. ### Can an agent turn off a protected flag? Yes. Kill always works for anyone who can write, protected flags included, so an agent can stop a bad release. Any other change to a protected flag is refused or waits for a person. --- # Human approval for AI agent flag changes URL: https://flagger.gg/guides/human-approval-agent-changes/ Updated: 2026-11-03 Let agents make small, reversible production changes on their own and send anything wide to a person. In Flagger.gg, turn approvals on for a project: agents in production can still create flags, target users, kill and roll out up to a cap (10% by default), but going wider or turning a flag on for everyone becomes a request a person approves in the Release console or with flagger approve. Agents have no way to approve, and kill never waits. ## Why approve some agent changes, not all An approval step on every change turns a person into a bottleneck for agents that ship many small changes a day. No approval at all means an agent can turn a half-finished feature on for every customer. The middle ground is to judge each change by how many users it reaches: showing a feature to admins, a few named users or a small percentage is cheap to undo, while turning it on for everyone is not. Flagger.gg makes that call per project, with one switch in the project's settings. It's the same idea as capping what an agent can spend: let it act alone up to a limit, and ask a person past it (North Bay Ventures on how to stop an AI agent from overspending). ## Auto-live mode and approvals mode - Auto-live (the default). Agents' changes apply at once, within their token's actions. New flags start on unless they carry a not-ready reason. Protected flags still refuse agents except kill. - Approvals on. New flags start off. People and admin tokens can do anything. Agents in development can do anything but touch protected flags. Agents in production work up to a cap, set per environment (10% by default), and wider changes become requests. Switching modes never changes the state of an existing flag. ## What an agent can do in production with approvals on |Change by an agent |Result | |Create a flag, edit its description, summary or owner |Applied | |off, kill, admins, targets, target edits |Applied | |percent up to the cap |Applied | |percent above the cap, on, bulk on, a revert to something wider than the cap |Request for a person | |Anything but kill on a protected flag |Request for a person | |Archive, protect, change policy or tokens, approve |Refused (403 forbidden) | Reach decides. off, admins and targets count as 0%, percent as its share and on as 100%. A change needs approval only when it is wider than the cap and wider than the flag is now, so making a flag safer always applies: an agent can take a flag from 50% to 20% with a cap of 10%. With approvals on, an agent token can also change one flag at most 5 times an hour, on top of its 30 writes a minute. Kill is exempt from both. ## What the agent sees when a change needs approval - API: 202 with status: "pending_approval", the request, and a url to the request's page in the console. - MCP: the same answer as a normal tool result, not an error, so the agent can report the link and move on. requests_list and request_get show where it stands. - CLI: exit code 2. flagger request --wait --timeout 30m waits until a person decides. The token needs the request action to file requests; without it the change fails with 403 needs_approval. A new request for the same flag and environment replaces the older pending one, and a request no one decides expires after 72 hours. A line for your agent's instructions: "If a flag change returns pending_approval, stop and report the request URL; never retry it." ## How a person approves - Open the Release console. Pending requests are listed under "Waiting for you", and each has its own page with the change, who asked, the run and the note. - Approve or decline, one at a time or in bulk. From a terminal, a person signed in with flagger login can run flagger approve or flagger decline . - Approval applies the change in one transaction and records it in the flag's history and the audit log with the request id. If the flag changed after the request was made, approving fails as stale, so no one approves a change against a state they didn't see. Pass --force to approve it anyway. ## How other flag services handle approval LaunchDarkly has review-style approvals for flag changes, modelled on pull request reviews. Reviewers are alerted by email, in the app, and in Slack or Microsoft Teams. Requiring approvals is on select plans, and Enterprise customers can require them per environment (LaunchDarkly's approvals docs, checked 2026-11-02). Its workflow is more general than Flagger.gg's: people review people's changes too, with notifications in the tools a team already uses. Flagger.gg's approvals are built around agents: a rollout cap per environment, a change judged by how far it reaches, and no approve path for any agent. ## FAQ ### How do I require human approval before an AI agent changes production? Turn approvals on in the project's settings. Agents in production can then roll out up to the cap (10% by default) on their own, and turning a flag on for everyone, or going past the cap, becomes a request a person approves. ### Can an AI agent approve its own feature flag change? No. Only a person can approve, in the console or with a flagger login user token. There is no approve tool in MCP, and agent and admin tokens can't approve. ### Does an agent need approval to kill a flag? No. Kill always applies at once, on protected flags too, and isn't rate-limited, so an agent can stop a bad release without waiting for anyone. ### Can I change the rollout cap? Yes. The cap is set per environment in the project's settings. Production starts at 10% and development at 100%. ### What happens to a request no one answers? It expires after 72 hours and the flag stays as it was. A newer request for the same flag replaces it sooner. --- # LaunchDarkly vs Flagger.gg URL: https://flagger.gg/compare/launchdarkly/ Updated: 2026-11-03 LaunchDarkly is the most complete feature-management platform: many SDKs, experiments, segments and rich targeting. Flagger.gg is a hosted flag service built for teams whose code is written by AI agents, with MCP and a JSON CLI as first-class ways in, scoped agent tokens and a per-run audit trail. Pick LaunchDarkly for experiments and broad SDK coverage; pick Flagger.gg when agents ship your code and you use Go or Node. ## Side by side LaunchDarkly facts are from its own docs, linked, checked on October 30, 2026. We say nothing about its pricing. | |LaunchDarkly |Flagger.gg | |SDKs |About 34: client-side, mobile, server-side, edge and AI (SDK list) |Go and Node; browser/React, Python and mobile In development | |Targeting |Rules on any context attribute, and reusable segments (segments) |Admins, user ids or verified emails, workspace ids, sticky percent. Segments and attribute rules In development | |Experiments |A/B/n tests and multi-armed bandits (Experimentation) |In development | |Metric-guarded rollouts |Guarded rollouts watch metrics and can roll back automatically (guarded rollouts) |Kill switch and revert today; auto-rollback In development | |Approvals and schedules |Approval workflows and scheduled changes, on select plans (approvals) |Approvals per project with an agent rollout cap; scheduled changes In development | |MCP server |Hosted (OAuth) or local npm package (MCP docs) |Hosted at mcp.flagger.gg or flagger mcp; 11 tools shown by token scope; no approve tool | |Agent identity |API access tokens; OAuth sign-in for the hosted MCP server |Agent tokens per agent: one project, chosen environments and actions, 90-day expiry; a note required on every write; run recorded | |Self-hosted parts |Open-source Relay Proxy you run (Relay Proxy) |Hosted only | ## Where LaunchDarkly is stronger - Breadth. SDKs for nearly every platform, including browsers and mobile, which Flagger.gg doesn't have yet. - Experimentation and metrics. Built-in experiments and guarded rollouts that react to metrics. - Targeting. Rules on any attribute you send, and segments you define once and reuse. - Maturity. A long-established platform with enterprise workflows such as scheduled changes and approvals. ## Where Flagger.gg fits better - Agents ship your code. Each agent gets its own scoped token; MCP tools appear only when the token allows them; every agent write needs a note and records its run; agents can't approve. - Auto-live or approvals. Let agents' changes apply at once, or let them roll out to a cap (10% by default) and ask a person for anything wider. - A JSON CLI. Agents that run shell commands get one JSON object per command and meaningful exit codes. - A small surface. Five states, local evaluation, unknown means off, and a Release console that lists what isn't live yet first. Choosing for a small team? See self-serve feature flags for startups. Flagger.gg isn't the Flux/CNCF Flagger, a Kubernetes operator; it's the hosted flag service at flagger.gg (how the two differ). ## FAQ ### What's a good LaunchDarkly alternative for a startup? It depends on what you use. If AI agents write much of your code and you're on Go or Node, Flagger.gg is built for that. If you need experiments, browser or mobile SDKs, or self-hosting, look at LaunchDarkly itself or the open-source tools in this comparison. ### Does LaunchDarkly have an MCP server? Yes, hosted with OAuth or as a local npm package, per its docs. Flagger.gg's MCP server is hosted at mcp.flagger.gg or runs as flagger mcp, with tools scoped by agent token. ### Can I move from LaunchDarkly to Flagger.gg? Flagger.gg imports flags and their history from JSON with flagger import, and its SDKs have a shadow mode that compares answers with your current system before you switch. Mapping LaunchDarkly's targeting onto Flagger.gg's five states is a manual step. ### Does Flagger.gg do experiments? Not yet. Experiments are in development. --- # Datadog feature flags vs Flagger.gg URL: https://flagger.gg/compare/datadog/ Updated: 2026-10-30 Datadog's feature flags come from its 2025 purchase of Eppo and tie flags to Datadog's metrics and experiments. Flagger.gg doesn't need an observability suite: it's a standalone flag service with local evaluation and agent access through MCP and the CLI. Metric-tied rollouts and auto-rollback are in development on Flagger.gg. ## Datadog, Eppo and feature flags Datadog announced it was acquiring Eppo, an experimentation and feature-flag platform, in May 2025 (Datadog's announcement). Datadog now offers Feature Flags, built on OpenFeature, which correlate flags with APM, RUM, logs and SLOs and support monitor-driven canaries with automatic rollback, and Eppo's experimentation as Datadog Experiments. Datadog's hosted MCP server has a feature-flags toolset (MCP tools). Facts checked October 30, 2026. ## Side by side | |Datadog Feature Flags |Flagger.gg | |What it needs |Part of the Datadog platform |Standalone; no observability suite | |Metrics and rollback |Flags tied to APM, RUM, logs and SLOs; monitor-driven canaries with automatic rollback |Kill switch (within a second) and revert today; metric-tied rollouts and auto-rollback In development | |Experiments |Datadog Experiments (formerly Eppo) |In development | |SDK standard |OpenFeature |Go and Node SDKs with local, synchronous evaluation and shared test vectors | |Agent access |Feature-flags toolset in Datadog's hosted MCP server |Hosted or stdio MCP with 11 tools scoped by agent token, a JSON CLI, a note required on every agent write, no approve tool | ## Where Datadog is stronger - Flags next to your telemetry. If you already run Datadog, seeing a flag's effect on errors and latency, and rolling back on a monitor, is built in. - Experimentation. Eppo's statistics, now Datadog Experiments. - OpenFeature. A vendor-neutral SDK API. ## Where Flagger.gg fits better - You don't want flags tied to an observability vendor. Flagger.gg works on its own. - Agents ship your code. Scoped agent tokens, per-run audit, notes on every write, protected flags agents can only kill, and approvals that agents can't grant themselves. - Local evaluation with a disk cache. Checks never make a network call, and a restart during an outage serves the last good rules. Flagger.gg isn't the Flux/CNCF Flagger, a Kubernetes operator; it's the hosted flag service at flagger.gg. ## FAQ ### What's an alternative to Datadog feature flags? If you want flags without an observability platform, a standalone service such as Flagger.gg, LaunchDarkly or one of the open-source tools. Flagger.gg is the one built around AI agents changing flags. ### Did Datadog buy Eppo? Yes. Datadog announced the acquisition in May 2025, and Eppo's product is now Datadog Experiments. ### Does Flagger.gg roll back automatically on bad metrics? Not yet; that's in development. Today a person or an agent kills or reverts the flag with one command, and the change reaches apps within a second. --- # Unleash, Flagsmith and PostHog alternatives URL: https://flagger.gg/compare/unleash-flagsmith-posthog/ Updated: 2026-11-01 Unleash, Flagsmith and GrowthBook are open source and can be self-hosted. PostHog bundles flags with product analytics. Flagger.gg is hosted only and not open source; it's built for agent-driven teams, with MCP, a JSON CLI and scoped agent tokens. Choose self-hosted open source if you must run it yourself. ## Side by side Facts are from each vendor's own docs or repository, linked, checked on October 30, 2026. Pricing is left out. Several of these keep some features in paid or enterprise tiers; check their docs for what's in the open-source edition. |Tool |Open source |Hosting |Strengths |MCP server | |Unleash |Yes, AGPL-3.0 |Self-hosted, hybrid or Unleash Cloud (options) |Activation strategies, constraints, segments; 17 official SDKs plus community ones |Yes (docs), early-stage | |Flagsmith |Yes, BSD-3-Clause |Self-hosted, private cloud or SaaS |Remote config, segments, multivariate flags |Yes, hosted (docs), early release | |GrowthBook |Open core (mostly MIT) |Self-hosted with Docker or GrowthBook Cloud |Warehouse-native experiments and a stats engine |Yes, local or hosted (docs) | |PostHog |Open core (MIT outside ee/) |PostHog Cloud; self-hosting is a hobby deploy PostHog calls unsupported (self-host) |Flags with product analytics, session replay, experiments and surveys |Yes, hosted, with flag tools (docs) | |Statsig |No |Hosted |Experiments, feature gates, dynamic configs. OpenAI announced buying Statsig in September 2025; Amplitude acquired the product in May 2026 (Statsig) |Yes, hosted (docs) | |ConfigCat |No |Hosted |About 20 SDKs; percentage options, targeting rules, segments, prerequisite flags (targeting) |Yes, local over stdio (docs) | |Flagger.gg |No |Hosted only |Built for AI agents: scoped agent tokens, per-run audit, approvals with an agent cap, a JSON CLI; Go and Node SDKs |Yes, hosted or stdio; 11 tools by token scope, no approve tool | ## If you must self-host Choose Unleash, Flagsmith or GrowthBook. They're open source and run on your own infrastructure, which matters for air-gapped networks, strict data residency or a policy against third-party flag services. Flagger.gg is hosted only, though its SDKs evaluate flags inside your app, so the users you check flags for are never sent to Flagger.gg. ## If you want flags inside your analytics PostHog puts flags next to product analytics, session replay and experiments, so you can see a flag's effect on behaviour in one place. GrowthBook and Statsig lead on experimentation; see GrowthBook, Statsig and ConfigCat alternatives. Experiments on Flagger.gg are In development. ## If agents write your code Most of these tools now publish an MCP server. What Flagger.gg adds is the guardrails around agents: a token per agent scoped to one project, environments and actions; MCP tools that appear only when the token allows them; a note required on every agent write, with its run recorded; protected flags agents can only kill; and approvals mode, where agents roll out up to a cap and a person approves anything wider. Flagger.gg isn't the Flux/CNCF Flagger, a Kubernetes operator; it's the hosted flag service at flagger.gg. ## FAQ ### What is a good open-source feature flag service for startups? Unleash (AGPL-3.0), Flagsmith (BSD-3-Clause) and GrowthBook (open core) are the common choices, and all can be self-hosted. Flagger.gg is not open source; it's a hosted service built for agent-driven teams. ### What's an alternative to PostHog feature flags? If you don't need flags inside your analytics tool, a dedicated flag service: an open-source one like Unleash or Flagsmith, or Flagger.gg if AI agents ship your code. ### Is Flagger.gg open source? No. It's a hosted service at app.flagger.gg. ### Do Unleash and Flagsmith have MCP servers? Yes. Both publish official MCP servers, which their docs describe as early-stage. Flagger.gg's MCP server ships 11 tools gated by agent-token scope. --- # GrowthBook, Statsig and ConfigCat alternatives URL: https://flagger.gg/compare/growthbook-statsig-configcat/ Updated: 2026-11-01 GrowthBook is open core and self-hostable, with warehouse-native experiments. Statsig pairs feature gates with experiments, product analytics and session replay. ConfigCat is a hosted flag service with open-source SDKs in over 20 languages and rich targeting. Flagger.gg is a hosted flag service built for teams whose code AI agents write, with scoped agent tokens, approvals and a per-run audit trail, and SDKs for Go and Node. ## Side by side Facts are from each vendor's own docs or repository, linked, checked on November 1, 2026. Pricing and plans are left out; check each vendor for what's in which plan. Flagger.gg here is the hosted flag service at flagger.gg, not the Flux/CNCF Flagger. | |GrowthBook |Statsig |ConfigCat |Flagger.gg | |Open source |Open core: mostly MIT, with enterprise directories (repo) |Not stated in its docs |SDKs yes; the service no (on-premise FAQ) |No | |Hosting |GrowthBook Cloud, or self-hosted with Docker or a Helm chart (self-host) |Hosted |Hosted; an on-premise option and a self-hosted evaluation proxy (proxy) |Hosted only | |Evaluation |SDKs download feature definitions, cache them and evaluate in your app (SDKs) |Server SDKs evaluate locally and poll every 10 s by default (server SDKs) |SDKs evaluate locally and send no user data; auto polling every 60 s by default (caching) |Go and Node SDKs evaluate in memory; changes stream in under a second, with 5 s polling if the stream drops | |SDKs |Client, server and edge SDKs, from JavaScript and React to Go, Python, Rust and Swift |Server SDKs for Node.js, Java, Python, Go, Ruby, C#, PHP, C++ and Rust (server SDKs) |Over 20, including mobile, Unity and Unreal Engine (SDKs) |Go and Node | |Strengths |Warehouse-native experiments with Bayesian or frequentist stats (overview) |Gates, dynamic configs, experiments, product analytics and session replay in one place (session replay) |Targeting with percentage options, segments and prerequisite flags (targeting) |Agent tokens scoped by project, environment and action; approvals with an agent cap; protected flags; per-run audit | |MCP server |Hosted (OAuth) or local; four tools that read and write the REST API (docs) |Hosted; 18 default tools, including gate create and update (docs) |Local over stdio; creates, updates and toggles flags (docs) |Hosted at mcp.flagger.gg or flagger mcp on stdio; 11 flag tools shown by token scope; no approve tool | |CLI |Yes, with -o json (docs) |Yes, siggy, for gates, configs and experiments (docs) |Yes, with --json on several commands (docs) |Yes, flagger, with --json on every command and exit code 2 for "waiting for approval" | ## GrowthBook: experiments, and self-hosting Choose GrowthBook if experimentation is the point. Its analysis runs against your own data warehouse, with Bayesian or frequentist statistics, sequential testing and CUPED, and its docs say no raw user-level events are sent to GrowthBook. It's also the one here you can run yourself: one Docker image with MongoDB, or a Helm chart on Kubernetes. Its SDK list is far broader than Flagger.gg's, covering browser, mobile and edge runtimes. Flagger.gg doesn't run experiments yet In development, and it's hosted only. ## Statsig: flags inside an analytics platform Statsig combines feature gates with dynamic configs, experiments, product analytics and session replay, and has a warehouse-native option. Its server SDKs evaluate gates locally. Statsig's own blog says it agreed to join OpenAI in September 2025, and a note added since says Amplitude acquired Statsig on May 5, 2026, with the product, brand and customers now part of Amplitude (Statsig). Pick Statsig if you want flags and product analytics together. Pick a dedicated flag service, Flagger.gg among them, if you only need flags and already have analytics elsewhere. ## ConfigCat: many SDKs and rich targeting ConfigCat is a focused flag service with open-source SDKs in over 20 languages, including mobile and game engines, and targeting rules with percentage options, segments and prerequisite flags. Its SDKs evaluate locally and send no user data to ConfigCat. If you need a self-hosted setup, it offers an on-premise version and a proxy you run in your own infrastructure. Flagger.gg has five states (off, admins, targets, percent and on), with targeting by user id, verified email and workspace. Segments and richer targeting are In development. ## When AI agents ship your code All three publish MCP servers and CLIs, so an agent can change flags in any of them. Flagger.gg is built around the guardrails for that: - A token per agent, scoped to one project, a list of environments and the actions read create target rollout kill request, expiring after 90 days. - MCP tools listed only when the token's actions allow them, and no approve tool, so an agent can't approve its own change. - A note on every agent write, with the run (thread or job) recorded in the audit log. - An approvals mode in which agents roll out up to a cap in production, 10% by default, and a person approves anything wider. - Protected flags that agents can only kill, and a kill that is never rate-limited. It's built from the flag system that runs Sandboxer and Transformer in production, from North Bay Ventures. ## FAQ ### What's an alternative to GrowthBook for feature flags? If you don't need experiments, a dedicated flag service: ConfigCat for broad SDK coverage and targeting, an open-source tool like Unleash or Flagsmith if you must self-host, or Flagger.gg if AI agents ship your code in Go or Node. ### What's a Statsig alternative? For experiments, GrowthBook or LaunchDarkly. For flags with product analytics, PostHog. For flags alone, ConfigCat, Unleash or Flagsmith, or Flagger.gg if agents write your code. ### Is ConfigCat open source? ConfigCat's docs say its core SDKs are open source and the service itself is not. ### Which of these can I self-host? GrowthBook, with Docker or Kubernetes, and ConfigCat through its on-premise version. Flagger.gg is hosted only, though its SDKs evaluate flags inside your app, so your users are never sent to Flagger.gg. ### Do GrowthBook, Statsig and ConfigCat have MCP servers? Yes. GrowthBook's is hosted or local, Statsig's is hosted and ConfigCat's runs locally over stdio. Flagger.gg's is hosted or stdio, with 11 tools gated by agent-token scope. --- # Cloudflare Flagship vs Flagger.gg URL: https://flagger.gg/compare/cloudflare-flagship/ Updated: 2026-11-03 Cloudflare Flagship is Cloudflare's feature flag service, in public beta since May 2026, built on OpenFeature and evaluated inside Workers from config at the edge. Flagger.gg is a hosted flag service for teams whose code is written by AI agents: its Go and Node SDKs evaluate in memory in your own servers, and agents work through MCP and a JSON CLI with scoped tokens. Pick Flagship if your app runs on Workers; pick Flagger.gg when agents ship your Go or Node code. ## What Cloudflare Flagship is Cloudflare announced Flagship on April 17, 2026 (Cloudflare's blog) and opened a public beta on May 26, 2026 (changelog). It's built on Workers, Durable Objects and KV. A Worker with a Flagship binding evaluates flags from config at the edge with no outbound HTTP call. Its official SDKs are OpenFeature providers for TypeScript, Python and Go; the Go SDK "evaluates flags over HTTP and does not support the Cloudflare Workers binding" (Go SDK, SDKs). Facts checked November 3, 2026, from Cloudflare's own docs. ## Side by side | |Cloudflare Flagship |Flagger.gg | |Status |Public beta (May 2026) |Open sign-up; built from the flag system that runs Sandboxer and Transformer in production | |Where checks run |In Workers via the binding, at the edge; Go and Python SDKs over HTTP, with optional caching |In memory in your Go or Node app; no network call per check | |Change propagation |Up to 30 seconds globally (concepts) |Pushed over a stream within a second; 5-second polling if the stream drops | |SDKs |OpenFeature providers: TypeScript (Workers, Node.js, browser), Python, Go |Go and Node; other SDKs In development | |Targeting |Ordered rules with 13 operators, nested AND/OR groups, boolean, string, number and JSON variants (targeting) |Five states (off, admins, targets, percent, on); users, verified emails and workspaces; richer targeting In development | |Percentage rollouts |Consistent hashing on a configurable attribute; A/B/n splits (rollouts) |Sticky bucket from sha256(key:userId), with shared test vectors in both SDKs and the service | |Kill switch |Disabling a flag serves its default variation (Wrangler commands) |flagger kill, the flag_kill MCP tool or the console; always allowed, even on protected flags | |History |Create, update and delete events per flag (wrangler flagship flags changelog) |Org audit log with actor, agent token, run, note, before and after, filterable by run | |CLI and tokens |Wrangler commands with --json output; account-wide or app-scoped API tokens (API tokens) |flagger CLI with --json everywhere; agent tokens scoped to one project, chosen environments and actions, 90 days at most | |Agent access |Wrangler and the REST API, which agents can call |MCP server (hosted at mcp.flagger.gg, or flagger mcp) with 11 tools listed by token scope, a note on every agent write, no approve tool | ## Where Flagship is stronger - Apps on Workers. The binding reads config from KV in the same Cloudflare location that handles the request, so a Worker needs no SDK fetch and no extra service. - OpenFeature. Its SDKs are OpenFeature providers, so switching from another provider changes only the setup, not your call sites. - Richer rules and variants. Thirteen operators, nested conditions, multi-variant flags with string, number or JSON values, and A/B/n splits. - More languages. TypeScript, Python and Go today, plus a browser provider (which Cloudflare doesn't yet recommend for public-facing apps, since it needs an API token in client code). ## Where Flagger.gg fits better - Servers outside Workers. Flagger.gg's Go and Node SDKs check flags in memory from a streamed ruleset, with a disk cache for restarts during an outage, so no check waits on the network. - AI agents ship your code. Scoped agent tokens, an MCP server whose tools follow the token's actions, a required note and an optional run id on every agent write, and protected flags agents can only kill. - People stay in charge of wide changes. With approvals on, agents can roll out up to a cap in production (10% by default) and anything wider becomes a request a person approves; there's no approve tool. Flagger.gg isn't the Flux/CNCF Flagger, a Kubernetes operator; it's the hosted flag service at flagger.gg. ## FAQ ### What is Cloudflare Flagship? Cloudflare's feature flag service, in public beta since May 2026. It's built on OpenFeature and evaluates flags inside Workers from config stored at the edge. ### Can I use Cloudflare Flagship outside Workers? Yes. Its TypeScript, Python and Go SDKs work in other runtimes, but outside the Workers binding they evaluate over HTTP, with optional caching. ### Is there a Cloudflare Flagship alternative for Go or Node servers? Flagger.gg's Go and Node SDKs evaluate every check in memory, with changes streamed within a second. LaunchDarkly, Unleash and Flagsmith are other options. ### Which one works better with AI coding agents? Flagger.gg is built for it: an MCP server, a JSON CLI, agent tokens scoped to a project, environments and actions, and an audit log of each agent run. Flagship's docs describe Wrangler and a REST API, which agents can also call. --- # Privacy policy URL: https://flagger.gg/privacy/ Updated: 2026-10-30 Last updated October 30, 2026 This Privacy Policy describes how North Bay Opco I, Inc. ("Flagger.gg", "we", "us" or "our") collects, uses, discloses and otherwise processes personal information in connection with our websites (including flagger.gg and its subdomains), the Flagger.gg console at app.flagger.gg (including the Release console), the Flagger.gg API, the hosted and stdio MCP servers, the flagger command-line tool, our SDKs, and our related products, services, events, communications, and sales and marketing activities (together, the "Service"). By using the Service or providing information to us, you acknowledge that your information will be processed as described in this policy. If you use the Service on behalf of an organization, "you" includes that organization. ## Who we are North Bay Opco I, Inc., a Delaware corporation, is the controller of the personal information described in this policy. Information that you, your agents or your users put into or send through the Service, such as flag keys, descriptions, owners, rules and targeting lists (including the user and workspace ids you target), environments, approval requests, notes, imported flag history and the contents of API, CLI, SDK and MCP requests ("Customer Content"), is handled under our Terms of Service and any other agreement between you and us, including any data processing agreement. Where we process personal information in Customer Content on your behalf, you are responsible for it and for providing any notices and obtaining any consents the law requires. Contact: privacy@northbayventures.com, or North Bay Opco I, Inc., 777 Brickell Ave, Suite 500 PMB 1074, Miami, FL 33131, USA. ## Flag evaluation stays in your app Our SDKs download your environment's rules and evaluate flags inside your own application. The people, sessions and attributes your application evaluates flags for are not sent to us. In shadow mode the SDK compares its answers with your existing system and logs any differences inside your application; those logs are not sent to us. What the SDKs do send us is described under Information collected automatically. ## Information we collect We collect information that you provide to us, information collected automatically when you use the Service or interact with us, and information we obtain from other sources. The categories below are examples, and we may collect other information of a similar kind. ### Information you provide - Account and profile information, such as name, email address, company, your organizations, projects, roles and memberships, and your sign-in method (Google or an emailed sign-in link). - Communications, such as messages, support requests, feedback, survey responses, waitlist entries (email, company and the note you leave), event registrations, and information you give our team, along with records of those interactions. - Content and credentials, such as Customer Content, and the names and scopes of the SDK keys, agent tokens and admin tokens you create. - Payment and billing information, if we offer paid plans, such as plan, invoices, billing address and tax details. Payment card details would be processed by our payment processors. ### Information collected automatically - Usage and telemetry, such as how you use the console, features used, flag changes, approvals, and API, CLI, SDK and MCP requests (including the flags an SDK registers, its name and version, and when it fetches rules), performance and error data, and usage metrics. - Audit and history records: for each change, who or what made it (a person, an agent token or an admin token, with the agent's name and run link where given), when, and from which IP address. - Device and log information, such as IP address, approximate location, browser and device type, operating system, identifiers, software versions, referring and exit pages, pages viewed, and dates and times of access. - How you found us: the website or search engine that referred you, the campaign tags (utm tags) and ad click ids in the link you followed, the page you landed on, a channel we derive from them (for example "google" or "x"), and when. We keep your first and most recent visit with these signals in a first-party cookie and attach them to your account when you sign up. - Email interaction information, such as whether you open our emails and click their links. - Cookies and similar technologies, described under Cookies and similar technologies. ### Information from other sources - Sign-in and connected services, such as Google, including name, email address and account identifier. - Teammates who invite you to an organization, and give us your email address and role. - Business-data enrichment and website visitor identification providers, which may give us information about visitors to our websites and their organizations, such as name, business email address, job title, company, company size and industry. - Data providers, partners and other third parties, such as marketing, advertising and analytics partners, event organizers, resellers, referral and integration partners, and publicly available sources such as professional networks and company websites. We may combine information from these sources. ## How we use information We may use the information we collect for any of the following purposes: - To provide the Service, including creating and managing accounts, organizations and projects, signing you in, serving rules to your SDKs, keeping flag history and audit logs, operating and billing the Service, providing support, and sending transactional and service communications. - For security and integrity, including detecting, preventing and investigating fraud, abuse, security incidents and other harmful or illegal activity, and enforcing our Terms of Service. - For analytics, research and development, including understanding how the Service and our websites are used, measuring which channels bring sign-ups, measuring performance, debugging, conducting research, and developing, training and improving our products, services, features and technologies. - For marketing and advertising, including sending newsletters, product updates, offers and event invitations; personalizing our websites and communications; and delivering, targeting and measuring advertising, including interest-based and cross-context behavioral advertising. - For sales, including identifying, researching and contacting businesses and people who may be interested in the Service, including visitors to our websites, and managing our relationships with customers and prospects. - For legal, compliance and business purposes, including complying with legal obligations and requests, establishing, exercising and defending legal claims, enforcing our agreements, and in connection with corporate transactions. - For any other purpose described to you when the information is collected, or with your consent or at your direction. We may also create de-identified, aggregated or anonymized information and use and disclose it for any purpose. Where the law requires, we maintain and use de-identified information in de-identified form and do not attempt to re-identify it, except as the law allows. ## Cookies and similar technologies We and third parties use cookies, pixels, tags, scripts, local storage and similar technologies on our websites and in the Service, for example to operate the Service, keep you signed in, remember your preferences, provide security, analyze usage, record how you found us, and deliver and measure marketing and advertising. Third parties, including analytics and advertising providers, may collect information about your online activities over time and across different websites and services, and may combine it with information they hold from other sources. Today these include: - Sign-in (app.flagger.gg): a session cookie that keeps you signed in. Strictly necessary. - Security: Cloudflare may set cookies to protect the Service from bots and abuse. Strictly necessary. - Your cookie choice: flg_consent, for one year. - How you found us: flg_ft (first visit) and flg_lt (most recent visit with a referrer, campaign tags or a click id), first-party cookies on flagger.gg for 90 days. They hold only the fields listed under Information collected automatically, never your IP address or browser details, and aren't sent to any third party. - Google Analytics: _ga and _ga_* cookies, for up to two years, to count visits and see which pages are used. Advertising features are turned off. You can block or delete cookies in your browser settings, but some parts of the Service may not work without them. Our websites do not respond to Do Not Track signals. We treat Global Privacy Control signals as described under US state privacy rights. If you visit our websites from the European Economic Area, the United Kingdom or Switzerland, we load analytics technologies such as Google Analytics, and any advertising or visitor identification technologies, and we record how you found us, only after you agree in our cookie banner. You can change your choice at any time with "Cookie settings" at the bottom of our websites; declining removes the cookies that record how you found us. ## How we disclose information We may disclose personal information to: - Service providers that perform services for us, such as hosting, infrastructure, storage and backups, email delivery, customer support, analytics, security, and professional advice. - Marketing, advertising, analytics and visitor identification partners, including to identify visitors to our websites and to deliver, target and measure advertising. This may include contact information in hashed form for audience matching. - Members of your organization: owners, admins and members of an organization see its projects, flags, approval requests, history and audit log, including who made each change. - Sign-in, integration and connected services that you choose to use with the Service. - Affiliates, meaning companies under common ownership or control with North Bay Opco I, Inc. - Parties to a corporate transaction, such as an actual or proposed merger, acquisition, financing, reorganization, sale of assets, or bankruptcy, including during due diligence. - Authorities and others, where we believe it is required by law or legal process, or appropriate to protect the rights, property or safety of Flagger.gg, our users or others, to investigate fraud or abuse, or to enforce our agreements. - Others with your consent or at your direction. The service providers we use today: |Provider |Purpose |Location | |Latitude.sh |Servers and database (the Service runs on our own server there) |US | |Cloudflare |DNS, content delivery and network security; R2 storage for encrypted database backups |Global | |Resend |Email delivery, such as sign-in links |US | |Google |Sign-in with Google, if you choose it |US | |Google (Analytics) |Website usage statistics: pages visited, device and approximate location |US | ## How long we keep it We keep personal information for as long as reasonably necessary for the purposes described in this policy, including to provide the Service, for our legitimate business purposes, and to comply with legal, tax and accounting obligations, resolve disputes, and enforce our agreements. How long depends on the type of information, the purposes for which we hold it, and our legal obligations. For example: - Account and organization data: while your account is open, and deleted within 30 days after you ask us to close it, except as below. - Flag history and audit logs: for the life of the project, because they are the record of who changed what; they are deleted with the project or organization, unless we need them for security, a dispute or the law. - Sign-in links expire after 15 minutes and device sign-in codes after 10 minutes. API keys and tokens are stored only as hashes, until you revoke them. - Encrypted database backups roll off on a schedule (7 daily and 4 weekly copies), so deleted data leaves them within about five weeks. - Cookies: as listed under Cookies and similar technologies. The record of how you found us stays with your account. - Waitlist entries: until you ask us to delete them. - Server request logs: for security and troubleshooting. ## International transfers We are based in the United States, and we and our service providers may process information in the United States and other countries, which may have data-protection laws different from those where you live. Where the law requires, we use appropriate safeguards for transfers of personal information out of the European Economic Area, the United Kingdom or Switzerland, such as the European Commission's Standard Contractual Clauses (with the UK addendum) or a recipient's certification under the EU–US Data Privacy Framework. ## Security We use reasonable measures designed to protect personal information. Sessions, sign-in links, API keys and tokens are stored only as hashes, backups are encrypted, and traffic is encrypted in transit. No method of transmission or storage is completely secure, and we cannot guarantee the security of any information. You are responsible for keeping your credentials, SDK keys and tokens secure, including the tokens you give your agents. We will notify you and the authorities of a personal-data breach as the law requires. ## Third-party services The Service may link to or integrate with websites and services operated by others, such as Google, GitHub and the AI agents and providers you connect to our MCP server or CLI. Their privacy practices are governed by their own policies, not this one. ## Your choices - Marketing emails: you can unsubscribe using the link in any marketing email. We may still send you transactional and service messages. - Cookies: you can use "Cookie settings" at the bottom of our websites, and block or delete cookies in your browser settings. - Google Analytics: you can install Google's opt-out browser add-on (tools.google.com/dlpage/gaoptout). - Interest-based advertising: you can use the opt-out tools of the Digital Advertising Alliance (optout.aboutads.info) and the Network Advertising Initiative (optout.networkadvertising.org), and your device's advertising settings. ## US state privacy rights This section applies to residents of US states with consumer privacy laws, including California (CCPA, as amended by the CPRA), to the extent those laws apply to us. Categories of personal information. In the last 12 months we have collected the following categories of personal information: identifiers (such as name, email address, IP address, and account and device identifiers); customer records and commercial information; internet or other electronic network activity (such as usage, telemetry, log data, how you found us, and browsing activity on our websites); approximate geolocation; professional or employment-related information (such as company); and inferences drawn from the above. We collect it from the sources, use it for the purposes, and disclose it to the categories of recipients described above. We keep it for the period described under How long we keep it. Sale, sharing and targeted advertising. We do not sell personal information for money. In the last 12 months we have not sold personal information, shared it for cross-context behavioral advertising, or used it for targeted advertising as those laws define them. If we work with advertising or visitor identification partners in future, those disclosures may be a "sale", "sharing" or "targeted advertising" under some state laws; we will update this policy first and honor opt-outs. We do not knowingly sell or share the personal information of consumers under 16. We do not use or disclose sensitive personal information for purposes that would give you the right to limit its use. Your rights. Depending on your state, you may have the right to: - know about and access the personal information we have collected about you, and obtain a copy of it; - correct inaccurate personal information; - delete personal information; - opt out of the sale of personal information, sharing for cross-context behavioral advertising, and targeted advertising; - not receive discriminatory treatment for exercising your rights. How to exercise them. Email privacy@northbayventures.com with your request and your state of residence. To opt out of sale, sharing and targeted advertising, you can also enable Global Privacy Control in your browser; we treat it as a valid request to opt out for that browser. We will verify your request as the law requires, and we may ask for information to do so. You may use an authorized agent, who must provide proof of your authorization. If we deny your request, you may appeal by replying to our decision, and, if your appeal is denied, contact your state attorney general. ## EEA, UK and Swiss privacy rights If you are in the European Economic Area, the United Kingdom or Switzerland, we process your personal information on these legal bases: to perform our contract with you (for example, running your account and serving your flags); for our legitimate interests, including providing, securing, analyzing, improving and marketing the Service, keeping audit records, sales outreach, and preventing fraud, where those interests are not overridden by your rights; with your consent, where the law requires it (for example, analytics cookies and recording how you found us); and to comply with legal obligations. You may have the right to access, correct, delete, restrict or object to the processing of your personal information, to data portability, and to withdraw consent at any time without affecting processing that came before. You may object to processing for direct marketing at any time. To exercise these rights, email privacy@northbayventures.com; we answer within one month. You may also lodge a complaint with your local data-protection authority. ## Children The Service is for businesses and developers and is not directed to children. You must be 18 or older to use it, and we do not knowingly collect personal information from children under 16. If we learn that we have, we will delete it. ## Changes to this policy We may change this policy at any time by posting the updated version here and updating the "Last updated" date. Changes take effect when posted, unless the law requires otherwise. Where the law requires, we will give you additional notice. Your continued use of the Service after changes take effect means you accept the updated policy. ## Contact us Questions or requests about this policy: privacy@northbayventures.com, or North Bay Opco I, Inc., 777 Brickell Ave, Suite 500 PMB 1074, Miami, FL 33131, USA. --- # Terms of Service URL: https://flagger.gg/terms/ Updated: 2026-10-30 Last updated October 30, 2026 These Terms of Service ("Terms") are an agreement between you and North Bay Opco I, Inc., a Delaware corporation whose mailing address is 777 Brickell Ave, Suite 500 PMB 1074, Miami, FL 33131 ("Flagger.gg", "we", "us"). They govern your use of flagger.gg, the Flagger.gg console at app.flagger.gg (including the Release console), the Flagger.gg API, the hosted and stdio MCP servers, the flagger command-line tool and the SDKs (together, the "Service"). By creating an account, or by using the Service, an SDK key or a token, you agree to these Terms and the Privacy Policy. If you use the Service for an organization, you agree for that organization and confirm you have authority to bind it. "You" then means both you and the organization. Please read section 17. It requires most disputes to be resolved by binding individual arbitration, not in court, and waives class actions. You can opt out within 30 days of accepting these Terms (see section 17). ## 1. Eligibility You must be at least 18 years old, or the age of majority where you live if that is higher, and able to enter a binding contract. The Service is for businesses and developers. You may not use the Service if you are barred from receiving it under the laws that apply to you or to us, including the sanctions rules in section 15. ## 2. Your account, keys and tokens - Accurate details. Keep your account details accurate and your sign-in methods (Google, or the email address we send sign-in links to) secure. - Your responsibility. You are responsible for everything done with your account, your organizations and projects, and their SDK keys, agent tokens and admin tokens, including by agents or people you let use them, as if you had done it yourself. - If a key or token is exposed: revoke or rotate it, and tell us at security@northbayventures.com if you think someone used it without permission. - Organizations: owners and admins of an organization control its members, projects, environments, policies, keys and tokens. ## 3. The Service Flagger.gg is a feature flag service: it stores your flags and their rules, serves them to SDKs that evaluate them in your application, and lets people and agents change them through the console, API, CLI and MCP servers, under the approval policies you set. Features we label as beta, preview, experimental or in development are provided as they are, may change or end without notice, and are excluded from any commitment we make about availability. We may change the Service, for example to add or remove features or to change limits. If a change materially reduces what a paid plan includes, we will tell you in advance, and you may cancel before it takes effect. Software. While these Terms are in effect, we give you a limited, non-exclusive, non-transferable, revocable licence to install and use our SDKs, CLI and MCP server to access the Service. Where a component comes with its own open-source licence, that licence governs it. ## 4. Your releases and your agents Flags change how your software behaves in production. You decide what each flag controls, its defaults, its rules and its approval policies, including which changes your agents may make on their own (auto-live). You are responsible for what you release and for its effect on your systems and your users, whoever or whatever made the change. Test your defaults: if the Service can't be reached, our SDKs keep serving the last rules they loaded or your code's defaults. If you give a token to an AI agent, or connect one to our MCP server or CLI, you are responsible for what it does with the Service, including flags it creates, changes it makes or requests, and approvals it asks for, as if you had done it yourself. Approval policies and auto-live limits are tools to help you control agents; setting them is your choice and your responsibility. ## 5. Acceptable use Use the Service lawfully and only as these Terms allow. Do not: - use it to break the law, infringe others' rights, or deliver malware or harmful content; - probe, scan or test its security, or get around its limits, authentication or approval controls, except as part of a security report we have agreed to; - interfere with it or overload it, including with automated traffic beyond normal SDK, CLI and API use; - access other customers' data, or share, sell or resell access to the Service without our permission; - copy, reverse engineer or build a competing product from the Service, except as the law expressly allows; - put sensitive personal information (such as health, financial or government ID data) into flag rules or descriptions. You are responsible for all content and traffic you and your agents send to the Service. ## 6. Your content "Your Content" is everything you, your agents or your users put into the Service: flag keys, descriptions, owners, rules and targeting lists, environments, approval requests, notes, imported history, and the contents of your requests. - You keep ownership of Your Content. - Our licence. You give us, our affiliates and our service providers a worldwide, non-exclusive, royalty-free, sublicensable licence to host, store, copy, process, transmit, display, modify and create derivative works of Your Content to provide, operate, maintain, secure, support, develop and improve the Service and our other products and services, and as described in the Privacy Policy. The licence lasts while Your Content is in our systems, and continues for anything we have already made from it, such as aggregated or de-identified data and improvements to our products. - Your rights to it. You confirm you have the rights needed to put Your Content into the Service, and that it does not break the law or these Terms. - Feedback. If you send us ideas or feedback, we may use them for any purpose without obligation to you. ## 7. Third-party services The Service can connect to services we don't control, such as Google, GitHub, and the AI agents and model providers (Anthropic, OpenAI and others) you connect to our MCP server, CLI or API. Your use of them is governed by their terms, and you are responsible for complying with those terms. We are not responsible for third-party services or what they do with data you send them. ## 8. Fees The Service is currently provided without charge. We may introduce paid plans or usage limits. We will tell you before any fee applies to you, and you will be charged only for a plan you choose. Paid plans will be described on our website, including how they renew and are cancelled, and you will pay any applicable taxes. Fees are non-refundable except as required by law. ## 9. Suspension and termination Closing your account. You may stop using the Service at any time, and close your account by writing to privacy@northbayventures.com. Closing ends any plan immediately, without refund for the rest of the period. Suspension. We may suspend keys, tokens, projects or accounts immediately if we reasonably believe: - you are breaking these Terms; - your use creates a security or legal risk or harms others; - payment fails. Where we reasonably can, we will tell you why and give you a chance to fix the problem. Termination. We may end these Terms for convenience with 30 days' notice, refunding any prepaid, unused fees. After termination, your right to use the Service ends, and SDKs using your keys stop receiving rule updates. We are not required to keep Your Content after termination and may delete it, so export anything you need first. Sections 4, 6, 8 (fees owed), 10–15, 17 and 18 survive termination. ## 10. Data protection The Privacy Policy explains how we handle personal data. If you put personal data of others into the Service, for example user or workspace ids in targeting rules, you are responsible for it, including providing any notices and obtaining any consents the law requires. If you need a Data Processing Addendum, write to privacy@northbayventures.com. ## 11. Copyright complaints We respond to notices of alleged copyright infringement under the US Digital Millennium Copyright Act and similar laws. Send notices to legal@northbayventures.com or by mail to North Bay Opco I, Inc., 777 Brickell Ave, Suite 500 PMB 1074, Miami, FL 33131. A notice should identify the copyrighted work; identify the material you say infringes it and where it is; give your name, address, phone and email; state that you believe in good faith the use is not authorized by the owner, its agent or the law; state, under penalty of perjury, that the notice is accurate and that you are the owner or authorized to act for the owner; and carry your physical or electronic signature. If we remove your material and you believe that was a mistake, you can send a counter-notice to the same address. We terminate the accounts of repeat infringers in appropriate circumstances. ## 12. Disclaimers The Service is provided "as is" and "as available". To the fullest extent the law allows, we disclaim all warranties, express or implied, including merchantability, fitness for a particular purpose, title and non-infringement. We do not promise that the Service will be uninterrupted, error-free or secure, that flags will be evaluated or delivered as you expect, that approvals or policies will prevent every unwanted change, or that data will never be lost. Keep your own copies of anything important. Some jurisdictions do not allow these exclusions, so they apply to you only as far as the law permits. ## 13. Limitation of liability To the fullest extent the law allows: - Excluded losses. Neither party is liable for indirect, incidental, special, consequential or punitive damages, or for lost profits, revenue, data or goodwill, including losses caused by a release, rollback or flag change. - Cap. Each party's total liability arising from these Terms or the Service is limited to the greater of the fees you paid us in the 12 months before the claim, or one hundred US dollars. These limits do not apply to your payment obligations, your indemnity under section 14, or liability that cannot be limited by law. ## 14. Indemnity You will defend and indemnify Flagger.gg, its affiliates and their personnel against third-party claims, and the resulting losses and costs (including reasonable legal fees), arising from: - Your Content; - your software, your releases, and your, your agents' or your users' use of the Service; - your breach of these Terms. ## 15. Export controls and sanctions You must comply with all export-control and sanctions laws that apply to you or to the Service. You may not use the Service if you are located in, ordinarily resident in, or organized under the laws of a country or region subject to comprehensive US, EU or UK sanctions, or if you are on a restricted-party list. You may not use the Service for the benefit of any such person. ## 16. Changes to these Terms We may update these Terms. For material changes we will give at least 30 days' notice by email or in the console before they take effect. If you keep using the Service after a change takes effect, you accept it. If you don't agree, stop using the Service and close your account. ## 17. Governing law and disputes Governing law. These Terms are governed by the laws of the State of Florida, without regard to its conflict-of-laws rules. The Federal Arbitration Act governs the arbitration agreement below. Talk to us first. Except for claims under Exceptions below, before starting arbitration or a court case, email legal@northbayventures.com with a description of the dispute and the relief you want. If we have a dispute with you, we will email your account address. Both sides will try in good faith to resolve it within 30 days. Binding individual arbitration. Except as set out below, any dispute arising out of or relating to these Terms or the Service that isn't resolved informally will be settled by binding arbitration administered by the American Arbitration Association (AAA) under its Consumer Arbitration Rules (or its Commercial Arbitration Rules for disputes between businesses). The seat of arbitration is Miami, Florida. Hearings may take place by video or phone, or on the documents alone. Judgment on the award may be entered in any court with jurisdiction. Class-action waiver. You and we may bring claims only individually, not as a plaintiff or class member in a class, collective or representative proceeding. The arbitrator may not consolidate claims or award relief to anyone other than the individual party. If this waiver is found unenforceable for a claim, that claim goes to court under the venue clause below, not to arbitration. Exceptions. Either party may bring an individual claim in small-claims court if it qualifies. Either party may also ask a court for an injunction or other equitable relief to stop infringement or misuse of its intellectual property, or unauthorized access to or abuse of the Service. Opt out. You can opt out of arbitration and the class-action waiver by emailing legal@northbayventures.com within 30 days of first accepting a version of these Terms that contains this arbitration agreement, with your name, your account email and a clear statement that you opt out. Opting out doesn't affect the rest of these Terms. Venue. Except as stated in the next point, anything not arbitrated will be heard only in the state and federal courts located in Miami-Dade County, Florida, and both parties consent to their jurisdiction. Consumers outside the US. If you are a consumer living in the EU, the UK or another country whose law doesn't permit a pre-dispute arbitration agreement or class-action waiver with consumers, the arbitration agreement and class-action waiver don't apply to you, and you may bring claims in the courts where you live. Nothing in these Terms limits mandatory consumer-protection rights you have where you live. ## 18. General - Entire agreement. These Terms, together with the policies they reference, are the entire agreement between you and us about the Service. - Severability and waiver. If a provision is unenforceable, the rest remains in effect. Failing to enforce a right is not a waiver. - Assignment. You may not assign these Terms without our consent. We may assign them in a merger, acquisition or sale of assets. - Force majeure. Neither party is liable for delays caused by events beyond its reasonable control. - Notices. We send notices to your account email. Send notices to us at legal@northbayventures.com or by mail to North Bay Opco I, Inc., 777 Brickell Ave, Suite 500 PMB 1074, Miami, FL 33131. ## Contact Questions about these Terms: legal@northbayventures.com.