HN Showcase
Back to browse
I built a feature flag service that's just a static JSON on a CDN

I built a feature flag service that's just a static JSON on a CDN

by IP14·Jul 17, 2026·2 points·0 comments
Visit ProjectView on HN

AI Analysis

●●●BangerBig BrainSlick

Static JSON on Cloudflare edge beats LaunchDarkly's round-trip latency for flag checks.

Strengths
  • •Evaluation happens in-process; flags keep working even if Switchbox servers go down.
  • •OpenFeature compatibility means switching providers requires changing one constructor line.
  • •Visual before/after audit diffs and in-app Playground for rule debugging are genuinely useful.
Weaknesses
  • •30-second propagation delay rules out instant kill switches for critical incidents.
  • •No built-in analytics; you must wire up your own event tracking for experiments.
Target Audience

Backend engineers, DevOps teams, startup CTOs

Similar To

LaunchDarkly · Flagsmith · Unleash

Post Description

Hi HN, I’m Ignat and I built Switchbox, a feature flags management platform that serves the configs as a static JSON file on a CDN.

That’s pretty much it. The whole flow is like this:

- The user sets the feature configs in the UI dashboard

- They set the SDK inside their code and use the flags to guide their features.

- The SDK polls the configs from the CDN every ~30 seconds and caches the values

- The user’s code gets almost no lag for the flag evaluation since it’s happening in-process and there are no external calls for it.

The architecture itself allows for my servers to stay with really low traffic and yet the configs will be available with really insignificant lag added to the user’s apps.

This is not a new idea, but not many vendors go for it since it has some tradeoffs, which are important:

- The flag updates need around 30s to go from the dashboard to the actual app. This is ok for most apps, but some critical ones might want an instant kill switch.

- Advanced analytics inside the dashboard are not possible. The evaluation never reaches my servers so I can’t know anything about them. This is good for security, but it limits the possibility for any advanced analytics. The only thing I can track is if the SDK is active based on the fact that it’s polling every 30s.

- The config is readable by anyone with that environment's SDK key, so flag names and rules shouldn't contain anything secret.

This fits feature flags well since flags are defined and updated pretty rarely compared to how many times they are evaluated.

I’d love to hear what you think about this. There is for sure some aspect that I’m missing and might bite me later on.

Similar Projects