Over the last few quarters, we’ve been steadily evolving ConfigBee.
We’ve expanded our SDK ecosystem with Flutter, introduced Gradual Rollouts, refreshed our SDKs, redesigned our pricing, introduced Deployment Units, published a new Fair Usage Policy, expanded our documentation, and completely rethought how we position ConfigBee.
Rather than announcing each of these changes individually, we wanted to step back and share the bigger picture.
Along the way, we’ve spent a lot of time talking with existing customers, engineering leaders, startups, industry experts, and new design partners evaluating ConfigBee.
Those conversations shaped nearly every decision we’ve made.
One thing became increasingly clear.
Modern software teams aren’t looking for another feature flag service.
- They’re looking for a reliable way to control software after deployment.
- They want to release safely, respond to production issues immediately, experiment confidently, personalize experiences, and give engineering, product, operations, and customer-facing teams the ability to control application behavior without shipping a new version of their application.
That realization has changed how we think about ConfigBee.
Today, ConfigBee is evolving beyond feature flags into a Runtime Control Platform and Release Management Platform.
Our philosophy.
> Build once. Control everything.
Expanding the ConfigBee Ecosystem with Flutter
One of the biggest milestones over the last few quarters has been the release of our Flutter SDK.
Flutter has become one of the most widely adopted frameworks for building cross-platform applications, and supporting it has been one of our most requested capabilities.
Today, our Flutter SDK is stable and production-ready.
Teams can now use ConfigBee’s Feature Flags, Dynamic Configurations, Targeting, and Runtime Control capabilities in Flutter based applications across Android, iOS, web, and desktop platforms.
For us, this is much more than adding another SDK.
It significantly expands the ConfigBee ecosystem into the mobile space while providing the same runtime control experience developers already expect on other platforms.
Gradual Rollouts Have Arrived
Another major milestone is the introduction of Gradual Rollouts.
ConfigBee has supported Contextual Targeting for a long time.
Many teams already use it to enable features for specific users, customer accounts, organizations, or carefully selected groups.
That works well when you already know exactly who should receive a feature.
As applications grow, however, another challenge appears.
Sometimes you don’t want to manually choose users.
Instead, you want the platform to automatically and consistently select a percentage of your users, gradually increase exposure, monitor production, and safely expand the rollout over time.
That’s exactly what Gradual Rollouts are designed to do.
Start with 1%.
Observe production.
Increase to 5%.
Then 10%, 25%, 50%, and eventually everyone, only when you’re confident.
This dramatically reduces deployment risk while making progressive delivery much easier.
Targeting and Gradual Rollouts Work Together
Although they may appear similar, Targeting and Gradual Rollouts solve different problems.
Contextual Targeting answers the question:
> Who should receive this feature?
You explicitly select users, customer accounts, organizations, or other contexts.
It’s ideal for long-term feature entitlements, enterprise customers, beta programs, customer-specific configurations, and personalization.
Gradual Rollouts answer a different question:
> How quickly or safely should this feature reach everyone?
Instead of manually selecting users, ConfigBee automatically chooses a stable percentage of your audience and progressively expands that percentage as your confidence grows.
One capability is about intentional audience selection.
The other is about safe release progression.
Together, they provide a much more complete runtime control model.
To support these capabilities, we’ve updated our SDKs so Gradual Rollouts work consistently across supported platforms.
Check our SDK Capability Matrix for more details.
Beyond Feature Flags
You’ll also notice that our website looks different.
That’s intentional.
Feature Flags remain one of ConfigBee’s core capabilities, but they no longer define the entire platform.
Today, ConfigBee combines:
- Feature Flags
- Dynamic Configurations
- Runtime Control
- Release Management
- Contextual Targeting
- Progressive Delivery
- Personalization
all into a single platform.
The goal isn’t simply to toggle features.
It’s to give teams complete runtime control over software behavior after deployment.
Deploy once.
Then let engineering, product, operations, support, and customer success teams decide what users experience, feature by feature, user by user, without redeployments.
Simpler Pricing That Grows with You
As ConfigBee has evolved, we also wanted our pricing to evolve.
Our objective was straightforward.
Make pricing easier to understand while removing unnecessary friction.
Every plan continues to include unlimited Feature Flags and Dynamic Configurations.
Pricing is now centered around two primary concepts.
- Monthly Active Visitors (MAVs) – measure the scale of your user base.
- Deployment Units (DUs) – measure the operational footprint of your application.
Rollout capabilities then scale naturally with each plan, from Instant Rollouts on the Free plan to increasingly advanced rollout strategies as teams grow.
Introducing Deployment Units
Deployment Units are a new concept within ConfigBee.
Their primary purpose is to represent the overall footprint of your projects within an account.
Today, they’re primarily measured by the total number of active environments across all projects.
Rather than managing separate limits for projects, environments, and other structural resources, Deployment Units provide a simpler representation of how your organization uses ConfigBee.
Alongside Monthly Active Visitors, Deployment Units also serve as the baseline for our Fair Usage Policy, giving us a transparent and scalable way to manage platform capacity without complicating pricing.
Check Glossary & Core Metric Definitions for more details.
A Fair Usage Policy Designed for Growth
One of the most important additions in this release isn’t a feature.
It’s our new Fair Usage Policy.
We introduced it with three goals.
* Keep pricing simple.
* Safeguard long-term platform stability.
* Maintain healthy unit economics as ConfigBee grows.
Instead of exposing every operational limit directly on our pricing page, we’ve significantly increased many limits that previously created unnecessary friction and moved them into the Fair Usage Policy.
For most customers, these limits should never become something you have to think about.
Just as importantly, our Fair Usage Policy is intentionally designed to be soft.
If your usage exceeds expected allocations, ConfigBee won't automatically stop serving feature flags or interrupt your production traffic.
Instead, we'll reach out, understand your workload, discuss your growth plans, and work with you to find the right solution.Our philosophy is simple.
We’d much rather work with our customers than surprise them with hard limits.
Better Documentation for a Growing Platform
As the platform has grown, so has our documentation.
We’ve expanded our SDK documentation, rollout documentation, glossary, and platform guidance to make ConfigBee easier to learn and easier to adopt.
Whether you’re learning about Deployment Units, Monthly Active Visitors, rollout strategies, or SDK capabilities, our goal is to provide clear explanations that help teams make the most of the platform.
Continuing to Support Startups
We’re still a startup ourselves, and we know how challenging those early stages can be.
That’s why we’re continuing our Verified Startup Program.
Eligible startups receive access to our Starter plan at no cost in exchange for collaboration and feedback, helping both of us grow together.
We’re also continuing to support eligible Startup India (DPIIT) recognized startups with additional benefits.
Supporting founders and engineering teams remains an important part of our mission.
Looking Ahead
This represents the biggest evolution of ConfigBee since we started building the platform.
It’s not defined by a single feature.
It’s the result of several quarters of listening, learning, and building.
To everyone who has trusted ConfigBee, shared feedback, challenged our thinking, or is evaluating us today—thank you.
Your ideas continue to shape what we build next.
We’re excited about the road ahead, and we’re just getting started.
Build once. Control everything.