LaunchDarkly pricing: how are Service Connections and client-side MAU calculated for billing?

Most teams don’t get surprised by LaunchDarkly’s feature set—but they do sometimes get surprised by how usage is measured. The good news: Service Connections and client-side MAU are both predictable once you understand what’s counted, where, and when.

Quick Answer: LaunchDarkly bills server-side usage using Service Connections (how many backend services/environments connect to LaunchDarkly) and client-facing usage using client-side MAU (how many unique client-side entities encounter flags in a month). Both are usage-based, tied directly to how you wire LaunchDarkly into your architecture.

The Quick Overview

What It Is: A usage-based pricing model where backend usage is measured as Service Connections and frontend/app usage is measured as client-side MAU (monthly active users).
Who It Is For: Engineering, product, and platform teams using LaunchDarkly for feature flags, experimentation, and runtime control across web, mobile, and backend services.
Core Problem Solved: You pay in proportion to how broadly LaunchDarkly is connected to your stack and how many real users/devices encounter flags—no guessing based on opaque tiers.

How It Works

LaunchDarkly pricing combines plan-based access to features (for example, Foundation, Pro, Enterprise) with metered usage based on:

Service Connections (server-side SDKs)
Client-side MAU (client-side SDKs)
Optionally, Experimentation MAU if you’re running experiments at scale

The key is understanding how each is defined and how it’s counted over time. Once you map those definitions to your architecture (microservices, environments, frontends, devices), you can pretty accurately forecast your bill.

1. How Service Connections are calculated

Definition (billing-grade):
A Service Connection is one instance of one server-side SDK connected to one LaunchDarkly environment, measured over time in minutes. Practically, it represents a backend microservice or replica that’s actively connected to LaunchDarkly’s streaming endpoints.

You’ll also see Service Connections described as:

“The number of microservices, replicas, and environments connected to LaunchDarkly for 1 month.”

Those two definitions are describing the same thing from different angles:

Server-side only:
Only server-side SDKs count toward Service Connections. Client-side SDKs (web, mobile, desktop) do not.
Per environment:
A service connecting to production and staging is two Service Connections (per replica).
Per instance/replica:
If you scale a microservice to 10 replicas in one environment, that’s roughly 10 Service Connections for that environment, while they’re connected.
Time-based measurement:
LaunchDarkly measures connections in minutes and then aggregates usage for the month. If you scale up and down during the day, your Service Connections reflect that dynamic usage, not your peak count 24/7.

Concrete examples of Service Connections

Example 1: Simple monolith
- 1 backend service
- 2 environments: staging, prod
- 3 replicas in each environment (e.g., Kubernetes Pods)
- Service Connections: 1 service × 2 envs × 3 replicas = 6 Service Connections
Example 2: Microservices architecture
- 5 microservices using server-side SDKs
- 3 environments: dev, staging, prod
- Average of 4 replicas per service per environment
- Service Connections: 5 × 3 × 4 = 60 Service Connections
Example 3: Autoscaling
- A service runs:
  - 2 replicas at night
  - 10 replicas during peak hours
- The Service Connection usage is time-weighted:
  - Fewer Service Connections counted during low-traffic periods
  - More during peak, when additional replicas are connected

How Service Connections show up in billing

On LaunchDarkly’s Foundation plan, you’ll see pricing like:

$12/month per Service Connection (billed monthly or annually)
You commit to a certain number of Service Connections each month.
If you exceed that commitment, additional usage is billed the following month based on your actual overage.

This is why it’s important to size your commitment with realistic assumptions about:

Number of server-side services using LaunchDarkly
Number of environments wired up
Typical replica counts and autoscaling behavior

2. How client-side MAU is calculated

Definition (billing-grade):
Client-side MAU are the client-side users, devices, organizations, or other defined entities that encounter feature flags in your product in 1 month.

Key points:

Client-side only:
This metric covers client-side SDKs—for example:
- Web JavaScript (browser)
- Mobile SDKs (iOS, Android)
- Desktop/thick clients
“Encounter feature flags” means the client-side context is used in a flag evaluation. If a user or device never hits code that evaluates a flag via the client-side SDK, they won’t count.

What counts as a “user” for MAU?

LaunchDarkly is flexible: the entity doesn’t have to be literally a “user.” It can be any context you define as the primary client-side identity, such as:

A human user (e.g., userId)
A device (e.g., deviceId)
An organization/account (e.g., accountKey)
A workspace or team

As long as that context:

Is created on the client side, and
Encounters at least one feature flag evaluation in a given month,

…it will count once toward that month’s client-side MAU total.

How client-side MAU are billed

From the pricing details:

$10/month per 1,000 client-side MAU

A few things to note:

You pay in blocks of 1,000 MAU (often written as “per 1k”).
A MAU is unique per month, not per session or per request.
The same user hitting your app 200 times in a month still counts as 1 MAU (as long as the identity is consistent).

Examples of MAU counting

