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

Most teams care about two things with LaunchDarkly pricing: how it scales with your architecture, and how it scales with your users. That’s exactly what Service Connections and client-side MAU are designed to capture—so you pay for real usage, not guesswork.

Quick Answer: Service Connections measure your server-side SDK footprint (microservices, replicas, environments) over time. Client-side MAU measures how many unique client-side entities (users, devices, orgs, etc.) encounter feature flags in a month. Both are usage-based inputs into LaunchDarkly billing.

---

The Quick Overview

• What It Is:
  A usage-based pricing model built on two main units:

  • Service Connections for server-side feature delivery.
  • Client-side MAU for flags evaluated in browsers, mobile apps, and other client environments.

• Who It Is For:
  Engineering, product, and platform teams who need predictable, scalable pricing for feature flags, experimentation, and AI control—across microservices and millions of users.

• Core Problem Solved:
  Aligning cost with actual runtime usage: how many services are connected and how many client entities are seeing flags, instead of flat per-seat or coarse environment-based pricing.

---

How Service Connections Work

Service Connections tie pricing directly to how your server-side architecture uses LaunchDarkly.

Definition in billing terms

A Service Connection is:

One instance of one server-side SDK connected to one LaunchDarkly environment, measured over time in minutes, and aggregated over a month.

In practice, LaunchDarkly also explains this as:

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

Only server-side SDKs count toward Service Connections. Client-side SDKs (e.g., JavaScript in-browser, mobile, desktop clients) are covered under client-side MAU instead.

How it maps to your architecture

Here’s how typical setups translate into Service Connections:

1. Microservices x environments

   • 5 server-side services (for example: auth, payments, catalog, search, notifications).
   • 3 LaunchDarkly environments (dev, staging, prod).
   • Each service runs one instance per environment.
   • Service Connections: 5 services × 3 environments = 15 Service Connections.

2. Replicas and autoscaling
   You might run multiple replicas of the same service in the same environment:

   • Payments service in prod with 10 pods (replicas) and one LaunchDarkly SDK instance per pod.
   • Each pod’s SDK connection counts.
   • If those 10 pods run steadily all month, you’re effectively using 10 Service Connections for that service/environment combination.

3. Short-lived / bursty workloads
   Usage is actually measured in minutes, then rolled up:

   • A job spins up 100 replicas for 30 minutes per day with the server-side SDK.
   • Even though the peak is 100 connections, the billed Service Connections reflect the time-weighted usage over the month.
   • Your LaunchDarkly rep can help you model this if you have heavy autoscaling.

How billing works with Service Connections

• When you subscribe to a LaunchDarkly plan, you:
  • Commit to a certain number of Service Connections per month.
  • Are billed monthly for that committed baseline.
• If you exceed your committed amount:
  • LaunchDarkly bills overages at the start of the next month for the additional Service Connection usage.
• Current list price reference (from public docs, subject to change):
  • $12 per Service Connection / month (Foundation plan example).

Because Service Connections log usage at the SDK-connection level, you can shape cost by:

• Reducing redundant SDK instances.
• Standardizing how many environments you connect each service to.
• Planning autoscaling behavior for long-running vs. bursty workloads.

---

How Client-side MAU Works

On the client side, pricing focuses on who actually encounters your flags, not how many SDK instances exist.

Definition in billing terms

Client-side MAU (Monthly Active Users) are:

The client-side users, devices, organizations, or other defined entities that encounter feature flags in your product in 1 month.

Key points:

• It’s about unique entities per month, not total flag evaluations.
• “Entity” is flexible: you decide whether a MAU is a user, a device, an organization, or another identifier you pass to the client-side SDK.

What counts as “encountering a feature flag”

An entity contributes to client-side MAU when:

• The client-side SDK (e.g., browser, mobile, IoT client) evaluates one or more flags for that entity in a given month.
• It doesn’t matter if they hit 1 flag or 50 flags—each unique entity is counted once per month.

Some important nuances:

• Anonymous contexts:
  If you use anonymous contexts (e.g., unauthenticated users or guests), each unique anonymous identifier that evaluates a flag counts toward MAU. Configuration decisions here can impact your bill.
• Multiple devices per user:
  If you identify users per device (e.g., each mobile device gets its own key), each device can count as a separate MAU.
• Multiple environments:
  If the same user encounters flags in multiple environments (for example, staging and prod) via client-side SDKs, they may be counted more than once depending on how you configure keys and environments.

How billing works with client-side MAU

• You commit to a certain MAU volume per month as part of your plan.
• LaunchDarkly measures how many unique client-side entities encounter flags in each billing month.
• If you exceed your committed MAU:
  • You’re billed for the additional MAU usage in the following month.
• Current list price reference (from public docs, subject to change):
  • $10 per 1k client-side MAU / month (Foundation plan example).

How anonymous and stored contexts affect MAU

Two configuration areas can influence how MAU accrues:

1. Anonymous contexts

   • Ideal for visitors who aren’t logged in yet.
   • But if each page view or session generates a new anonymous ID, you might inflate MAU.
   • Best practice: reuse anonymous IDs across sessions or for the life of the cookie/device where appropriate.

