Skip to content
NanoFlags
Start free
SDK 0.4.0Signature checks on by defaultEd25519 signature checks on by default

Feature flags · Release safety

Ship the change.Prove what shipped.

NanoFlags adds drafts, independent approvals and scenario checks to every flag change, then delivers it as a signed bundle to your SDKs in about 0.2 seconds. Evaluation runs locally in your app, so a network blip never becomes an outage.

Start freeRead the quickstartnpm i @nanoflags/sdk

Explore plan $0Apache-2.0 SDKOpenFeature provider

Live proof: p50 222 ms · p95 325 mscommit → SDK, last 24 hEd25519-signed bundlesApache-2.0 SDKSee live latency

DraftTestedr184Publishedr183ObservedCoverageincomplete
tracecheckout-v225% → 50%publish r184 · production
Database commit to SDK listener, by probe region, last 24 hours
Probe regionp50 (ms)p95 (ms)
KIX Osaka189279
MEL Melbourne194281
LHR London229317
ATL Atlanta253340
DEN Denver255341
Measured by synthetic probes, last 24 h, 1,418 samples. Flag name and revision are illustrative; timings are the real 24-hour aggregates.Live numbers and methodology
  • p50 commit → SDK 222 ms
  • p95 325 ms
  • KIXOsaka189 ms
  • MELMelbourne194 ms
  • LHRLondon229 ms
  • ATLAtlanta253 ms
  • DENDenver255 ms
  • 1,418 samples · last 24 h
  • Ed25519-signed bundles
  • Pushed over WebSockets
  • Evaluated locally in your app
  • Apache-2.0 SDK
  • OpenFeature provider
  • Public status page

Why NanoFlags

What makes NanoFlags different.

Four things built into every flag change. Each one is enforced by the product or measured in public, and each links to the page that shows how.

  1. scenario checks

    Changes are tested before they publish.

    A scenario check is the value you expect a flag to return for a given context. Where checks are required, a single failure blocks the publish.

    scenarios · checkout-v2illustrative
    • EU signed-in users get v2pass
    • Signed-out visitors keep v1pass
    • Internal staff always see itpass
    • US customers stay outfail
    Publish blocked · 1 failing
  2. independent approval

    Every change is reviewed independently.

    The author and anyone who edited the draft can't approve it. An approval is tied to the exact draft and goes stale if the draft changes.

    rollout 25% → 50%draft 9f3c1aillustrative
    • mayaauthorcan't approve
    • samedited the draftcan't approve
    • leereviewerapproved

    Bound to this exact draft. Any edit makes it stale.

  3. ed25519 · on by default

    Every bundle is signed, and the SDK verifies it.

    Ed25519 signatures, checked by the SDK by default. A tampered or unsigned config is rejected, and your app keeps its last good config.

    signature valid// bundle r184 · production · illustrative{ "revision": 184,"flags": { "checkout-v2": { "rollout": 50 } },"kid": "k2","sig": "9f3c…e1a0" }
  4. measured live

    Delivery speed is measured live and published.

    Synthetic probes time each publish from database commit to SDK every 5 minutes. The results and the method are public.

    222ms

    p50 by probe region · last 24 h

    • KIX Osaka189 ms
    • MEL Melbourne194 ms
    • LHR London229 ms
    • ATL Atlanta253 ms
    • DEN Denver255 ms

    p50 · commit → SDK · last 24 hp95 325 ms · 1,418 samples

Required approvals and scenario checks are part of Team and Scale. On those plans, every new Production environment starts with both turned on.

Live demo · real edge

Flip a real flag. Watch it land.

This is a public NanoFlags environment. Press the switch: the change is published, signed and pushed to the SDK running in this tab, and to every other visitor on this page.

Connecting to the edge…Revision —

Flag

Public demo · Live demo environment

New checkout

demo-new-checkout

Accent colour demo-accent

Your browser

A demo storefront evaluating flags locally with @nanoflags/sdk

Trail Runner 2

Lightweight running shoe

$129

Continue to checkout

Step 1 of 3 · Shipping address

Anything you publish here is visible to every visitor. Resets to the default every 15 minutes.

Want this in your own app? Start free — no card

One change, end to end

From draft to every SDK, with nothing skipped.

Every flag change follows the same path as a code change. Each step leaves an artefact you can point to.

  1. Draft

    Edit targeting, values or rollout. Nothing reaches users until it's published.

    draft · checkout-v2

  2. Test

    Scenario checks run saved contexts against the draft and compare them with the expected results. A failing check blocks publishing.

    12 / 12 passed

  3. Approve

    A teammate reviews the diff. Authors and editors can't approve their own change.

    approved · not an author

  4. Publish & sign

    The change becomes an immutable revision, signed with Ed25519 and pushed over live connections.

    r184 · kid k2

  5. Verify

    SDKs check the signature, swap in the new config, and report which revision they loaded. Gaps stay visible as “unknown”.

    signature valid

Roll back by restoring any earlier revision. Every step is in the audit log.

Delivery

Evaluated in your app. Zero network calls per flag.

Published changes travel over WebSockets on Cloudflare's network and arrive in SDKs in about a fifth of a second. Your app evaluates flags locally, so a slow network never slows a request, and a lost connection leaves the last verified config running.

  1. Publish

    postgres commit

  2. Sign

    Ed25519

  3. Edge

    WebSocket push

  4. SDK

    verify → evaluate