Example 1: Single web app
- 50,000 unique logged-in users who see flags each month
- Consistent userId across sessions
- Client-side MAU: 50,000
- Billing: 50 × $10 = $500/month for client-side MAU
Example 2: Mobile app with devices as identity
- 80,000 active devices per month that encounter flags
- Using a deviceId as the primary context key
- Client-side MAU: 80,000
- Billing: 80 × $10 = $800/month
Example 3: Multi-tenant SaaS using organizations
- 3,000 active organizations per month with feature flags evaluated client-side
- Each org is the primary context
- Client-side MAU: 3,000
- Billing: 3 × $10 = $30/month

3. Experimentation MAU (when applicable)

If you’re using LaunchDarkly’s experimentation capabilities at scale, you may also see:

Experimentation MAU:
The number of users available to be targeted in experiments each month.

From the pricing context:

$3/month per 1,000 Experimentation MAU

This is a separate meter from client-side MAU. Not every client-side user has to be in experiments; only those eligible as experiment participants count toward Experimentation MAU.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Service Connections	Measures server-side SDK connections per service × environment × instance	Aligns cost with how broadly LaunchDarkly is wired into your backend
Client-side MAU	Counts unique client-side entities that encounter feature flags monthly	Ties cost directly to real user/device reach
Experimentation MAU	Counts users eligible for experiments each month	Lets you scale experimentation without overpaying for non-participants
Annual billing discount	Applies an automatic discount for annual contracts	Lowers effective per-unit cost for committed usage

Ideal Use Cases

Best for teams with many backend services:
Because Service Connections map neatly to microservices, replicas, and environments, platform teams can forecast usage based on real infrastructure, not rough guesses.
Best for product-led, user-facing apps:
Because client-side MAU is tied to actual users/devices that see flags, product teams can control cost by deciding exactly where to load the client-side SDK and evaluate flags.

Limitations & Considerations

Anonymous contexts can inflate MAU:
If you configure LaunchDarkly to use anonymous contexts on the client side (for example, for logged-out users or unregistered visitors), you may see higher MAU numbers. You can mitigate this by:
- Consolidating identities when a user logs in
- Managing stored contexts and retention
- Working with your LaunchDarkly representative to tune your approach
Environment and replica sprawl increases Service Connections:
Every additional environment (e.g., multiple staging variants) and every replica counts. If you run many environments or very high replica counts, you may want to:
- Limit which environments connect LaunchDarkly for production-grade flagging
- Use flags selectively in ephemeral or short-lived environments
- Right-size your Service Connection commitment with your LaunchDarkly rep

Pricing & Plans

LaunchDarkly offers plan tiers (for example, Foundation for growing teams) plus usage-based meters.

From the Foundation pricing snapshot:

$12/month per Service Connection
- “Service connections are the number of microservices, replicas, and environments connected to LaunchDarkly for 1 month.”
$10/month per 1,000 client-side MAU
- “Client-side MAU are the client-side users, devices, organizations, or other defined entity that encounter feature flags in your product in 1 month.”
$3/month per 1,000 Experimentation MAU (when experimentation is enabled)
- “The number of users available to be targeted in experiments each month.”

There is also an automatic discount on all plans set up with annual billing, so if you know your usage band, annual can be more cost-efficient.

Typical packaging patterns:

Foundation (usage-based):
Best for growing teams that want full-featured feature management and experimentation, with pricing that scales as more services and users adopt flags.
Custom/Enterprise:
Best for large engineering organizations needing:
- Higher Service Connection and MAU commitments
- Enterprise governance (custom roles, policies, approvals, audit logs)
- Contracted SLAs and tailored pricing

Exact plan details and volume discounts will depend on your contract; you’ll finalize those with the LaunchDarkly sales team.

Frequently Asked Questions

Do I pay for all users in my product, or only those that hit LaunchDarkly flags?

Short Answer: You pay for client-side MAU that encounter feature flags, not for every possible user in your database.

Details:
A user (or device, or org) only counts as a client-side MAU if:

They’re represented as a context in the client-side SDK, and
They trigger at least one feature flag evaluation in a given month.

If some parts of your app never touch LaunchDarkly, users who only live in those paths won’t be counted as MAU. This is why many teams strategically load the client-side SDK only on pages or surfaces where flags are needed.

If I scale my microservices up and down, will my Service Connections spike my bill?

Short Answer: Service Connections are time-based, so autoscaling is accounted for, but higher peak and longer-running replicas will increase usage.

Details:
Service Connections are measured as instances of server-side SDKs connected to an environment over time (in minutes). If your service runs 2 replicas for half the day and 10 replicas during peak hours, your monthly Service Connection usage will reflect that pattern. You’re not billed based on your absolute maximum count at any single point; you’re billed on aggregate usage across the month. For predictable workloads, your LaunchDarkly representative can help you size a commitment that fits your typical traffic and scaling behavior.

Summary

Service Connections and client-side MAU are designed to mirror how you actually use LaunchDarkly in production:

Service Connections track how many backend services, replicas, and environments are wired into LaunchDarkly via server-side SDKs.
Client-side MAU track how many unique client-side entities (users, devices, orgs) actually encounter feature flags each month.
Experimentation MAU (when applicable) focuses specifically on users available to be targeted in experiments.

Tie those metrics to your architecture, and LaunchDarkly’s pricing becomes predictable: the more of your stack you bring under runtime control, and the more users you serve flags to, the more you’ll use—and pay for—LaunchDarkly.

Next Step

Get Started