ConfigCat Pricing: Estimate Usage and Choose the Right Plan
If you are researching ConfigCat pricing or comparing it to alternatives like LaunchDarkly, you are likely trying to answer one simple question:
Which plan do we actually need?
ConfigCat pricing mainly depends on how many times your applications download their feature flags configuration per month, with larger plans allowing higher usage. While most of our users find ConfigCat pricing super simple, we have learned that for some, it is difficult to estimate their usage.
This guide shows you exactly how to estimate your usage and choose the right plan without guesswork.
How Does ConfigCat Pricing Work?
ConfigCat pricing is primarily based on how many times your application downloads config JSON.
Each time a client SDK downloads or refreshes its config from the CDN, it counts as one config download.
Typical flow
- Your app starts.
- The ConfigCat SDK downloads the latest config.
- The SDK caches it locally.
- The SDK refreshes it periodically.
This design allows feature flags to be evaluated locally in your application, which keeps performance fast and avoids server calls for every flag check.
Calculating downloads
The basic rule is:
Total downloads = initial downloads + periodic refresh downloads
When estimating usage, please count:
- 1 initial download for each app start, browser session, or app open;
- periodic refresh downloads based on how long that app instance stays alive.
Example:
- 10 servers
- SDK is set to refresh every 30 seconds
If those 10 servers each start once and stay up for the whole month, that is roughly:
Seconds in 30 days = 30 × 24 × 60 × 60 = 2,592,000 sec
Refreshes = 10 servers × (2,592,000 sec ÷ 30 sec interval) = 10 × 86,400 = 864,000
Initial downloads = 10
Total = 10 + 864,000 = 864,010 downloads / month
That total maps directly to a plan tier.
Which ConfigCat Plan Do You Need?
Each ConfigCat subscription plan includes a monthly quota of downloads and traffic.
| Plan | Monthly config downloads |
|---|---|
| Forever Free | ~5 million |
| Pro | ~25 million |
| Smart | ~250 million |
| Enterprise | ~1 billion |
So, with 864,010 downloads / month, you will fit into the Forever Free plan. If your usage grows, you can just move to a higher tier.
These limits are soft limits. If your usage temporarily exceeds your plan quota (e.g. during traffic spikes like Black Friday, product launches, or viral growth), ConfigCat will continue serving config requests. Feature flags are part of your application's runtime infrastructure, so reliability comes first.
If your usage consistently exceeds your plan's limits, we will reach out to you to discuss the best option for your system, whether that means fine-tuning your setup, upgrading your plan, or purchasing additional quota.
Does ConfigCat Charge Per Seat?
Unlike many developer tools, ConfigCat does not charge for seats. This means:
- Teams can add unlimited developers
- User count does not affect pricing
- Pricing scales with system usage, not team size
This approach keeps pricing predictable for engineering teams.
Many teams start with the Free plan and move to higher tiers as their applications scale. The goal of this pricing model is simple: your costs scale with the size of your system, not the size of your team.
How Does ConfigCat Pricing Compare to LaunchDarkly?
If you are coming from LaunchDarkly, the first thing to know is that the two tools measure usage differently.
ConfigCat uses a single metric: config downloads. LaunchDarkly combines two: service connections (each backend service counts as one) and client-side monthly active users (MAUs). The practical difference depends on your architecture, and it can be significant.
Take a frontend-heavy product as an example. LaunchDarkly's Foundation plan charges $8.33 per 1,000 client-side MAUs (LaunchDarkly Pricing, 2026), so 100,000 monthly active users run $833/month in MAU charges alone, regardless of how often those users actually trigger a feature flag check. On ConfigCat, the same users generate downloads based on session activity and your refresh interval, both of which you control.
Microservices face a different cost driver. Each backend service connection costs $10/month on LaunchDarkly's Foundation plan, so a system with 20 microservices adds $200/month before any user traffic is counted. On ConfigCat, backend services are counted by how many config downloads they make, not by how many there are.
| ConfigCat | LaunchDarkly | |
|---|---|---|
| Pricing basis | Config downloads | Service connections + client MAUs |
| Free plan | Yes (5M downloads/month) | Yes (Developer tier) |
If you are evaluating options after a price increase or looking for a model that scales more predictably, our top LaunchDarkly alternatives guide walks through the main options and what to look for.
Are Features Locked Behind Higher Plans?
No. Unlike many tools in this space (including LaunchDarkly, which gates SSO, SAML, and SCIM behind its Enterprise tier), ConfigCat ships all features on every plan.
All plans include:
- SSO
- 2FA
- SAML
- SCIM
- all integrations
- the full ConfigCat's powerful feature flag targeting and rollout engine
Pricing depends on configuration downloads, not on which features your team needs.
What Other Limits Apply?
Plans also define limits for certain resources, such as:
- number of feature flags
- number of environments (prod, staging, etc.)
- number of products
- number of segments
- support level
These limits are straightforward to estimate and rarely cause billing surprises.
Options for Special Requirements
For organizations with strict infrastructure or compliance requirements, ConfigCat offers alternatives to the standard SaaS cloud solution.
Dedicated infrastructure
The Hosted Dedicated Plan is a private-cloud solution where ConfigCat is installed and managed in datacenters specified by you.
On-premise deployment
With the On-premise deployment, you install and manage ConfigCat for yourself, and we give the license and support.
These offerings share a standard core, but details can be customized through a negotiated agreement.
Example: Estimated Monthly ConfigCat Usage
A typical multi-channel product shows how the pieces add up. Take this setup:
Backend
- 5 backend services (server-side scripts, microservices, Kubernetes pods, etc.)
- SDK refresh interval: 60 seconds
Web frontend
- 20,000 daily users
- ConfigCat JavaScript SDK
- refresh every 60 seconds while the page is open
- average session: 5 minutes
Mobile apps
- 8,000 daily users
- SDK refresh on app start
- average: 2 opens per day
Which ConfigCat plan would they fit into? Working through each layer gives the answer.
For each part of the system, we will use the same pattern:
Total downloads = initial downloads + periodic refresh downloads
Step 1: Backend Downloads
Each backend service starts with one initial download, then refreshes every 60 seconds.
Seconds in 30 days = 30 × 24 × 60 × 60 = 2,592,000 seconds
Initial downloads: 5 services × 1 = 5
Periodic refreshes: 5 services × (2,592,000 seconds ÷ 60 seconds interval) = 5 × 43,200 = 216,000
Total = 5 + 216,000 = 216,005 downloads / month
For long-lived backend services, the startup downloads are usually negligible compared to periodic refreshes. For short-lived jobs or frequently restarted pods, count one initial download for every start.
Backend services can receive near-instant notifications using ConfigCat Webhooks. Expose a web endpoint that calls your backend SDK's forceRefresh() function, and ConfigCat will notify it via webhook whenever feature flag values change.
Webhooks do not generate configuration downloads and have no additional cost, so they are a simple way to reduce backend traffic.
Step 2: Web Frontend Downloads
Each user session lasts about 5 minutes.
With a 60-second refresh interval, each session generates:
1 initial download at page load
4 periodic refreshes while the page remains open
Total = 5 downloads per session
This is the same as saying the page stays open for about 5 minutes and refreshes about once per minute, but separating the initial download from the periodic refreshes makes the calculation easier to reason about.
Daily sessions:
20,000
Daily downloads:
20,000 × 5 = 100,000
Monthly downloads:
100,000 × 30 = 3,000,000
A 60-second refresh interval means feature flag changes can take up to 1 minute to reach frontend applications. If you need faster propagation, you can reduce this to as little as 1 second by setting the pollIntervalSeconds parameter.
Step 3: Mobile Downloads
Mobile apps typically refresh feature flags when the app starts.
If the app downloads on startup and does not auto-poll in the background, each app open generates:
1 initial download + 0 periodic refreshes = 1 download
Daily downloads:
8,000 users × 2 opens = 16,000 downloads/day
Monthly downloads:
16,000 × 30 = 480,000
We have learned that mobile developers prefer retrieving feature flag values when the app starts. ConfigCat's SDKs support this behavior through manual polling mode.
Step 4: Total Monthly Usage
Estimated downloads:
Backend: 216,005
Web: 3,000,000
Mobile: 480,000
Total: 3,696,005 downloads/month
Which ConfigCat plan fits this system
Taking a look at the pricing tiers tells us that this system fits into the Forever Free plan, because the total usage is under 5 million downloads/month.
| Plan | Monthly config downloads |
|---|---|
| Forever Free | ~5 million |
| Pro | ~25 million |
| Smart | ~250 million |
| Enterprise | ~1 billion |
Takeaways
In most real-world systems:
- Frontend applications generate the most traffic, especially browser apps.
- Backend traffic is usually smaller and can be reduced further using Webhooks or the ConfigCat Proxy.
- Mobile traffic is moderate.
When you estimate usage, the safest mental model is always:
Total downloads = initial downloads + periodic refresh downloads
Count the initial downloads first, then add the periodic refreshes based on how long the app stays alive.
Understanding this pattern makes it easier to estimate feature flag usage and pick the right pricing tier.
What Refresh Interval Should You Use?
The right refresh interval depends on how quickly you need flag changes to propagate and how much traffic you want to generate.
- Backend services: start with 60 to 300 seconds. If you need faster updates, prefer Webhooks or the ConfigCat Proxy instead of very aggressive polling.
- Web frontends: 60 seconds is a practical default. Use 15 to 30 seconds only if faster propagation matters and the extra download volume is acceptable. Use 120 to 300 seconds if minute-level updates are enough and you want lower traffic.
- Mobile apps: prefer download on app start or when the app returns to the foreground. Continuous short-interval polling is usually unnecessary on mobile.
Choosing the Right ConfigCat Plan
Feature flags are meant to make deployments safer and give teams more control over releases.
Understanding how configuration downloads scale with your architecture and traffic makes it much easier to estimate usage and choose the right ConfigCat plan.
If you're unsure, the easiest way to start is with the Forever Free plan, which includes 5 million config downloads per month and the full feature set. Many teams find this is enough for early development and even production workloads. You can always upgrade later as your system grows.
Create a free ConfigCat account (no credit card needed) and start experimenting with feature flags today.
You can also stay up-to-date with us on X, GitHub, LinkedIn, and Facebook.