Feature flags exist so a bad deploy becomes a config change instead of an incident. That part hasn't changed. What has changed is the bill: LaunchDarkly shipped AgentControl on May 19, 2026, a runtime layer that reconfigures an AI agent's behavior in under 200ms without a redeploy, and quietly dropped per-seat pricing in the process. The current plan meters two things instead: service connections and client-side monthly active users.
I wrote up the full breakdown, with every number pulled from the live pricing pages, on DevToolLab. Here's the short version, plus a demo proving the "avoid lock-in" pitch for the open standard underneath all of this actually holds up.
What changed and why it matters
LaunchDarkly's free Developer tier is still generous: unlimited seats and flags, 5 service connections, 1,000 MAU, 5,000 AI runs, 14-day retention, no card required. The paid Foundation tier is where the new shape shows: $10 per service connection a month plus $8.33 per 1,000 client-side MAU, no seat fee at all. Per Vendr's marketplace data, the median contract still lands between $63,960 and $72,000 a year.
None of that is unreasonable for what the platform does. But if you're not using agent orchestration, you're paying enterprise rates for flag delivery alone, and that's exactly the gap three open source projects have been eating for years.
The three ways out
Switch vendors. Unleash, GrowthBook, and Flagsmith each sell a hosted plan, priced on very different terms than LaunchDarkly. All three matter more for what comes next.
Self-host. Each of those three also ships a real, free, open source edition, not a crippled trial. The cost becomes a small VPS instead of a connection meter.
Stop caring which vendor you're on. OpenFeature is a CNCF specification, not a product. Your code calls one vendor-neutral API; the provider underneath becomes a config line instead of an architecture decision.
The three self-hosted options, briefly
Unleash is AGPL-3.0, sits around 13,800 GitHub stars, and self-hosting is one docker compose up -d away. The catch: choosing self-hosted under its Pay-As-You-Go cloud plan carries a 5-seat minimum, and the license means modifications you distribute as a service need to stay open.
GrowthBook licenses most of the repo MIT, with a handful of enterprise directories carved out under a separate license, the exact same shape as several other "open core" tools in this space. Free self-hosting has no user cap, just a one-project ceiling. It also does warehouse-native experimentation, not just flags, which the other two don't.
Flagsmith is BSD-3-Clause and, unusually, publishes no request ceiling at all on self-hosted deployments. Its hosted free tier is a real but small 50,000 requests a month for one seat.
Proving OpenFeature actually avoids lock-in
The claim is easy to make and worth testing instead of trusting. Here's business logic that only imports the OpenFeature client, never a vendor SDK:
import { OpenFeature } from "@openfeature/server-sdk"
export async function renderCheckoutButton(userId) {
const client = OpenFeature.getClient()
const enabled = await client.getBooleanValue("new-checkout-flow", false, {
targetingKey: userId,
})
return enabled ? "new checkout" : "classic checkout"
}
Now swap the provider underneath it, twice, using the SDK's built-in in-memory provider as a stand-in for a real vendor plugin:
import { OpenFeature, InMemoryProvider } from "@openfeature/server-sdk"
import { renderCheckoutButton } from "./checkout.mjs"
await OpenFeature.setProviderAndWait(new InMemoryProvider({
"new-checkout-flow": { variants: { on: true, off: false }, disabled: false, defaultVariant: "off" },
}))
console.log(await renderCheckoutButton("user-1")) // "classic checkout"
await OpenFeature.setProviderAndWait(new InMemoryProvider({
"new-checkout-flow": { variants: { on: true, off: false }, disabled: false, defaultVariant: "on" },
}))
console.log(await renderCheckoutButton("user-1")) // "new checkout"
I ran this with @openfeature/server-sdk 1.23.0 before publishing, and the output matches the comments exactly. checkout.mjs never changes between the two runs. Swapping a real vendor's provider in production is the same operation: change what you pass to setProvider, not what your application calls.
The part that breaks during migration
Config vars and builds port cleanly between any of these platforms. What doesn't is percentage rollout math: LaunchDarkly, Unleash, and GrowthBook each hash users into targeting buckets differently, so a 10% rollout on one system is not the same 10% of users on another. Verify parity before you cut traffic over, and keep the old vendor running for a full billing cycle after the new one goes live, so a rollback is a config change and not an emergency.
The full article on DevToolLab also covers GrowthBook's exact license split, the complete pricing comparison table, and a step-by-step migration checklist.
Related DevToolLab tools
If you're standing up a self-hosted flag server, two tools are worth bookmarking: an .env file generator for scaffolding the environment variables Unleash, GrowthBook or Flagsmith need before your first docker compose up, and a webhook signature verifier for checking the HMAC on incoming flag-change webhooks before you trust the payload.
Top comments (0)