From Fragmented Flags to Confident Releases: The OneSignal Story
Taming feature flags across hundreds of services in a Kubernetes-heavy backend
OneSignal operates hundreds of backend services and around 13,500 Kubernetes pods, making safe rollouts and centralized feature flag management essential. By adopting ConfigCat, OneSignal consolidated release control across their platform, reduced deployment risk, and enabled both engineering and product teams to ship features with confidence, always landing on their feet.
Your Cat-Scan Summary
Overview
Industry
Software Development
Company Size
51-200 employees
Using ConfigCat Since
2024
Use Case
Feature targeting, controlled releases, backend feature flags
Key Wins
Centralized feature flag management, safer rollouts using targeting and percentage-based rules, reduced deployment risk
Who is behind the flag?
About OneSignal
Founded in 2014, OneSignal is an intelligent messaging platform used by product and marketing teams to onboard, engage, and retain users. They can orchestrate journeys across push, web, SMS/RCS, email, and in-app messages, driving lifecycle outcomes all from a single platform.
The Purr-fect Stack
Tech Stack & Development Culture
OneSignal operates a large, modern backend built to support a global, distributed messaging platform.
The backend is polyglot by design, with services written in:
- Rust, which powers most of their backend services
- Ruby, from their original Ruby on Rails codebase
- Golang, used across additional services
Feature flags are primarily evaluated in backend services, with some services forwarding feature flag values to a SPA frontend. While OneSignal does not develop mobile applications themselves, many feature-flagged API endpoints are consumed by their customers' mobile SDKs.
ConfigCat's broad SDK support made it easy to standardize feature flag usage across all these services.
The platform runs at significant scale on Kubernetes, with approximately 13,500 pods deployed using different deployment strategies. Some Ruby-based services rely on multi-process architecture that cannot share caches, which can result in a single pod requesting feature flag values multiple times.
This environment requires tooling that is reliable, fast and flexible, especially when multiple teams work on shared services. OneSignal's development culture emphasizes controlled rollouts, clear ownership, and reducing risk in production, even as the system grows in size and complexity.
Before ConfigCat Walked In
The Challenge: Fragmented Feature Flag Management
As OneSignal’s platform expanded, feature flag management became increasingly complex.
Different services had adopted different approaches:
- Open-source tools in some places
- Custom, in-house solutions in others
- Little consistency, limited visibility, and scattered ownership
This fragmentation made it harder to manage feature rollouts centrally, especially across a rapidly growing engineering organization. OneSignal needed a single feature flag management service that could scale with their backend and support multiple teams and languages.
“Every service had its own approach, some using open-source solutions like Flipper, which had a UI. But most of the time, each service would have its implementation, often without UI support, and not be very flexible.”
How the Cat Saved the Day
The Solution: Centralizing Feature Flag Management Across Teams and Services
OneSignal adopted ConfigCat to replace fragmented feature flag implementations with a single, unified feature flag management system.
The original goal was to support engineering teams by standardizing how feature flags are created, managed, and evaluated across services. Over time, ConfigCat also became a useful tool for product teams, enabling closer collaboration during feature launches.
“For OneSignal, our initial goal was to facilitate engineering teams, but product teams also have access to ConfigCat to manage feature flags or new features we like to give access to beta customers. So they help facilitate that process of onboarding beta customers.”
With ConfigCat, teams can:
- Manage feature flags across multiple languages from a single UI
- Use targeting rules to control access for different customer plans
- Roll out features gradually using percentage-based rules
- Organize feature flags using tags to reflect team ownership
This shared approach allows engineering and product teams to move faster together without sacrificing control or reliability. Feature releases become calmer, more predictable, and easier to manage, even across hundreds of backend components and pods.
The Cat in Action
How OneSignal Uses ConfigCat in Production
Feature Flags Across Multiple Languages
OneSignal uses ConfigCat in Ruby, Golang, and Rust, supported by ConfigCat's broad SDK support. This made it possible to standardize feature flag usage across both legacy and modern services without introducing additional complexity.
Scaling Feature Flags with the ConfigCat Proxy
To reduce API usage and increase reliability, OneSignal uses the ConfigCat Proxy.
Because some Ruby pods cannot share caches and may request feature flag values up to 20 times per pod, the proxy helps:
- Reduce overall API calls
- Improve performance
- Act as an additional reliability mechanism
By hosting their own proxy, OneSignal adds an extra layer of resilience to their architecture, which is especially valuable in a large-scale Kubernetes infrastructure.
Real-World Feature Flag Usage
OneSignal uses ConfigCat’s capabilities in several real-world scenarios to manage feature releases safely and at scale. They rely heavily on targeting rules to roll out features to different customer cohorts based on subscription plans.
“We leverage targeting rules all the time to release features to different cohorts of our customers, which we would segregate based on the plans our customers are on. Free vs. paid, or even between different paid plans, too.”
In addition, percentage options are frequently used to control the rollout of new features and refactorings, allowing teams to introduce changes gradually in production and reduce risk.
As feature flag usage grew across services and teams, OneSignal also found feature flag tags especially useful for organizing flags and clarifying ownership when multiple teams work on the same services, helping maintain long-term clarity and control.
Why They Picked the Cat
Why OneSignal Chose ConfigCat
OneSignal evaluated a broad set of feature flag service alternatives, including OpenFeature (with Flagd), FlagSmith, Flipt, Unleash, DevCycle, LaunchDarkly, FeatBit, CloudBees, Harness, Split, and PostHog.
They compared solutions across several dimensions:
- Broad language support
- Audit logging
- Multiple environment support
- Metrics
- Pricing
After reviewing all options, ConfigCat ranked highest across their evaluation criteria.
From Meow to Wow
Future Outlook: Building on a Strong, Scalable Foundation
The OneSignal journey is continuing to evolve. With feature flag management centralized and running reliably across a large, Kubernetes-heavy backend, the team is well positioned to support ongoing growth and platform development. As OneSignal continues to expand its omnichannel messaging capabilities and serve developers and marketers around the world, ConfigCat provides a stable foundation that helps teams roll out changes in a controlled, predictable way, no matter how complex the environment becomes.
Is ConfigCat a Fit for You?
Land Every Release on Its Feet
OneSignal's experience shows how much easier feature delivery becomes with the right release management approach in place. If you’re looking to centralize feature flag management, support both engineering and product teams, and ship with confidence at scale, ConfigCat helps your releases land smoothly, even in complex, distributed systems.
Want more? Discover our other success stories!