2. Stored contexts and caps

   • LaunchDarkly stores context instances for targeting, auditing, and analysis.
   • Environments can reach context limits (for example, millions of stored context instances).
   • You can manage and clean up stored contexts to keep targeting accurate and avoid unnecessary cardinality.

If you have unusual patterns (e.g., kiosk devices with rotating IDs or ephemeral browser sessions), talk to your LaunchDarkly representative—they can help you tune context usage so MAU reflects real usage, not noise.

---

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Service Connections	Measures server-side SDK instances per environment over time.	Aligns cost to actual microservice + environment footprint.
Client-side MAU	Counts unique client-side entities that encounter flags each month.	Scales with real user/device activity, not raw traffic.
Usage-based Billing	Bills overages only when you exceed committed Service Connections or MAU.	Predictable baseline with flexibility for growth and spikes.

---

Ideal Use Cases

• Best for microservice-heavy backends:
  Because Service Connections map directly to microservices, replicas, and environments, teams with Kubernetes or ECS-style architectures can scale LaunchDarkly in step with their rollout patterns—and know exactly which services drive cost.

• Best for high-volume B2C and multi-device apps:
  Because client-side MAU is based on unique entities that actually see flags, large consumer apps, IoT fleets, and cross-device products can keep pricing aligned with real usage rather than total HTTP traffic or page views.

---

Limitations & Considerations

• Autoscaling complexity:
  Heavy autoscaling can make Service Connection usage less intuitive. If you’re spinning up thousands of short-lived server instances, talk to your LaunchDarkly rep to model usage and right-size your commitment based on minute-level tracking.

• MAU inflation from identifiers:
  If you frequently rotate user IDs, generate new anonymous IDs per session, or identify per device when you could consolidate at the account level, your client-side MAU can grow faster than your actual user base. Review how you define contexts and IDs to keep counts realistic.

---

Pricing & Plans

LaunchDarkly’s public pricing page gives baseline signals (for example, the Foundation plan lists $12 per Service Connection / mo and $10 per 1k client-side MAU / mo), but actual pricing can vary by:

• Plan tier (Foundation vs. higher tiers).
• Volume commitments.
• Additional capabilities (experimentation, observability, AI Configs, enterprise governance).

Some customers are also billed by additional units like Experimentation MAU (the number of users available to be targeted in experiments each month, with an example rate of $3 per 1k), and observability usage (logs & traces volume).

For Service Connections and client-side MAU, think of plans roughly as:

• Growth / Foundation-style plans:
  Best for teams establishing feature management and experimentation with a moderate number of services and MAU, wanting a simple per-Service Connection and per-1k MAU pricing model.

• Enterprise plans:
  Best for organizations with large microservice estates, global user bases, and strict governance needs, where custom commitments, discounts, and additional units (Experimentation MAU, observability usage) are negotiated.

For precise numbers and how they apply to your specific architecture, the fastest path is a conversation with LaunchDarkly sales—they can translate your service topology and user base into projected Service Connections and MAU.

---

Frequently Asked Questions

How do I estimate how many Service Connections I need?

Short Answer: Count your long-lived server-side SDK instances per environment across your services, then layer in typical autoscaling patterns.

Details:
Start with a simple inventory:

1. List each server-side service that will use LaunchDarkly.
2. For each, list the LaunchDarkly environments it connects to (dev, staging, prod, etc.).
3. For each environment, count the typical number of long-lived instances (pods, VMs, processes) with the server-side SDK.

Multiply those together to get a rough Service Connection count. If you autoscale heavily, consider your average instance count over the month rather than peak. Your LaunchDarkly representative can then help refine this estimate based on minute-level usage patterns.

---

How do I control and predict client-side MAU?

Short Answer: Standardize how you identify users/devices, reuse anonymous IDs where appropriate, and monitor MAU trends in LaunchDarkly.

Details:

To keep client-side MAU predictable:

• Choose a stable identifier:
  Decide whether MAU should be per user, per device, or per account. Use that consistently in your client-side SDK initialization.

• Manage anonymous usage:
  If you use anonymous contexts, avoid generating a completely new ID for every page view or session unless necessary. Use cookies or local storage to persist an anonymous ID.

• Monitor usage in LaunchDarkly:
  Use LaunchDarkly’s reporting and usage views to see MAU trends. If you spot spikes that don’t match real-world growth, investigate identifier changes or new surfaces where flags are being evaluated.

• Coordinate with your rep:
  Your LaunchDarkly representative can help you check whether your MAU pattern is expected and suggest configuration improvements.

---

Summary

Service Connections and client-side MAU are LaunchDarkly’s way of tying pricing to the two places you actually use runtime control:

• Server-side: microservices, replicas, and environments connected via server-side SDKs (Service Connections).
• Client-side: the unique users/devices/orgs that actually encounter feature flags each month (client-side MAU).

Service Connections scale with your architecture. Client-side MAU scales with your audience. Together, they keep costs aligned with real feature flag usage—in production, in real time, with no redeploys required.

---

Next Step

Get Started