Feature flags, now in the admin console
Experimental capabilities used to require a config file edit and a redeploy. Now admins can flip them from the settings UI — safer rollouts, faster experiments.
Every instance we run has a small set of capabilities we're not quite ready to commit to. Sometimes it's a new export format we want two customers to try before we generalize it. Sometimes it's a rewrite of an internal path that's safe to enable everywhere except the one workspace with the weird ingest pipeline. Historically, gating those required an environment variable, a config reload, and someone with production access. That's a lot of ceremony for something that is, by definition, meant to change often.
So we moved feature flag management into the admin console. Manage Feature Flags (Admin)
Why a UI, and why now
The honest answer: the config-file approach was optimizing for the wrong reader. Flags exist because we want to change behavior without a deploy. The moment toggling one requires editing YAML and restarting a service, you've reintroduced the deploy — just a scarier, less-audited version of it. Every team we talked to had the same pattern: a flag would ship, sit at its default for months because flipping it felt risky, and eventually get hardcoded and forgotten.
Moving the surface into the admin settings page changes the economics. An admin who wants to try an experimental capability opens the Feature Flags page and flips it. If it goes wrong, they flip it back. The blast radius stays scoped to their instance, and the decision stays with the person who actually owns the instance's behavior.
What this unlocks
The near-term win is obvious: experimental capabilities we ship behind flags are now genuinely reachable. Manage Feature Flags (Admin) If we tell you a new capability is available under a flag, you can actually turn it on today, evaluate it against your data, and turn it off if it isn't a fit — no ticket, no redeploy, no coordination with us.
The longer-term win is that it changes how we ship. When flipping a flag is a two-click operation, we can ship more things behind flags. That means smaller, more frequent releases of in-progress work, earlier feedback from the handful of customers who care about a specific capability, and fewer big-bang launches where we guess at requirements and hope.
A few things worth naming explicitly. Flags are per-instance, so turning one on in your environment doesn't affect anyone else. Anything gated behind a flag is, by definition, still experimental — we may change its behavior, its API surface, or remove it entirely before it graduates. If a flag is stable enough that you'd be upset to lose it, tell us; that's usually the signal that it should stop being a flag and start being a feature.
What's next
We'll be moving several in-flight capabilities behind admin-visible flags over the next few releases, and the paired help-center article covers the mechanics of finding and toggling them. Expect the list on that page to grow — that's the point.