| Profile | Connections cost | MAU cost | Seats | Monthly total | Annual vs monthly billing | Plan that fits | |---|---|---|---|---|---|---| | 5 developers, 10 connections | Small, the main variable | None, no client-side SDK | Few, a minor line | Mostly connections plus a handful of seats | Annual saves little in absolute terms | Entry paid plan | | 15 developers, 40 connections, 100k MAU | Grows with every service | Becomes the largest line | Moderate | Driven by MAUs, then connections | Annual discount is worth committing to once traffic is stable | Mid-tier plan | | 50 seats, several environments | Multiplies across environments | Depends on client apps | Largest line | Driven by seats, then environment count | Annual matters most, but only if seat count holds | Plan with governance controls | With no client-side SDK there's no MAU line for a five-person, server-side-only team, so the bill is seats plus connections. Each extra service that opens its own connection adds cost, so count processes, not repositories.  For fifteen developers with a client-side app, once a browser or mobile app evaluates flags, MAUs become the largest line, and 40 connections are a second meter running beside it. With fifty seats and several environments, seats lead the bill, and every extra environment repeats the connection charge. Governance features justify the higher plan here, but annual billing locks in a seat count you may not keep. ## Usage meters driving LaunchDarkly costs **Four meters decide a LaunchDarkly bill** (service connections, seats, client-side MAUs and event volume), and each one grows on a different trigger than the others. The list below pairs every meter with what pushes it up and whether the plan covers it or bills overage, so you can find your own exposure before you compare tools. - Service connections rise with every SDK instance or backend service you add. Your plan includes an allotment, then bills overage. - Seats rise with every person you invite. The plan includes a set seat count, and extra seats cost more. - Client-side MAUs rise with traffic spikes and anonymous visitors. Your plan includes an allotment, with overage beyond it. - Experiment events rise with every tracked interaction. The plan includes some volume, and the rest is overage or an add-on. Split a monolith into services, or run more replicas, and the meter rises without a single new user, because LaunchDarkly counts a connection per SDK instance, not per product. If product managers, support staff and contractors all need to flip a flag, each one is a billable seat. Anonymous users count as contexts too. A marketing push, a bot wave or a viral post inflates the meter for a month, and you pay for traffic you didn't plan for. Turn experiments on across a busy app and that's where overage tends to start. Experimentation and observability sit outside the base flag price, and every tracked event adds to the total. ## Hidden costs and limits teams hit after launch With the meters priced, gated features, caps and contract terms are what remain, and the Enterprise column of the table below is where most of them sit. I haven't confirmed any cell against a LaunchDarkly docs page, so every entry is an unverified customer report. Confirm each one in writing before you sign. | Capability | Developer | Foundation | Enterprise | Status | |---|---|---|---|---| | Approvals | Reported absent | Reported limited | Reported included | Unverified customer report | | SSO | Reported absent | Reported absent | Reported included | Unverified customer report | | Custom roles | Reported absent | Reported absent | Reported included | Unverified customer report | | Audit log retention | Reported shortest | Reported mid-length | Reported longest | Unverified customer report | | Environment/project caps | Reported tightest | Reported raised | Reported negotiable | Unverified customer report | | Renewal terms | Self-serve | Self-serve | Quote only | Unverified customer report | **If approvals and SSO are compliance requirements for you, the real entry price is the Enterprise quote, not the plan you started on.** ### LaunchDarkly environment, retention and rate limits When a cap is hit, overage policy decides what you pay. In a [Benchmarkit survey by Ray Rike](https://www.linkedin.com/posts/rayrike_how-are-saas-companies-managing-overages-activity-7284929905941708802-Z3Ke), 39% of SaaS companies use a soft cap, so most vendors let you exceed a limit and sort out the bill afterward.  According to Benchmarkit (Ray Rike), another 26% charge overages directly, which means a traffic spike becomes a line item. **Only 14% use a hard cap**, so don't count on being cut off before you're billed. And 19% don't charge at all, which is why you should ask which group your vendor falls into. Ask for the overage rule, the renewal uplift and the notice period in writing. ## Plan upgrades vs. overage costs Past a specific connection count, the next plan is cheaper. That's the count where your overage charges, at $12 per extra service connection per month, grow past the next tier's flat fee plus its lower per-connection rate; by this point, you're paying more than you would on the next tier.  ### Crossover points between tiers Overage cost is a straight line: extra connections multiplied by $12. The next tier is a flat fee that you pay from the first connection, plus a lower rate on whatever you add. ### LaunchDarkly overage vs. next-tier crossover chart Plot monthly dollars against service connections from 5 to 100. Draw the current-tier overage line against the next tier's flat-fee-plus-rate line, and mark where they cross. Read it as a tripwire: the crossover is the connection count at which your finance team should stop approving overage and start approving the upgrade. ### LaunchDarkly annual commitment pricing tradeoffs Annual commitments follow the same logic with a different axis: you trade flexibility for a lower rate, so the commitment only wins if your connection count stays above the crossover for the whole year. ### Getting real LaunchDarkly pricing quotes in writing I won't give you a dollar figure for each step. LaunchDarkly's plan fees past the entry tier aren't something I can confirm here, and a guessed number would be worse than none. Ask for the flat fee and per-unit rate in writing, put both into the two lines above, and find your own crossover. ### Moving the crossover by cutting usage Shrinking the count that drives your bill moves the crossover further away. 1. Audit service connections. Each server-side SDK instance that holds a streaming connection counts, so duplicate environments, idle staging services and short-lived workers inflate the meter. 2. Share one SDK client per process rather than creating one per request or per job. 3. Move low-change flags to a configuration file or environment variable, so fewer services need a live flag connection at all. 4. Prune seats and dead flags. Former contractors and abandoned test projects still occupy paid slots.  ## LaunchDarkly against Unleash, Flagsmith, PostHog and Statsig **Mostly, the cheaper-looking tools charge on different meters**. They only win when their meter's smaller than LaunchDarkly's for your traffic, which you can only know after rerunning the comparison. ### Price and pricing unit side by side To see what each vendor counts and whether you can run it yourself, read the pricing unit column first: it tells you which of your numbers (developers, end users, events) becomes the bill for a 15-developer team. | Tool | Pricing unit | Self-hosting | What moves a 15-developer bill | |---|---|---|---| | LaunchDarkly | Service connections, seats, client-side MAUs, events | Not offered as a standard option | Every meter at once, so the bill tracks traffic and headcount | | Unleash | Seats and instances on the hosted plan | Open-source edition you run yourself | Seat count, or your own server time if self-hosted | | Flagsmith | Requests on the hosted plan | Open-source edition you run yourself | API request volume from your apps | | PostHog | Usage-based, billed per product (flags are billed per request) | Open-source edition, with limits | Flag request volume, which grows with page loads | | Statsig | Events and usage | Hosted service | Event volume, which grows if you log heavily | For current rates, go to the vendors' own pricing pages. ### When self-hosting feature flags costs less When your flag traffic's large, your team already runs its own infrastructure, and you don't need to hire anyone to babysit one more service, self-hosting's cheaper. The license is free, but you pay for the server, upgrades, uptime and the on-call hour when flag evaluation stalls and every feature check fails. For a 15-developer team with no platform engineer, that engineering time can exceed a hosted bill several times over. The same choice applies to the automation around your flags, and Activepieces keeps it a setting rather than a commitment: it's the same product self-hosted (Docker, Compose or Kubernetes, air-gap capable) or on its managed cloud, and Git Sync and Releases, a documented feature in the Activepieces docs, promotes flows from test to production.  The core is MIT-licensed, so hosting there is a cost line you can revisit rather than a decision you're stuck with. ## LaunchDarkly integrations and webhooks With little code, flag changes and usage alerts can reach Slack, tickets and a finance sheet. LaunchDarkly's own webhooks cover the plumbing, and the wiring hours belong in the same tally you just made. ### LaunchDarkly native integrations and webhook setup LaunchDarkly ships native integrations for common chat and ticketing tools, so a flag change can post to a channel or open a ticket without you building anything. For anything without a native integration, a webhook sends an HTTP request to a URL you control whenever a matching event fires. That covers the finance sheet, which has no native route.  ### Routing flag events with Activepieces Receiving those webhooks and fanning them out is something Activepieces handles through its catalogue of 747 integrations, counted in the community integrations directory of the activepieces/activepieces repository, under an MIT-licensed core, so webhooks can be routed to hundreds of different platforms. If a service you need is missing, an integration for it can be generated privately. This is optional, and it's not a pricing remedy: it moves alerts to the right people, but it doesn't lower a single meter on your invoice. It's worth it only if someone on finance needs usage alerts in a sheet and nobody wants to read a dashboard. From the moment LaunchDarkly emits a usage alert to the moment finance can see it in a row, the sequence below shows one route. 1. Create a webhook in LaunchDarkly pointing at your workflow's URL, so events leave the product instead of waiting for someone to look. 2. Add a Catch Webhook trigger in Activepieces, which receives that request and starts a run. 3. Filter on the event kind, so routine flag edits don't flood the channel meant for usage alerts. 4. Post the filtered event to Slack, where the engineer who can act on it will see it. 5. Append a row to the finance sheet, which leaves a dated record you can compare against the invoice. ## Frequently asked questions Does LaunchDarkly have a free plan? It's offered a free entry plan for small projects, but its limits are set for evaluation, not production traffic. Read the current caps on the pricing page and measure your own connections against them before assuming it covers a live app. Is LaunchDarkly pricing per seat or per usage? Both. You pay for seats, and you pay separately for usage meters such as service connections, client-side monthly active users, and event volume. Seats are the predictable line; the meters are the ones that grow with traffic, so a small team with a busy app can still see a large bill. Can you pay for LaunchDarkly monthly instead of annually? Billing terms depend on the plan. Self-serve tiers have been offered with monthly payment, while larger plans are typically contracted annually, and the price for those is often available only through sales. Ask for the monthly figure in writing, because an annual-only quote hides what a month of overage costs. ### Is there an open-source alternative to LaunchDarkly? Yes. Unleash and Flagsmith are open-source flag platforms you can host yourself, and GrowthBook's an open-source tool that pairs flags with experimentation. **Self-hosting removes the per-connection and per-user meters**, but you take on hosting, upgrades, and uptime, which is a cost of its own. OpenFeature's a vendor-neutral standard for flag code, not a service, so adopting it makes a later switch cheaper. What should I check before signing a LaunchDarkly contract? Price your own traffic against each meter, then confirm these points: - How the vendor counts a service connection, and whether each server instance or process counts separately - How client-side users are counted, and whether anonymous visitors are included - What happens when you pass an included limit: a hard stop, an overage rate, or a forced upgrade - Whether the renewal price is fixed or resets - Whether the quote lists every meter, not just the headline plan If the sales team can't state these plainly, treat that as part of the price. ## Related reading - [Cohere Pricing 2026 for Trial, Production and Enterprise](https://www.activepieces.com/blog/cohere-pricing-2026-for-trial-production-and-enterprise) - [ADP Payroll Pricing for Small Businesses in 2026](https://www.activepieces.com/blog/adp-payroll-pricing-for-small-businesses-in-2026) - [DeepSeek Search API vs Exa Pricing for Small Teams (2026)](https://www.activepieces.com/blog/deepseek-search-api-vs-exa-pricing-for-small-teams-2026) ## References - [Benchmarkit (Ray Rike)](https://www.linkedin.com/posts/rayrike_how-are-saas-companies-managing-overages-activity-7284929905941708802-Z3Ke)Whichever meter leads, the bill is seats plus connections plus client-side MAUs, and the plan name only sets the rates.