How Toggled works

Managing feature flags without the chaos

One flag follows one lifecycle: create it, target it, roll it out, measure it, and keep a kill switch under your thumb the whole time. Here is each step in detail, in the order your team will actually live it.

No card required

Step 01 · Create the flag

Wrap the new path, deploy whenever

A flag is one conditional around the code you are not ready to show. Merge it to main, deploy it to production, and nothing happens: the flag is off, so every user stays on the old path. Deploying stops being the same decision as releasing, which is the core idea behind any feature toggle.

Name flags like code: checkout.new-flow, owned, searchable, with full history.
Every flag carries a safe default, so an unreachable network can never take the wrong path.
Unlimited flags on every plan. Flag freely; clean up freely.

app/checkout.ts

const newFlow = await flags.isEnabled(
  'checkout.new-flow',
  { userId: user.id, plan: user.plan },
);

return newFlow
  ? renderNewCheckout()   // nobody sees this yet
  : renderClassicCheckout();

Targeting rules · checkout.new-flow

team = internal serve: new

beta = true serve: new

country = US · plan = pro rollout: 25%

everyone else serve: old

Rules read top to bottom; the first match wins.

Step 02 · Target who sees it

Internal first, then beta, then the world

Rules target users by anything you pass the SDK: user id, plan, region, device, or your own attributes. The classic ladder is internal team, then beta opt-ins, then a percentage of everyone. Rules evaluate locally inside the SDK, so targeting adds no network hop and works in every language the same way.

Plan-based rules double as entitlements: gate a premium feature with plan = pro and pricing changes stop requiring deploys. More patterns live in feature flag service use cases.

Step 03 · Roll out 1% to 100%

One slider, no cliff

A gradual rollout walks the flag up a ladder: 1%, 10%, 25%, 50%, 100%, with a hold at each step while you watch errors and latency. Consistent hashing keeps every user in the same cohort at every step, so nobody flickers between old and new, and the 1% you tested is inside the 10% you test next.

This is exactly a canary deployment without touching your infrastructure: no second cluster, no load-balancer surgery, no traffic mirroring project.

Rollout plan · checkout.new-flow

1% Soak 24h. Watch error rate and p95 latency.

10% Soak 24h. Add conversion guardrail.

25% Currently here. Holding 48h.

50% Waiting on guardrail check.

100% Then delete the flag.

experiment: checkout.new-flow

Illustrative sample data

A · classic checkout3.1%

B · new checkout4.6%

Guardrails: error rate flat, p95 latency +2ms, refunds flat.

Step 04 · Measure the impact

The rollout is already an experiment

While the flag is partially on, your traffic is split between old and new. Attach a metric and that split becomes an A/B test: conversion for the primary question, error rate and latency as guardrails. You find out whether the feature helped before it reaches everyone.

The full story is on the A/B testing software page, including when a test is not worth running.

Step 05 · The kill switch

When it goes wrong, it goes off

Any flag can be flipped off for everyone in one click. SDKs converge in about 3 seconds, every user lands back on the known-good path, and your deploy stays exactly where it is. Compare that with a revert, a build, and a rollout window measured in tens of minutes while customers watch errors.

The feature flag kill switch page covers the rules that keep the switch trustworthy months after launch. The short version: the old path keeps working, and SDKs fail safe to last-known values even if Toggled itself is unreachable.

Incident recovery

Redeploy

45 min

→

Flag off

~3 s

Design target for SDK convergence after a kill-switch flip. Try it live in the homepage console.

Try the kill switch

Under the hood

Built so the worst case is boring

Local evaluation

Rulesets stream to your SDK and evaluate in-process. Flag checks are sub-millisecond and add zero network hops to your request path.

Fail-safe defaults

If the stream drops, SDKs keep serving the last-known ruleset, then your coded defaults. Our outage never becomes your outage.

Consistent hashing

The same user lands in the same cohort in every SDK and every service, so partial rollouts stay coherent across your whole stack.

SDKs for React, Next.js, Node.js, Python, Go, Java, Rails, iOS and Android. Start with React, Next.js, Node.js or Python.

Early access · launching soon

See your first flag flip in minutes

Join the early-access list and we will email you when your spot opens. Flat pricing, unlimited seats, no card required.

No card required · your data stays yours

Keep exploring