v1.0 · May 2026 Latest: A truth pass over this site · Jul 9

Stop redeploying
to flip a switch.

feat evaluates flags inside your runtime and streams changes to every SDK as they happen. Every plan is a small flat rate with unlimited seats and flags; your monthly active users just decide which tier fits.

Start free → Email the founder

No credit card npm i @feathq/js-sdk 2-minute setup

new-checkoutOFF

flag_key: new_checkout_v2

· user.plan is pro· device.platform in [ios, android]· rolled out to 0% of pro-tier orgs· evaluated 1.2M× today

Acme Headphones

Studio-grade sound, 38-hour battery, active noise cancelling.

$249 USD

VARIANT_B · CONTROL

events · livestreaming
04:21flag.evaluatednew_checkout_v2 → true · user_8231
04:19rule.matchedcountry in [US, CA, UK] · plan = pro
04:17flag.evaluatednew_checkout_v2 → false · user_8230

01 / what's in the box

A full flag platform.
Targeting to approvals.

Six things every flag platform should do, working from your first signup: targeting rules, sticky rollouts, per-environment approvals, a real audit log, the right key for each runtime, and local in-runtime evaluation.

Targeting beyond users.

Describe who you mean: paying orgs in Brazil, devices on app version 3.2, one specific customer having a bad day. Combine conditions with AND and OR, save the result as a segment, and watch the live preview show who matches.

Sticky rollouts.

Ship a flag to 10% of pro-tier organizations in Germany with one click. Sticky rollouts keep the same audience on the same variation across requests, sessions, and devices. Different rules can carry different splits, with a fallback split that catches everyone else.

Approvals per env, per flag.

Production requires approval. Staging doesn't. Configure how many approvers, whether comments are required, and whether requests expire, per environment.

Different keys for different runtimes.

Server keys for back-ends, browser-safe keys for client-side code, and a semi-secret mobile key type reserved for future native SDKs. Each tuned to its runtime's security model.

Auditor-grade history.

Every change captured with full before-and-after history, who made it, and why. 30 days on Free, 3 years on Scale, custom on Enterprise.

Evaluates locally. Updates live.

Save a change and connected SDKs pick it up over the live stream in under a second; a background poll catches up within 30 seconds if a stream drops. Your SDK keeps a local copy and evaluates flags in your runtime, so there's no network call per flag check. JavaScript, Python, Go, Ruby, and an Edge Worker SDK all evaluate the same way, so what your back-end returns matches what the edge serves.

02 / targeting

The audience updates
while you type.

Compose rules across any audience you can describe: users, devices, organizations, sessions, requests. Conditions compare text, numbers, dates, and semver, and combine with AND and OR.

flag · new_checkout_v2

Serve true to audiences where

recalculating

AND

AND

→ otherwise servefalse

live audience preview

0.38M / 4.82M users

7.9% of monthly actives match these rules.

user.plan is "pro"  AND
device.platform in "ios, android"  AND
device.app_version version ≥ "2.4.0"

03 / rollout + experiments

Roll out to 1%,
then 10%, then everyone.

Ship a flag to 1% of any audience. Sticky rollouts keep the same user (or device, or organization) on the same variation across requests and sessions. Different rules can carry different splits, with a fallback split for everyone else. A built-in statistical engine and auto-advance gradual rollouts arrive Q3 2026.

Progressive rollout

drag to adjust

Ship to 1%, watch the metrics, ramp up. Every change is instant. No redeploys, no flag drift.

30%

70% control

In treatment

14,46,000

Evals / min

5,04,000

Latency

2ms p99

A/B testing

Q3 2026

A built-in statistical engine, variant tracking, and metric integrations are on the way. Today: ship the slider on the left and bring your own analytics for measurement.

Variant tracking shared with the same SDKs you already use
Pluggable metric sources (Segment, Mixpanel, PostHog, custom)
Frequentist and Bayesian engines side-by-side
Auto-advance gradual rollouts that halt on a regression

04 / sdk

One line. Every
runtime.

Five SDKs that all evaluate flags the same way: JavaScript, Python, Go, Ruby, and an Edge Worker SDK. What your back-end returns matches what the edge serves. OpenFeature provider for JavaScript and the Edge Worker. REST API for anything else (reference docs in progress).

↪Flag checks evaluate in your runtime, with no per-check network call.

↪Live updates that only fetch when something actually changed.

↪Streams changes in under a second over SSE, with a 30-second safety poll when a stream drops.

// Local cache; in-process eval after first sync
import { FeatClient } from '@feathq/js-sdk'

const feat = new FeatClient({
  apiKey: process.env.FEAT_KEY!,
  dataPlaneUrl: 'https://data.feat.so',
})
await feat.ready()

