In May 2026, Cloudflare announced Flagship: an Edge-Native Feature Flag Service Built on OpenFeature and began offering an OpenFeature-compatible, edge-native feature flag platform as SaaS. In a domain previously led by players like LaunchDarkly, Optimizely, and Statsig, this adds an option to evaluate flags directly from Cloudflare's globally distributed network.
Feature flags have become indispensable for phasing feature releases in custom development. This article outlines design guidelines, phased rollout strategies, and common pitfalls when integrating Flagship × OpenFeature into custom development.
Why feature flags have become essential in custom development
The model where "release day = simultaneous public launch to all users" has already reached its limits in custom development. Here are the three reasons why:
| Context | Impact on custom development |
|---|---|
| Development speed accelerated 3x to 10x by AI | Simultaneous public launch with 5 releases a day is hazardous |
| Client user bases are diversifying | Growing demand to alter behavior by plan, region, or device |
| Demand for "recovery in seconds" during incidents | Deployment rollbacks are too slow to keep up |
In particular, the need to "roll out AI-written code incrementally" is growing rapidly in projects that have integrated Auto Mode or Cursor tools. Following the concept of "controlling the volume of code written by AI" covered in Safely Operating Claude Code Auto Mode in Custom Development, the practice of releasing in phases even if generation is fast is becoming the standard.
Characteristics of Cloudflare Flagship
Comparing Flagship with competitors reveals the following key characteristics:
| Item | Flagship | LaunchDarkly | Statsig | In-house implementation |
|---|---|---|---|---|
| Edge evaluation latency | Up to 5 ms (all Cloudflare locations) | 〜 50ms | 〜 100ms | Depends on custom design |
| OpenFeature compliance | ✅ Native | ✅ Provider | ✅ Provider | Depends on implementation |
| Pricing | From $0.10 / 1M evaluations | From $50/month + volume charges | Freemium | Infrastructure costs + labor costs |
| Workers / R2 integration | Native | API integration | API integration | Custom responsibility |
| Existing Cloudflare account | Can be used as is | New contract | New contract | Not required |
| SLA | 99.99% (Enterprise) | 99.99% | 99.95% | Self-managed |
In particular, "whether you are already using Cloudflare" serves as a major decision point. For projects that have already adopted Workers, Pages, R2, or D1, the ability to start using flags without additional contracts or SDKs is a major benefit, significantly lowering the barrier to adoption in custom development.
Five stages of phased releases built for custom development
When rolling out new features in stages for custom development projects, the following five stages serve as the baseline model.
[Stage 1: Internal Dogfooding]
└ 開発チーム + 顧客社内のみ（フラグ 100%、外部 0%）
[Stage 2: Friendly Users]
└ 顧客指定の協力ユーザー 5〜20 名（同意取得済み）
[Stage 3: Geographic Canary]
└ 国内の特定地域 / 特定プラン / 1〜5%
[Stage 4: Gradual Rollout]
└ 5% → 25% → 50% → 100% を 1〜2 週間で
[Stage 5: General Availability]
└ 100% 配信、フラグは "Cleanup 待ち" に移行Here are the progression criteria for each stage:
| Stage | Go criteria | No-Go signal |
|---|---|---|
| Stage 1 → 2 | No critical bugs, no anomalies in logs | Increase in stack traces |
| Stage 2 → 3 | Collected NPS feedback from participating users | Surge in support inquiries |
| Stage 3 → 4 | Error rate < 0.1%, p95 latency maintained | Elevated error rate |
| Stage 4 → 5 | Stable for 24h each at 5% / 25% / 50% | Decline in conversions |
| Stage 5 → Cleanup | Stable for 2 weeks at 100% flag enablement | Not applicable → Immediate cleanup |
By building this flow via the standard OpenFeature SDK, even if you switch from Flagship to LaunchDarkly or an in-house implementation in the future, no application-side code changes are required. This shares the same design philosophy of "maximizing performance while minimizing Cloudflare lock-in" discussed in Persistent Memory for Business Systems with Cloudflare Agent Memory.
Why OpenFeature is positioned at the core
Even when choosing Flagship, we strongly recommend using the standard OpenFeature SDK. The three main reasons are:
- Avoiding vendor lock-in: Application code remains unchanged even if switching vendors later
- Testability: Testing merely requires swapping to an in-memory provider
- Combining multiple vendors: Seamless division of roles—e.g., Statsig for A/B testing, Flagship for release management, and in-house tools for internal use
OpenFeature is a Cloud Native Computing Foundation sandbox project and is becoming the de facto industry standard. In custom development projects, incorporating OpenFeature from the beginning represents the minimal investment needed to preserve future options.
Five common pitfalls
Finally, here are pitfalls frequently encountered when running feature flags in custom development.
Pitfall 1: Leaving flags "permanently abandoned"
Failing to clean up flags after release completion causes if-statements to proliferate endlessly across the codebase. Always set a "cleanup deadline" for each flag and have CI trigger warnings for overdue flags.
Pitfall 2: Forgetting to define "default values" during design
When Flagship becomes temporarily unresponsive, the user experience varies dramatically depending on whether the default value is false or true. Explicitly configure failsafe fallback values in the OpenFeature provider setup.
Pitfall 3: Confusing A/B testing with release management
"Whether to release a feature" and "A/B testing a button color" are flags with completely different operational lifecycles. Categorize them using prefixes or tags, and display them separately on monitoring dashboards.
Pitfall 4: Client stakeholders toggling flags directly
Handing over permissions carelessly leads to accidents where a client stakeholder toggles a flag on a Friday evening. Agree on "who," "when," and "which environment" can be operated via RBAC on a per-project basis, and document this in contract clauses.
Pitfall 5: Evaluating flags only on application startup
Fetching flags only once upon server-side startup means flag changes will not be reflected. We recommend using OpenFeature's streaming providers or per-request evaluation at the edge to keep the maximum reflection delay within 5 to 30 seconds.
Summary: Turning releases from "events" into "daily operations"
Feature flags are a mechanism that transforms feature releases from high-stakes, one-shot events into smooth, everyday operations. The combination of Cloudflare Flagship × OpenFeature offers an easily adoptable setup for custom projects as an option that lowers contract hurdles while preventing vendor lock-in.
Implementing OpenFeature and designing phased rollout frameworks vary considerably in effort depending on codebase size, number of environments, and authorization requirements. If you have concerns such as "Friday production releases are stressful" or "we want to roll out features early to a limited user segment," we provide individual estimates upon reviewing your details. Please feel free to reach out via our contact form.
Sources
- Cloudflare Introduces Flagship: an Edge-Native Feature Flag Service Built on OpenFeature（InfoQ）
- OpenFeature — A vendor-agnostic feature flag standard
- Safely Operating Claude Code Auto Mode in Custom Development (GH Media)
- Persistent Memory for Business Systems with Cloudflare Agent Memory (GH Media)
