Introduction

What Switchbox is, how it's delivered, and when to use it.

Switchbox is a feature flag service with an unusual delivery model: your flag configuration is published as a static JSON file on a CDN, and our SDKs read it directly from the edge. There is no API server in the read path. Your app fetches a small file from Cloudflare, caches it, and evaluates every flag locally, in-process, in under a millisecond.

That one design choice is the whole product:

  • Your app never waits on us. Flag checks are a local lookup against a cached config — no network call per evaluation, no added request latency.
  • If we're down, you keep working. The SDK serves the last config it fetched. There is no hard dependency on a live API.
  • It scales like a CDN, because it is one. Reads are static-file GETs on Cloudflare's edge, not database queries.

When to use Switchbox

Switchbox fits the common cases that feature flags are built for:

  • Ship dark, release later — deploy code with a feature flagged off, flip it on when you're ready.
  • Gradual rollouts — release to 5% of users, watch your metrics, then ramp.
  • Targeting — turn a feature on for a plan, a country, an internal team, or any attribute you pass in.
  • Kill switches — toggle a misbehaving feature off from the dashboard without a deploy.

It is hosted-only — there's no self-hosting story. You manage flags in the dashboard; your app reads them through one of the SDKs.

The two halves

There are two surfaces to learn, and they're small:

  1. The dashboard (switchbox.dev) — where you create projects, environments, and flags, set targeting rules and rollouts, and rotate SDK keys. This is the only place flags are written.
  2. The SDKs — Python, JavaScript, and React. These read the published config and evaluate flags in your app. They share one evaluation engine, so a given user gets the same result in every language.

Next steps

  • Quickstart — go from signup to a live flag in under five minutes. Start here.
  • How it works — the CDN read path, local evaluation, and polling, explained.
  • SDK reference — every method, option, and behaviour for each SDK.