One hop from commit to SDK. Live timings are on the speed page.
  • Local evaluation in the Browser and Node.js SDKs, React and OpenFeature JS/TS
  • ready() never rejects; an explicit stale status tells you when the config isn't confirmed current
  • The same deterministic engine on edge, SDK, CLI and CI: a scenario that passes in CI gives the same result in production
Live numbers and methodology
import { createClient } from "@nanoflags/sdk";

const flags = createClient({
  sdkKey: process.env.NANOFLAGS_SDK_KEY!,
  baseUrl: "https://edge.nanoflags.io",
  service: "checkout-api",
});

await flags.ready(); // never rejects
const on = flags.boolean("checkout-v2", false, { key: user.id, region: "EU" });
// Evaluated locally. Falls back to false only if no config has ever loaded.

Trust, but verify

Don't trust us. Check.

Run the bucketing engine in your browser, see exactly what a browser key receives, and read the account controls. The public signing keys are at /v1/keys.

MurmurHash3

Same user, same bucket, everywhere

One engine runs at the edge, in the SDK, in the CLI and in CI. Type any user key: the result is computed in your browser with the same code.

hash("checkout-v2", "user_1") → 40.61 < 50 ✓ · rollout 50%

browser keys

Client keys get client flags

A browser key receives only client-exposed flags and the segments they use. Server rules stay on your servers.

server keycheckout-v2internal-pricingseg: enterprise
browser keycheckout-v2internal-pricing (not sent)seg: enterprise (not sent)
accounts & data

Account and data controls, written down

  • two-step sign-in

    TOTP

    MFA with recovery codes; enforce it for admins

  • tenant isolation

    RLS

    Row-level security on every table, checked by an automated cross-organization isolation suite

  • backup interval

    1 h

    Hourly backups and a public status page with incidents

  • key revocation

    ≈1 min

    A revoked key is refused at the edge within about a minute

Read the security details

No lock-in

Built so you can leave.

The parts that run in your code are open source, and your data is always yours to take.

  • LICENSEApache-2.0

    • @nanoflags/sdk
    • @nanoflags/engine
    • @nanoflags/cli
    • @nanoflags/openfeature-provider

    Open-source client

    The SDK, evaluation engine, CLI and GitHub Action are Apache-2.0. Read every line that runs in your app.

    SDK on GitHub
    1. Your code
    2. OpenFeature API
    3. NanoFlags provider
    4. Local evaluation

    OpenFeature provider

    Write your flag calls against the OpenFeature standard API; NanoFlags evaluates them locally underneath.

    OpenFeature guide
  • project.jsonexported
    • flags
    • segments
    • environments
    • drafts
    • scenarios
    • bundles

    Export everything

    Download a whole project (flags, segments, environments, drafts, scenarios and published bundles) as one JSON file from the dashboard, or run nanoflags export in CI.

    CLI reference

If we're unreachable, your app keeps serving the last config it verified. You stay in control.

In your workflow

Flags in your pull requests and your CI.

Install the CLI

npm i -g @nanoflags/cli

A PR comment with the flag states a change touches, code references, and a “NanoFlags scenarios” check.

Pull request #482acme/webillustrative

nanoflags[bot] commented

Flags read in this pull request

flagStagingProduction
checkout-v2on · 50% · r212on · 25% · r184draft differs
new-pricing-pageoff · r212off · r184

NanoFlags scenarios — success

Pricing

Flat prices. Evaluations are never billed.

Start free on one project. Prices are public, limits never block your apps from reading flags, and there's a 14-day refund.

  • Explore

    $0

    Try the full workflow on one project.

  • Team

    $149/mo

    Required reviews and scenario checks for production.

  • Scale

    $499/mo

    Several products, unlimited members, audit export.

  • Enterprise

    Custom

    Security review, custom limits and contract terms.

See pricing

Who you're trusting

A new company, in the open.

NanoFlags launched in 2026. We don't have customer logos to show you yet, and we won't invent them. What we can give you is everything you need to check us: live performance data, open-source code, a public security page and our registered company details.

Company
NanoFlags is a product of Intinovate, Riyadh, Saudi Arabia. Registered company details
Payments
Paddle is our merchant of record: it handles invoices and tax in your country.
Support
support@nanoflags.io · docs in English and Arabic.
Incidents
Incidents and maintenance are posted publicly on the status page. Status

FAQ

Questions engineers ask first.

Full list of subprocessors and controls
What happens if NanoFlags is down?
Your SDKs keep evaluating the last config they verified. You can't publish new changes until we're back; your users aren't affected.
Where is our data stored?
Account data and configuration are stored in Supabase (Mumbai) and delivered through Cloudflare's global network. Your users' attributes are evaluated in your app and aren't sent to us to make decisions.
Can we export everything?
Yes. Export your project as JSON at any time. The SDK is Apache-2.0 and there's an OpenFeature provider.
Will the bill grow with our traffic?
No. Evaluations are local and never billed. Plans are flat monthly or annual prices, and hitting a limit never stops your apps reading flags.
Do you have SOC 2?
Not yet. Our security page lists exactly what we do today; Enterprise includes a security review.

Make your next flag change a reviewed one.

Free for one project. No per-evaluation billing. Export any time.