Why progressive delivery with open source feature flags needs its own plan
A platform team can switch off a bad web, commerce or learning release in seconds only if the kill switch is designed for that job before the release ships. Self-hosted Unleash, Flagsmith or GrowthBook can carry percentage rollouts, canary cohorts and operational kill switches. The edition you license, the hosting model you choose and the runtime path a kill switch takes through your SDKs, caches and networks decide whether it fits your estate. The short platform comparison sits in the platforms section, so this section focuses on what changes when the release is public-facing.
Generic flag setups assume that a toggle is an engineering convenience. Public digital estates in regulated sectors treat a toggle as a change to a live service. A checkout step, course enrollment page or citizen form that is switched on for 10 percent of visitors may also have to meet accessibility duties. For state and local government web content, the ADA Title II rule requires WCAG 2.1 Level AA, and the ADA Title II web and mobile accessibility rule sets compliance dates of April 26, 2027 and April 26, 2028 depending on entity size. A cohort that sees an unaudited variant is a compliance question, not only a product question, so the rollout plan must record who received which variant and when.
Before you rely on a kill switch, confirm three things with your vendor and in your own environment: whether the flag is evaluated server-side or in the client, what the SDK does when the flag service is unreachable, and which default value applies to each flag. Confirm which edition provides the approvals, roles and audit logs you need, because on the published pricing pages several of these governance features sit in paid tiers. Then rehearse the switch-off with the on-call team, measure how long it takes to take effect across your delivery channels and record the result as evidence.
Which release-control requirements shape the build
This table maps each release-control requirement to its source, whether a regulation, an internal control or a platform constraint, and to what it means for the build. Read it as a checklist to settle before choosing between Unleash, Flagsmith and GrowthBook, since several requirements depend on which edition you run. The main takeaway is that approvals, audit logs and SAML sit behind paid tiers on every candidate, so budget and governance needs should be fixed before the platform is picked.
| Requirement | Source of the requirement | What it means for the build |
|---|---|---|
| Kill switch latency and fallback values | Internal incident response runbook and service availability targets set by the owning team | Every flag needs a safe default that the SDK returns if the server is unreachable. Test the off path in staging and confirm how quickly each SDK picks up a changed state. |
| Percentage rollouts and sticky bucketing | Internal release policy for staged exposure | Users must stay in the same bucket across sessions or the experience flips. Sticky bucketing is a Enterprise feature on self-hosted GrowthBook, so confirm bucketing behavior in the Open Source edition and in each SDK. |
| Canary cohort definition | Internal release policy and product owner sign-off | Cohorts depend on attributes such as region, tenant or account type. Define the attributes, decide where they are stored, and confirm they are sent to the flag service only as needed. |
| Approval and audit of toggles | Internal change management policy and, for regulated firms, the relevant control framework | Approvals and change requests are Enterprise features on Unleash and GrowthBook. Flagsmith governance features, including roles, change requests and audit logs, start at the Scale-Up plan. Confirm the edition before designing the workflow. |
| Role-based access and SSO | Identity policy and access reviews | SAML single sign-on on Flagsmith is an Enterprise feature, and SSO and SCIM on GrowthBook are Enterprise features. Plan provisioning and removal of access for toggle operators. |
| Flag cleanup and lifecycle | Internal engineering hygiene standard | Stale flags add code paths and risk. Assign an owner and expiry date to each flag at creation, and track removal in the same ticket as the code change. |
| SDK caching and offline defaults | Platform constraint of the chosen SDK and edge layer | Unleash Edge open-source support reaches end of life on December 31, 2026, so plan a move to an Enterprise plan or another caching design. Test behavior when the cache is cold and the server is down. |
| Accessibility of rolled-out content | ADA Title II rule for state and local government web content, which requires WCAG 2.1 Level AA | Experiment variants are still public content. Public-sector teams should include accessibility checks in the release gate for each variant, not only for the default experience. |
| Operations and self-hosted deployment | Platform constraint: Flagsmith recommends an external database in production, and GrowthBook recommends a managed MongoDB-compatible service | Decide who runs the database, backups and upgrades before go-live. Confirm the flag service stays available during deploys, since it is now in the path of every release. |
Which open source platform fits progressive delivery
Unleash, Flagsmith and GrowthBook all support percentage rollouts and flag-based shutoffs, but they differ in licence terms, what the free self-hosted edition limits, and which governance controls sit behind a paid tier. The choice depends on whether one team manages a few environments, several teams share flags across environments, or releases are judged against warehouse metrics.
Unleash for single-team kill switches
Unleash moved its source code to AGPLv3 starting with v8.0.0, while the official open-source Docker images remain under Apache 2.0. The free edition is limited to 1 project and 2 environments with basic roles, which suits one team with a production kill switch and a staging flag. Confirm that your use of the source, not just the images, keeps you within AGPLv3 obligations. Edge OSS reaches end of life on December 31, 2026, so plan its replacement before that date.
Unleash for multi-environment rollouts
Once several teams or production, staging and regional environments need separate flag states, the free Unleash edition stops at 2 environments. Enterprise adds unlimited projects and environments, project roles, user groups and change requests. Confirm which of these you need before choosing, and confirm how environment import and export handles segments and custom strategies, which must already exist in the target instance.
Flagsmith for infrastructure-led delivery
Flagsmith's core code is BSD 3-Clause, and its self-hosted open-source version has no API request limits. Its official Helm chart creates a PostgreSQL server in the cluster by default, so production deployments should point it at an externally managed database. Optional Edge Proxies reduce latency for distributed services. Confirm the Edge Proxy and PgBouncer setup against your traffic pattern before go-live.
Flagsmith governance and access controls
Role-based access control, SAML single sign-on, change requests and audit logs are Enterprise features in Flagsmith, and the pricing page places governance features from the Scale-Up plan. Teams that need approval trails before a kill switch can be flipped in production should confirm this tier before committing. OpenShift deployment through Helm charts is available, but Operator support requires an Enterprise plan.
GrowthBook for MIT-licensed core
GrowthBook's code outside its enterprise directories is MIT licensed, and its self-hosted Open Source plan includes unlimited users, 1 project and unlimited API requests. That makes it a fit for a single team running percentage rollouts and kill switches with no request ceiling. Confirm that the enterprise directories you deploy are covered by the GrowthBook Enterprise License before relying on any of them.
GrowthBook for safe rollouts and warehouse metrics
Self-hosted Enterprise adds safe rollouts, approval workflows, ramp schedules and holdouts. GrowthBook also runs its statistics against your own warehouse using only SELECT queries and receives aggregated results, so a canary can be judged on the same revenue or error data your finance or operations teams already trust. Confirm which warehouse your metrics live in and whether your team can write the SQL definitions.
How to roll out progressive delivery in phases
This sequence moves a team from unmanaged releases to flag-controlled delivery in stages, so each phase produces a tested artifact before the next one depends on it. The end state is a self-hosted flag server where a bad release can be switched off in a measured, rehearsed time.
Inventory release paths and critical journeys
Platform and product owners list every service, release pipeline and user journey that a flag could affect, and mark the journeys that carry payments, sign-in or regulated data. Engineering leads record who can approve a production change today. The output is a signed inventory with a named owner per path, which becomes the scope for every later phase.
Define kill switch scope and fallback values
For each critical journey, the team writes the kill switch it needs, the fallback value served when the switch is off, and the condition that triggers it. Fallback values must be safe defaults that the application can serve without the flag server reachable. The output is a reviewed register of switches with fallbacks, approved by the service owners.
Deploy the flag server with external database
The platform team installs the chosen self-hosted server (Unleash, Flagsmith or GrowthBook) in its own cluster or VM estate, connected to a managed PostgreSQL or MongoDB service rather than an in-cluster database. The Flagsmith Helm chart creates its own database by default, so teams should override that setting for production. The output is a tested restore of the database and a documented upgrade path.
Wire SDKs and CI/CD release gates
Developers add the server-side SDK to the critical services, with the fallback values coded into the application. The pipeline gains a gate that blocks production promotion when a switch for that service is missing or when the flag server is unreachable in staging. The output is a passing test suite that proves each switch flips the behavior it controls and that the fallback is served when the server is down.
Run a canary cohort with rollback drill
The team releases a new feature to a small internal cohort, then to a defined percentage of users, while dashboards for error rate, latency and business metrics are linked to the flag. An on-call engineer then triggers the kill switch in a scheduled drill and records the time from decision to confirmed rollback. The output is a measured rollback time and a runbook updated with what the drill exposed.
Set flag lifecycle and cleanup rules
Owners agree on a rule for every flag type: release flags are removed after full rollout, kill switches are kept and reviewed, and experiment flags are closed when the analysis ends. A recurring review lists stale flags and assigns removal tickets. The output is a written lifecycle policy and a first cleanup report showing which flags were retired and which were kept with a reason.
Integration points that make a kill switch work under load
How does CI/CD integration speed up turning a flag off?
CI/CD integration lets a pipeline create, link and clean up flags as code, so the flag that guards a release exists before the code ships and is named in the same change record. The switch-off speed itself comes from the flag platform, not the pipeline, but a pipeline that deploys without a flag gives you nothing to switch. Common gaps when this is missing:
- Releases ship with no flag, so the only rollback is a redeploy that can take far longer than a toggle.
- Flags are created by hand in a console, with no owner, expiry date or link to the ticket.
- Pipeline checks do not stop a release that removes a flag still referenced by code.
Ask your team to confirm which deployment tool writes flag state and whether that path requires an approval step.
Why do SDK caching and default values matter during an outage?
SDK caching and default values decide what your application does when it cannot reach the flag server, so they set the floor for how safe a kill switch is. Each SDK keeps the last known flag state in memory, and the default value in code is the answer used when no state exists yet. Failures to plan for:
- A kill switch defaults to on in code, so a cold start during an incident re-enables the broken feature.
- Cache TTLs are long, so a toggle takes minutes to reach some services.
- Startup depends on a live call to the server, so a flag outage blocks deployments.
Set defaults to the safe state for each flag and test the behavior with the flag server stopped.
What do edge or proxy layers change for switch-off latency?
Edge or proxy layers sit between the SDKs and the flag API, serving cached flag state close to the services that evaluate it, which reduces latency and load on the central server. Unleash Edge is one example of this pattern, and its open-source version reaches end of life on December 31, 2026, so teams on that path should plan an upgrade. Flagsmith offers optional Edge Proxies for lower latency. Without this layer:
- Every evaluation crosses the network to a central service, which can slow requests at peak load.
- One central instance becomes the single point of failure for all toggles.
- Traffic spikes during an incident can overload the flag server at the moment you need it.
Confirm the edition and support status of any proxy before you depend on it.
How do observability alerts link to feature flags?
Observability alerts linked to flags tell the on-call engineer which flag changed when error rates or latency moved, so the decision to switch off takes minutes rather than a search through deploy history. The link works by tagging metrics, logs and traces with flag names or variant values, then alerting on the same signals that guard each rollout. When this is missing:
- An alert fires with no record of which flagged cohort is affected.
- Engineers toggle a flag in the wrong environment because the names do not match.
- Rollout percentages and error rates cannot be compared, so the team cannot tell whether the change caused the problem.
Ask your observability vendor or team to confirm how flag identifiers reach traces and dashboards in your stack.
Why does identity provider integration matter for toggle authors?
Identity provider integration makes toggle authors sign in through your corporate directory, so every change is tied to a named person, group and role. Who can flip a switch is the control auditors and incident leads care about most. Flagsmith places SAML single sign-on and governance features such as roles, change requests and audit logs at its Scale-Up plan and above, and GrowthBook lists SSO and SCIM as self-hosted Enterprise features. Unleash lists single sign-on and SCIM provisioning under Enterprise. Without this integration:
- Accounts are shared or local, so offboarding does not remove toggle rights.
- Changes cannot be traced to a person during an incident review.
- Break-glass access has no defined path.
Check which edition includes SSO and SCIM before you price the platform.
Can a team set up these integrations without outside help?
Many teams can wire up one or two of these integrations themselves, but the full set usually needs people across platform engineering, security and SRE working in the same change window. The work splits into who owns the pipeline hooks, the SDK defaults, the proxy tier, the alert rules and the identity setup. DeployOpen plans, implements, integrates and documents self-hosted platforms inside your own infrastructure under a written, fixed scope, and it can test the failure paths with you. Your internal time, the edition you choose and the number of services that evaluate flags drive the total effort. Ask any partner for a written scope that names each integration, the owner and the test that proves it works.
What should a kill switch test cover before go-live?
A kill switch test should prove that a flag reaches every consuming service within the time your incident process allows, and that each service falls back to a safe state when the flag server is unreachable. Run the test with real flagged code paths in a staging environment that mirrors production topology, including the proxy tier and cache settings. Include these checks:
- Turn each switch off and measure how long each service takes to reflect the change.
- Stop the flag server and confirm defaults hold after a restart.
- Trigger a synthetic alert and confirm the alert names the flag and environment.
- Attempt a toggle with an account that has no change rights and confirm it is refused and logged.
Keep the results as evidence for the release and incident runbooks.
What change evidence auditors ask for from flag toggles
This table lists the evidence an assessor typically samples when a feature flag changes production behavior, and the component that produces each item. Use it to decide which records your platform, CI/CD pipeline and observability stack must retain before an audit. Regulatory mapping is for your auditors to judge; DeployOpen prepares the evidence but does not issue attestations.
| Evidence item | What it shows | Where it usually comes from | What to confirm |
|---|---|---|---|
| Toggle history | Who changed a flag, when, and from which value to which value | Platform audit log in the self-hosted flag service | Which edition provides audit logs and how long entries are retained |
| Approval records | A second person reviewed and approved a production toggle before it took effect | Enterprise change requests (GrowthBook approval workflows, Unleash change requests, Flagsmith change requests) | Whether the edition you need includes change requests and whether approvals are enforced, not just recorded |
| Role assignments | Who could change production flags at the time of the change | Platform role and permission configuration, exported on a schedule | Whether roles are project-scoped and whether SSO and SCIM provisioning feed the role list |
| Deployment linkage | The flag change is tied to the release or incident ticket it belongs to | CI/CD logs and pipeline run records that call the flag API | Whether pipeline service accounts are separate from named human users |
| Rollout progression | The percentage or cohort steps taken and the monitoring checks at each step | Platform audit log combined with observability exports of error rates and conversion | Whether metric snapshots are stored outside the dashboard tool |
| Kill switch test results | The off switch was exercised and took effect within the agreed window | Scheduled drill records from the runbook, with timestamps from the SDK or edge layer | Whether drills run in production-like environments and results are signed off |
| Cleanup records | Stale flags were removed or archived, with owner sign-off | Flag inventory export and tickets closing each flag | Whether a flag lifecycle policy defines a review date for each flag |
| Configuration exports | The configuration in force on a given date can be reproduced | Environment export as JSON, stored under version control or in an evidence store | Whether segments and custom strategies are exported too, since they are referenced rather than copied |
What to ask an implementation partner before a kill switch goes live
Start by asking how the partner measures switch-off time. A kill switch is only useful if the time from toggle to behavior change is measured in the environment that will run it, not assumed from a vendor page. Ask for a test that flips a flag on a production-like stack, shows the change reaching each SDK and edge layer, and records the result in the change ticket. Ask which caching layers sit between the SDKs and the flag server, because an Unleash Edge or Flagsmith Edge Proxy deployment changes that path. Also ask which components are past or near end of life. The Unleash Edge documentation gives open-source Edge an end-of-life date of December 31, 2026, so confirm that date and the upgrade route before go-live.
Ask which edition the quote is built on and why. The open-source and enterprise tiers differ in ways that matter here: Unleash Open Source is limited to one project and two environments, Flagsmith's governance features such as roles, change requests and audit logs start at its Scale-Up plan, and GrowthBook's safe rollouts and approval workflows sit in its self-hosted Enterprise tier. Ask the partner to show which of these features the kill switch process depends on, and to state who approves a flag change and where that approval is recorded. Ask how SDK defaults are set, meaning the value every client falls back to when the flag service is unreachable, and whether the partner will write those defaults into code review rather than leave them in the admin console.
Ask how flag cleanup is governed. Stale flags accumulate fast and make kill switches harder to reason about, so request a named owner, an expiry or review date on each flag, and a removal step in the delivery pipeline. For upgrades, ask how the partner tests new releases of the flag server and SDKs in staging before production, and who carries the work when a component reaches end of life. Finally, make sure the fixed scope is written so that switch-off testing, default configuration, cleanup rules and upgrade responsibilities each have a named deliverable, an acceptance check and an owner. Items left out of the written scope are where kill switches tend to fail in practice.
What progressive delivery with open source flags costs and needs
What does it cost to run open source feature flags for progressive delivery?
The software licence is often free, but the spend sits in three places: the infrastructure that hosts the flag service, the Enterprise subscription if you need governance features, and the staff time to wire SDKs and maintain flags. The self-hosted Open Source plans carry no subscription fee. GrowthBook's pricing page lists its self-hosted Open Source plan as free with unlimited users, 1 project and unlimited API requests. Unleash's pricing page lists Open Source as free and self-hosted with 1 project, 2 environments and 5,000 feature flags per instance. Enterprise tiers add cost. Unleash lists Pay-As-You-Go at $75 per seat per month with a 5-seat minimum for self-hosted, and Flagsmith lists Start-Up at $40 per month billed yearly. Ask any vendor to confirm current pricing in writing, because these figures change.
Which features push a self-hosted flag platform into an Enterprise plan?
The features that matter most for controlled releases are usually gated behind paid editions. Check these first:
- Single sign-on and SCIM provisioning, which centralize access for the people who can flip a kill switch.
- Roles, permissions, change requests and audit logs, which create the approval trail a release process may need.
- Approval workflows and safe rollouts, which control how a percentage rollout advances.
On Flagsmith's pricing page, SAML single sign-on and governance features start at the Scale-Up plan. On GrowthBook, self-hosted Enterprise adds SSO, SCIM, approval workflows, safe rollouts, ramp schedules and holdouts. Unleash Enterprise adds single sign-on, SCIM, custom roles and change requests. Confirm which of these your access and audit rules require before you pick an edition.
How much internal staff time does SDK wiring and flag cleanup take?
Staff time is usually the largest recurring cost, and it is not published by any vendor. It falls into three phases: initial SDK integration in each service, kill switch and rollout runbooks, and ongoing cleanup of stale flags. Effort rises with the number of services, languages and mobile or edge clients that evaluate flags, and with how many flags exist without an owner or expiry date. Ask your team to inventory services and SDK languages before requesting a quote, since that inventory is the main input to any estimate. A flag lifecycle policy that sets removal dates reduces cleanup work later.
How long does a progressive delivery rollout take to set up?
The timeline is set by phases, not a fixed duration, and each phase depends on the scope agreed in writing. A typical sequence runs through platform installation and identity setup, SDK integration in a pilot service, a canary cohort with observability hooks, then a rollout of kill switch runbooks across production services. Each phase ends with a test that a flag change takes effect. Most engagements are fixed-scope, so timelines are agreed in writing before work starts. Ask for the phase list, the exit criteria for each phase and the services included in the first release of the rollout.
What does the client team need to provide before implementation starts?
The client team supplies the environment and the decisions. Expect to provide:
- Cloud accounts, a Kubernetes cluster or virtual machines, and a managed PostgreSQL or MongoDB database where production requires one.
- Identity provider access for single sign-on, and named owners for each flag environment.
- A list of services and clients that evaluate flags, including mobile apps and any edge caches.
- Observability tooling access, so flag state can be correlated with error rates and latency.
- Decisions on the flag lifecycle policy, approval rules and who may operate a kill switch.
Missing inventory or unclear ownership are the most common causes of delay.
Can our own engineers run progressive delivery without an implementation partner?
Yes, if your team has container operations experience and at least one engineer who owns SDK integration. Both Unleash and Flagsmith publish self-hosting guides based on Docker and Kubernetes, and GrowthBook maintains an official Helm chart. The work that tends to stall internal teams is production hardening: database backups, upgrades, access controls, and runbooks that the on-call team can execute during an incident. A partner can plan, implement, harden, document and support the platform inside your infrastructure, and ongoing support is available as a retainer. Compare the cost of internal staff time against a fixed-scope engagement before deciding.
What drives the operating cost of self-hosted flags up over time?
Recurring costs grow with the number of environments, seats, services and evaluation traffic. Hosting costs rise with request volume and with the number of edge or proxy layers you add for latency. Subscription costs rise with seats and with plan tiers, since Flagsmith charges extra API calls on its Free, Start-Up and Scale-Up plans at $50 per million per month. Upgrades, security patches and backup testing recur on every platform, whether self-hosted or SaaS. Ask vendors to confirm how their editions meter seats, requests and environments before you model the first year.
Which risks should a kill switch design address before go-live?
A kill switch only works if the flag service is reachable and the SDKs keep their last known values. Plan for these risks:
- Flag service outage, handled through SDK caching, default values set in code and, where needed, an edge layer.
- Unauthorized flag changes, handled through role-based access, approvals and audit logs.
- Flag sprawl, handled through owners, expiry dates and scheduled removal.
Test each kill switch in a non-production environment, and record who is authorized to switch it off in production.
How DeployOpen scopes and supports progressive delivery
DeployOpen starts every progressive delivery engagement with a written, fixed scope that names the flag platform and edition, the environments, the SDKs and services that evaluate flags, the CI/CD pipelines and observability tools to be connected, and the roles that may change a production flag. Deliverables and timelines are agreed before work begins, so the kill switch path, the rollout rules and the flag lifecycle policy are defined as part of the contract rather than discovered during build. Before scoping, confirm which edition your team needs: the free self-hosted tiers differ on projects, environments, SSO, SCIM, roles and change requests, and those differences decide which controls can be enforced in the platform itself.
DeployOpen deploys the chosen platform inside your own cloud accounts, data centers or air-gapped networks, including the database, cache and any edge or proxy layer that sits between SDKs and the flag service. Hosting decisions in the scope cover where targeting attributes are evaluated, how flag configurations move between environments, and how images and updates reach the network. DeployOpen also runs security testing of the flag path itself: the admin interface, the API tokens used by pipelines, the SDK keys shipped to clients, and the failure behavior when the flag service is unreachable. Findings are reported against the scope so they can be fixed or accepted in writing.
After go-live, support is delivered through a retainer agreed separately from the implementation scope. A retainer typically covers upgrades to the platform, patching, backup verification, drills of the kill switch procedure, and periodic reviews of stale flags and permissions. Ask any partner, DeployOpen included, to state in writing what the retainer covers, who responds to an incident and through which channel, and how upgrades are tested against your flag definitions before they reach production. Confirm the current support and maintenance status of your chosen release with the vendor, since release support windows differ between projects.
