ConfigCat — feature flags with unlimited seats

Three moves, and the deploy stops being the scary part.

Code goes to main with the flag off. The launch happens later, on your schedule, from a dashboard anyone on the team can open.

Add the flag

Create the setting in the dashboard, then read it with getValueAsync and a default value. The default is what your app serves if we are ever unreachable, so the flag can never take your app down with it.

Aim it

Percentage Options split traffic. Targeting Rules pick the people. Both live in the config.json your SDK already downloads, so changing who sees what needs no deploy and no restart.

Clean it up

The CLI scans your repo and uploads Code References, so every flag links to the lines using it. The Zombie Flags report then tells you which ones stopped changing — the list of what is safe to delete.

The whole release, on one panel.

Everything below is live. Drag it, flip it, break it. That is the point — this is the part of the product that a screenshot cannot sell.

Percentage Options

Roll out by percentage

Split users across values and widen the group when the numbers hold. The same user keeps landing in the same group, so nobody watches the feature flicker in and out.

25% 3,118 of 12,473 users get newCheckoutFlow

0%25%50%75%100%

One switch

Turning it off is the same move

Bad launch? Flip the setting to off. No rollback, no redeploy, no war room.

serving · newCheckoutFlow

Targeting Rules

Ship to exactly who you mean

Conditions read like the sentence you would say out loud, against attributes you already have on the User Object.

serve true when Email ENDS WITH @acme.com and Country IS ONE OF [DE, AT]

Audit log

Every change, with a name on it

Who changed what, in which environment, and when. Kept 7 days on Free, 35 on Pro and Smart, two years on Enterprise.

Environments

On in Test, off in Production

One setting, separate values per environment. Two environments on Free, three on Pro, unlimited from Smart up.

Test

Staging

Production

Zombie Flags

The report that tells you what to delete

Flags are technical debt with a nice interface. ConfigCat watches which ones stopped changing and emails you the list on the schedule you set — daily, weekly or monthly. Tag the ones meant to live forever and they drop off it.

savedPaymentMethodschanged 2d ago

legacyPricingTableZOMBIE96d

oldOnboardingCopyZOMBIE141d

The whole API is one question.

What is this setting worth for this user? The percentage maths, the targeting, the download — all of that happens before your line of code runs.

import * as configcat from 'configcat-js'

const client = configcat.getClient('#YOUR-SDK-KEY#')

const value = await client.getValueAsync(
  'newCheckoutFlow',
  false,                                // default if we're unreachable
  new configcat.User(user.id)
)

return value ? renderNewCheckout() : renderClassicCheckout()

import "github.com/configcat/go-sdk/v9"

client := configcat.NewClient("#YOUR-SDK-KEY#")

on := client.GetBoolValue(
    "newCheckoutFlow",
    false,                              // default if we're unreachable
    &configcat.UserData{Identifier: user.ID},
)

if on {
    return renderNewCheckout()
}
return renderClassicCheckout()

import configcatclient
from configcatclient import User

client = configcatclient.get('#YOUR-SDK-KEY#')

on = client.get_value(
    'newCheckoutFlow',
    False,                              # default if we're unreachable
    User(user.id)
)

return render_new_checkout() if on else render_classic_checkout()

Same three arguments in every SDK: the setting key, the default, the user.

Priced on traffic, not on headcount.

Most feature flag tools charge per seat, which quietly turns "who is allowed to see the flags" into a budget question. This one does not.

seats unlimited on every plan, including the free one

Forever Free

Enough to put a real feature behind a real flag.

$0forever

10 feature flags, 2 products
2 environments, 2 segments
4 targeting rules per flag
5M config downloads / month
99% uptime SLA · 7-day audit log

Start free

MOST TEAMS

Pro

For a team shipping to production every week.

$110per month

100 feature flags, 3 products
3 environments, 3 segments per product
8 targeting rules per flag
25M config downloads / month
99.9% uptime SLA · 35-day audit log
3 webhooks

Start free, upgrade later

Smart

When the limits start being the thing you think about.

$325per month

Unlimited flags, environments, segments
Unlimited targeting rules
10 products
250M config downloads / month
99.95% uptime SLA · 35-day audit log
Unlimited webhooks

Start free, upgrade later

Enterprise

$900 / mo

1B config downloads, 4 TB traffic, 99.99% uptime SLA, two-year audit log retention.

Talk to us

Dedicated

$4,500 / mo

6B+ config downloads, 24 TB traffic, isolated infrastructure. Add-ons available on every tier.

Talk to us

Fair questions.

What happens to my app if ConfigCat goes down?

Nothing you have to page anyone about. The SDK evaluates against a config it has already downloaded, so a flag check does not wait on us. If we are unreachable it keeps serving the last config it holds, and if it never got one, it returns the default value you passed at the call site.

That default is not a formality. It is the answer to this question, and you write it on the first line you ever type.

Does a flag check slow down my requests?

The evaluation is local. Your SDK downloads config.json from our CDN on the polling mode you choose — automatic on an interval, lazy with a cache TTL, or manual — and every check after that runs against what is already in memory.

How is this different from environment variables?

An environment variable changes when you redeploy. A setting changes the moment you save it — for a percentage of users, for one country, for one customer — with an audit trail and a one-click undo. Environment variables are configuration. Flags are release control.

Can product managers change flags, or only engineers?

Anyone you invite, and inviting them costs nothing, because seats are unlimited on every plan. That is the practical argument for the pricing model: the person who wants the feature on at 10am should not have to file a ticket with the person who holds the seat.

What stops us drowning in old flags?

Two things, and they work together. The CLI scans your repository and uploads Code References, so each flag shows the files and lines that still use it. The Zombie Flags report then emails you the flags that have not changed inside your chosen window — daily, weekly or monthly, with a tag to exclude the ones meant to be permanent.

What does the free plan actually hold back?

Volume, not people. Ten flags, two environments, two products and five million config downloads a month, on a 99% SLA. Seats stay unlimited, so the whole team can be in there from day one.

Turn any feature offon without a release.