const { value } = await feat.evaluate('new_checkout_v2', false, {
  targetingKey: user.id,
  user: { key: user.id, plan: 'pro' },
})

05 / safety

When it's on fire,
pull the lever.

Flip a flag off and connected SDKs get the change over the live stream in under a second. SDKs that poll instead catch it within 30 seconds. The audit log records who, what, and why.

Kill a feature globally.

Something on fire? Hit kill. The off state streams out in under a second. No rollback. No redeploy. No standup.

new_checkout_v2 · productionlive

change propagated · live everywhereidle

active sessions affected0

click the button to simulate an emergency kill

06 / control

Simple by default.
Advanced on demand.

Every governance feature is an org-level toggle. Start with kill-switch flags; turn on segments, individual targeting, approvals, and gradual rollouts when your team needs them. Disabled features disappear from the console.

Always on

Boolean, string, number, and JSON flags
Targeting rules
Percentage rollouts
Kill switch + archive
Audit history
API keys for every runtime

The basics every team gets, on every plan. No setup, no settings page.

Org-level toggles

Segments
Individual targeting
Change requests + approvals
Gradual rollouts

Flip on what your team is ready for. Disabled features vanish from the console, so it never grows past what you actually use.

07 / privacy

We can't see
your users.

The JavaScript, Go, Python, Ruby, and browser SDKs evaluate flags inside your runtime, so the attributes you target on (email, plan, anything) never reach our servers. Browser SDKs report identifier-and-kind pairs for MAU counting, hashed one-way at the edge before storage. The backend SDKs report nothing.

your runtime

context: { user: "u_1732",

email: "ana@acme.io",

plan: "pro" }

evaluate("checkout-v2")

→ true, locally, ~2 ms

Attributes stay here. There is no evaluate API to send them to.

feat's edge

stores for billing:

sha256("u_1732")

→ "353b4abb…" (one-way)

email, plan: never received

Browser SDKs report ID-and-kind pairs so we can count monthly active users; the edge hashes them before anything is stored. The JavaScript, Go, Python, and Ruby SDKs report nothing at all.

One exception, stated plainly: the Edge Worker SDK evaluates over an in-process binding inside feat's worker, so its context does pass through our code. We store only the hashed identifier-and-kind pairs, same as above.

08 / receipts

Numbers we
actually publish.

These numbers come from the SDK and data-plane code, not from a brainstorm.

0 ms

p99 local SDK eval latency, evaluated in your runtime.

0.0 %

Uptime SLA on Growth tier and above.

< 1 sec

For a saved change to reach connected SDKs over the live stream.

Free-tier monthly active users. Every plan has unlimited flags.

09 / check our work

Don't take our
word.

The claims on this page are checkable. Here's where a skeptic should look.

A dependency tree you can read at a glance.

The Go, Python, and Ruby SDKs are standard-library only. The JavaScript SDK adds feat's own engine and schema plus the OpenFeature packages behind its provider; nothing else. Releases publish to npm with provenance attestation via OIDC trusted publishing, so you can verify each artifact came from our CI, not a laptop.

see the provenance on npm →

The wire format is public.

The exact datafile your SDK consumes is a documented, versioned schema, published as @feathq/datafile-schema. Rollout bucketing is deterministic down to the hash recipe, which we published in full; port it yourself and your numbers should match ours exactly. Prefer vendor-neutral? OpenFeature providers ship for the server and browser SDKs.

read the bucketing recipe →

A paper trail on every plan.

The audit log is on for everyone, Free included. Changes made in one request group into one entry instead of thirty rows, comments can be required per environment, and API-key secrets are redacted before a record is ever written.

how the audit log works →

10 / pricing

Honest pricing.
No “contact us” tax.

Free forever for solo devs. A flat rate for teams, sized by monthly active users; seats never show up on the bill.

Free

$0 7,500 MAU 100 server connections

A real production tier: 7,500 MAU and unlimited flags, free forever.

Boolean, string, number & JSON flags
Attribute-based targeting
Percentage rollouts
Kill switch + archive
Live updates
100 server connections · no per-connection fees
Built-in roles
2FA + Google/GitHub OAuth Coming Q3 2026
30-day audit log
Community support
2 projects · unlimited envs · unlimited flags

Start free →

Starter

$19/mo $15/mo billed annually 25,000 MAU 250 server connections

A production-ready flag platform for under $20 a month.

Everything in Free, plus:
250 server connections
Failsafe delivery (multi-CDN failover) Coming Q3 2026
Segments (reusable targeting groups)
Stale-flag detection Coming Q3 2026
Required comments on changes
Webhooks Coming Q3 2026
CLI Coming Q3 2026
90-day audit log · email support (48h)

Start free →

Get back to
shipping.

Start for free → Talk to an engineer

Stop redeploying to flip a switch.