LaunchDarkly pricing: plans, billing units, and what actually drives the bill

LaunchDarkly's published plans

LaunchDarkly publishes three plans. Two carry public numbers and one does not. The figures below were read from launchdarkly.com/pricing on 8 September 2026. Vendor packaging changes, so treat this as a starting point and confirm against the current page and your own quote.

The single most important thing to understand is that LaunchDarkly does not price its core feature-management product per seat. Seats are unlimited on the free plan, and the paid meters are service connections and client-side monthly active users. Many third-party comparisons still describe a per-seat model, which is why teams arrive at forecasts that are wrong by an order of magnitude in either direction.

The two units you are actually billed on

LaunchDarkly's billing documentation defines both meters precisely. Reading them carefully is the difference between a forecast that holds and one that doubles in the first quarter.

A service connection is defined as "one instance of one server-side SDK connected to one LaunchDarkly environment for a time period measured in minutes". Read that as instances, not services. Six replicas of one service talking to three environments is eighteen service connections, not one and not three.

Client-side MAU is defined as "the number of unique monthly active contexts, typically user contexts, evaluated by LaunchDarkly client-side, AI, and edge SDKs", calculated as "the total number of unique context keys evaluated in a month". The documentation is explicit that changing a context key produces an additional MAU. Anonymous or per-device keys, key rotation on logout, and per-session identifiers all inflate this number without adding a single real user.

Two worked estimates using the published rates

Neither figure below is a quote. Both are arithmetic on LaunchDarkly's own published Foundation rates, shown so you can substitute your numbers.

Case one, a server-heavy B2B application. Six server-side SDK instances in each of production, staging, and development gives 18 concurrent service connections. Foundation includes the first five, so 13 are billable at $10 each, or $130 per month. Flag evaluation happens server-side, so client-side MAU is near zero. The estimated bill is about $130 per month, or roughly $1,560 a year.

Case two, the same application with a consumer-facing web and mobile client. Add 250,000 unique context keys evaluated by client-side SDKs each month. At $8.33 per 1,000 client-side MAU that is 250 times $8.33, or $2,082.50 per month, on top of the $130 in service connections. The estimated bill is about $2,212.50 per month, or roughly $26,550 a year.

The gap between those two cases is entirely architectural. Nothing about the number of flags, the size of the team, or the sophistication of the rollout changed. If your bill surprises you, the cause is usually one of three things: replica count multiplied by environment count, anonymous context keys counted as distinct users, or a client-side SDK adopted for convenience where a server-side evaluation would have done.

• Count SDK instances at peak autoscale, not at steady state. The meter is measured in minutes.
• Multiply instance count by the number of environments each instance connects to.
• Check whether your client SDK sets a stable context key per user or a fresh key per session.
• Separate anonymous traffic from signed-in traffic before estimating client-side MAU.
• Ask whether an evaluation genuinely needs to happen in the browser or on the device.

What the free plan does and does not cover

The Developer plan is unusually generous on the dimensions most vendors restrict and tight on the ones that matter at scale. Seats are unlimited. Feature flags are unlimited. That removes the two most common reasons a team outgrows a free tier elsewhere.

The binding constraints are 5 service connections and 1,000 client-side MAU per month. A single service running across three environments with a couple of replicas each will pass five service connections quickly. Any consumer-facing product passes 1,000 client-side MAU in a day.

This makes the free plan a genuine fit for internal tools, back-office systems, and early server-side products, and a very short runway for anything with public users.

Overage behaviour and billing timing

LaunchDarkly's documentation states that "We never stop or throttle service if you exceed your MAU limit. All contexts will continue to receive feature flags correctly, regardless of the amount of your MAU." That is good for reliability, and it means the meter cannot protect you from itself.

For self-serve plans, the documentation describes billing "at the beginning of each month for any usage exceeding your entitlements from the prior month", with email notifications sent during the month as the overage balance crosses various dollar amounts. In practice you learn about an architectural change on the invoice, one month late.

If you are moving to a pay-as-you-go plan, put a monthly check on service connection count and unique context keys into the same review that already covers cloud spend. The number that changes your bill is a deployment topology number, and deployment topology changes without anyone thinking about the flag vendor.

• Set an internal alert on service connection count, not just on the invoice total.
• Record the replica and environment count you quoted, so a later increase is traceable.
• Ask sales in writing how autoscaling peaks are treated within a billing period.
• Ask whether context keys from bot and synthetic traffic are excluded from MAU.
• Confirm what happens to the rate when an annual commitment is exceeded mid-term.

The questions to settle before the quote conversation

Enterprise pricing is not published, which means the vendor will size the contract from numbers you provide. Arriving with those numbers already measured is most of the negotiation.

Separately, before you buy more platform, check whether the problem you are solving is a delivery problem at all. Teams frequently escalate their feature-management contract when the actual blocker is that nobody can say which customers depend on which flag, or what revenue is attached to a flag nobody dares remove. That is a governance question, and a larger runtime subscription does not answer it.

• Peak service connection count by environment, measured over a full month.
• Unique context keys per month, split into signed-in, anonymous, and synthetic.
• Which flags are permanent entitlements rather than temporary release toggles.
• How many flags are still live only because their customer dependency is unknown.
• Whether the Guardian add-on, experimentation, or AI runs are genuinely required in year one.
• What the renewal rate is if your MAU grows by the amount your own forecast expects.

Sources and further reading

• Pricing plans and published rates, LaunchDarkly ↗
• Calculating billing, service connection and MAU definitions, LaunchDarkly documentation ↗
• LaunchDarkly subscriptions and plans, LaunchDarkly documentation ↗