Feature flags in 2026: revisit Unleash, Flagsmith and GrowthBook before you hard-code another release toggle

Manoj Shukla
October 12, 2026

Picture a test-preparation and online classes platform in Jaipur (an invented example, not a real client). Students use an Android app, an iOS app and a React web app. The backend is a set of Java and Go services on Kubernetes, with PostgreSQL for accounts and payments. Every release toggle today is a boolean in a ConfigMap or an if (city == "Kota") buried in code, so turning off a broken mock-test screen in exam season means a hotfix build and a store review. The platform team has agreed to adopt a real feature flag service and to self-host it. One architect proposes Unleash because it is the oldest of the three, runs on PostgreSQL, and evaluates flags inside the backend SDKs. A second prefers Flagsmith for its remote config values, trait-based segments and BSD-licensed core. A third argues for GrowthBook because the product team wants experiments with proper statistics on top of the same flags, using the warehouse they already pay for.

All three are open-source or open-core feature management platforms that you can run on your own servers. They are not configuration management tools, not a secrets store and not a replacement for a deployment pipeline. This post compares Unleash, Flagsmith and GrowthBook on where evaluation happens, SDKs, targeting, rollout behaviour, self-hosting operations, licences and security. Facts come from release notes, official docs and their source repositories, licence files and CVE records, checked on 12 October 2026. The drill near the end is my own run on this Linux box.

The short version

A feature flag platform moves a decision from build time to run time. The useful part is not the toggle; it is targeting, sticky percentage rollouts, audit history and a kill switch that works when the release team is asleep.
Unleash 8.2.0 (8 September 2026, 3:27 PM IST) is the current tip. From v8.0.0 the source code and the unleash-server npm package are AGPLv3; the official open-source Docker images stay Apache 2.0 and the SDKs keep permissive licences. The open-source Unleash Edge is in maintenance and reaches end of life on 31 December 2026.
Flagsmith 2.282.0 (12 October 2026, 2:28 PM IST) is the current tip of a fast release train. The core is BSD 3-Clause. RBAC, SAML and LDAP, change requests and some database backends are in the closed Enterprise Edition images.
GrowthBook 5.1.0 (22 September 2026, 8:37 AM IST) is the current tip. The core is MIT; three enterprise directories carry the GrowthBook Enterprise License. It needs MongoDB (or a compatible store such as FerretDB) for its own state, and it is strongest when experiments and warehouse metrics matter as much as flags.
Pick by the main job: plain release and ops toggles with server-side evaluation lean Unleash; remote config with identity traits and an all-PostgreSQL stack lean Flagsmith; flags that must turn into measured experiments lean GrowthBook. Put OpenFeature in front of whichever you choose.
In my drill, Unleash 8.2.0 ran from npm on PostgreSQL 18 and a 10 percent rollout over 100,000 users landed at 9.99 percent. Raising it to 25 percent reached the SDK in about one second and kept every original user. The Flagsmith and GrowthBook SDKs gave 9.96 and 10.21 percent offline. The three 10 percent groups shared only 97 users, so changing tools reshuffles who sees a feature.

Where things stand on 12 October 2026

Dates are from each project’s GitHub release page; times are converted from UTC to IST. Licences are from the LICENSE files at the tagged release.

Project

Release

Date (IST)

Notes

Licence

Unleash

8.2.0

8 September 2026

Current tip; created-by filter; fixes for several cross-project authorisation bugs and secure storage of personal and service account tokens

AGPLv3 source; Apache 2.0 official OSS Docker image

Unleash

8.0.0

9 June 2026

AGPLv3 move; release templates, impact metrics and safeguards made generally available (Enterprise features); new sunset flag type

AGPLv3 source

Unleash

7.6.5 and 7.5.2

29 June 2026

Security backports on the 7.x lines

Apache 2.0

Unleash Edge

20.6.0

7 October 2026

Open-source build in long-term maintenance; end of life 31 December 2026

MIT, except enterprise crates

Flagsmith

2.282.0

12 October 2026

Current tip; updated_at on traits; experimentation refactors

BSD 3-Clause core

Flagsmith

2.280.0

5 October 2026

Fix: publishing a feature version could bypass change requests; flag dependency work

BSD 3-Clause core

Flagsmith Edge Proxy

2.23.0

15 May 2026

Separate container that serves environment documents

BSD 3-Clause

GrowthBook

5.1.0

22 September 2026

Current tip; contextual bandits (beta), funnel metrics, targeting projects, composable permissions, atomic publishing (beta)

MIT core plus Enterprise License directories

GrowthBook

5.0.1

19 August 2026

Fixes a critical self-hosted account takeover for local email and password login

MIT core plus Enterprise License directories

GrowthBook

5.0.0

20 July 2026

Agent skills and CLI, Custom Hooks V2, JSON Schema checks for flag values, Configs, product analytics GA

MIT core plus Enterprise License directories

GrowthBook Proxy

1.4.0

13 August 2026

Optional caching and streaming proxy

MIT

OpenFeature

ongoing

n/a

Vendor-neutral flag API; CNCF incubating project

Apache 2.0

Date (IST)

Event

29 September 2014

Unleash repository created on GitHub

5 June 2018

Flagsmith repository created on GitHub

8 May 2021

GrowthBook repository created on GitHub

25 January 2022

GrowthBook 1.0.0

6 June 2024

Unleash 6.0.0

17 November 2024

CVE-2024-52871 and CVE-2024-52872 published for Flagsmith (fixed in 2.134.1)

11 June 2025

Unleash 7.0.0

9 July 2025

GrowthBook 4.0.0

26 May 2026

Unleash pull request “Move to AGPL-v3” merged

2 June 2026

Unleash blog announces the AGPLv3 move

9 June 2026

Unleash 8.0.0, first AGPLv3 release

10 July 2026

Unleash 8.0.3 with a batch of authorisation fixes

20 July 2026

GrowthBook 5.0.0

19 August 2026

GrowthBook 5.0.1 (account takeover fix)

8 September 2026

Unleash 8.2.0

22 September 2026

GrowthBook 5.1.0

12 October 2026

Flagsmith 2.281.0 and 2.282.0

31 December 2026

Scheduled end of life for open-source Unleash Edge

Two things in this table change the comparison compared with a year ago. First, Unleash is no longer Apache 2.0 at the source level. Second, Unleash pushes its edge caching layer towards the Enterprise build. Both matter for a self-hosting team; neither makes Unleash a bad fit, so I kept all three products and did not swap one for an OpenFeature-only backend such as flagd or Flipt.

First question: do you need a feature-flag service at all?

A flag service is one more production dependency, with its own database, upgrades, tokens and on-call surface. It pays for itself only when decisions change more often than deployments.

Stay with config files, environment variables or a ConfigMap when:

a handful of switches change once a quarter and a redeploy is cheap;
there is no need to target a city, plan, app version or user percentage;
one team owns every service that reads the switch;
an audit trail of “who turned this on” is already covered by Git history.

Move to a flag platform when:

you want trunk-based development with unfinished work merged but dark;
mobile releases make a hotfix slow, so a remote kill switch is worth real money;
product managers or support staff, not only engineers, must change targeting;
you need sticky percentage rollouts (5 percent, then 25, then 100) with the same users staying in;
you want every change recorded, reviewed and reversible without a build;
experiments need consistent assignment and analysis instead of ad-hoc random numbers.

A middle path is OpenFeature with a file-based provider such as flagd: a standard API in code, no server UI, and a later move to a full platform without touching call sites. For the Jaipur team, the mobile kill switch alone justifies a service.

What a feature flag platform actually does

Every platform here has the same three parts: an admin service with a UI and API, a store for flag definitions and audit events, and SDKs in your applications. The important design choice is where the rule is evaluated.

Evaluation model

How it works

Where you see it

Server-side local evaluation

Backend SDK downloads all flag rules, caches them in memory and evaluates in-process. No network call per check; changes arrive on the next poll or stream event.

Unleash backend SDKs; Flagsmith server SDKs in local evaluation mode; GrowthBook backend SDKs

Remote evaluation

SDK sends the user context to a service, which returns evaluated flags. Rules stay private; each fresh context costs a request.

Unleash frontend SDKs via the Frontend API or Edge; Flagsmith client SDKs and remote mode; GrowthBook remote evaluation via Proxy

Client-side local evaluation

Browser or mobile app downloads a rules payload and evaluates locally. Fast, but anyone can read the rules unless you encrypt or hide them.

GrowthBook client SDKs by default

Local evaluation keeps personal data inside your application. Unleash says plainly that backend SDKs never send user data to the Unleash server. Flagsmith’s local mode uses only the traits passed in at runtime and does not persist them. GrowthBook’s SDK payload is a JSON document that can be cached on a CDN; its docs warn that feature rules are visible to users unless you use remote evaluation.

Unleash

Unleash is a Node.js service on PostgreSQL. The current self-hosting guide pairs it with PostgreSQL 15 or newer, and the 8.2.0 package.json declares Node 22 or newer. It exposes three APIs: the Client API for backend SDKs, the Frontend API for browser and mobile SDKs, and the Admin API for the UI and automation. Backend SDKs fetch the whole flag configuration and evaluate locally; frontend SDKs fetch already-evaluated flags for one context.

Targeting is built from activation strategies. The default gradual rollout uses a normalised MurmurHash of a stickiness field (user ID, session ID or a custom field) combined with a group ID, so the same user stays in the same bucket. Constraints add AND conditions using string, numeric, date and SemVer operators; 8.0.3 added SemVer greater-or-equal and less-or-equal operators. Several strategies on one flag are combined with OR. Variants carry payloads for simple A/B or remote config cases. Flag types (release, experiment, operational, kill switch, permission, and now sunset) feed lifecycle and stale-flag reports.

The open-source build is deliberately narrower than Enterprise. The README lists RBAC, SSO, more environments, project support, advanced segmentation and additional strategy constraints under paid plans. Change requests, release templates, impact metrics and safeguards are Enterprise features. That is fine for a small team with two environments; a regulated platform that needs four-eyes approval on production flags should budget for Enterprise.

Unleash Edge is a Rust caching layer between SDKs and the server. It reduces load and can evaluate for frontend SDKs so user data never reaches the main server. The open-source Edge is in long-term maintenance with end of life on 31 December 2026, and Enterprise Edge requires Unleash Enterprise 7.3 or later. If you self-host the open-source server and expect very large frontend traffic, plan for the server’s own Frontend API, a CDN pattern, or an Enterprise contract.

Flagsmith

Flagsmith is a Django and Django REST Framework API with a React dashboard, storing everything in PostgreSQL. The quick-start Docker Compose bundles dashboard and API on one port. An optional asynchronous task processor runs from the same image with a different entrypoint and can use the main database or a separate one; without it, the API runs background tasks in an unmanaged thread. The Edge Proxy is a separate container with no external dependencies that downloads environment documents and answers SDK requests.

The data model is organisations, projects, environments, features, identities, traits and segments. Each feature can be a boolean, carry a remote config value, or be multivariate with percentage weights. Segments are rule trees with operators such as equals, in, regex, SemVer, is set, modulo and percentage split. The percentage split hashes the segment and the identity key with MD5, so a user’s bucket is stable per segment. Identity overrides can force a value for one user. October 2026 releases added flag dependency work (prerequisites and a Dependencies tab).

Server SDKs run in remote mode (a blocking call per flag fetch, with traits persisted against the identity) or local mode (poll the environment document and evaluate in-process using a server-side key). Client SDKs use remote evaluation with a public client-side key.

The open-source edition has no API request limits, but the FAQ is clear that RBAC, SAML and SSO, and certain database integrations are closed-source Enterprise features. The Enterprise images add SAML, LDAP, workflows (change requests and flag scheduling), and on the full EE image Oracle and MySQL support. Enterprise deployments also need an uploaded licence file and signature.

GrowthBook

GrowthBook ships one Docker image with a Next.js front end, an Express API and a Python statistics engine. Its own state (users, flags, experiment metadata, cached results) lives in MongoDB. The docs suggest a managed MongoDB-compatible service for production, warn that Azure Cosmos DB is not a supported replacement, and document FerretDB on PostgreSQL for teams that want a fully open-source store. Containers are stateless and scale horizontally; the production guide suggests at least 2 GB RAM and one vCPU per instance and at least three instances for fault tolerance, with an optional separate jobs server for heavy statistics work. The runtime image is now a distroless, non-root image.

Flags are typed (boolean, string, number, JSON) with rules evaluated in order: forced values, percentage rollouts, experiments, and safe rollouts that watch guardrail metrics. Targeting uses attributes, saved groups and prerequisite features. Rollouts hash an attribute with GrowthBook’s own FNV-1a based function, with a hash version setting. Sticky bucketing keeps users in a variation when targeting changes mid-experiment. 5.0 added JSON Schema validation for string and number flags, unreachable rule detection, constants and Configs for structured JSON flags. 5.1 added targeting projects and an atomic publishing endpoint in beta.

What sets GrowthBook apart is the experimentation layer. It connects to your warehouse (BigQuery, Snowflake, Redshift, ClickHouse, PostgreSQL and others) and runs SQL to compute results, so assignment data and metrics stay in your systems. The production guide reminds you that GrowthBook runs user-defined SQL, so give it a least-privilege, read-only warehouse user. Approval flows, SSO and SCIM are Enterprise features.

Architecture side by side

Aspect

Unleash 8.2

Flagsmith 2.282

GrowthBook 5.1

Server language

Node.js (TypeScript)

Python (Django)

Node.js (TypeScript) plus Python stats engine

Own state store

PostgreSQL

PostgreSQL (Oracle and MySQL on Enterprise image)

MongoDB or compatible (FerretDB documented)

Optional extra components

Unleash Edge (OSS build ends 31 December 2026)

Task processor, Edge Proxy, InfluxDB for analytics

GrowthBook Proxy, CDN, jobs server

Backend evaluation

Local in SDK

Remote or local (server key)

Local in SDK

Frontend evaluation

Remote via Frontend API or Edge

Remote via client key

Local from payload, or remote via Proxy

Change propagation

SDK polling (configurable); Enterprise streaming to Edge in beta

Local mode polls the environment document; remote mode fetches per request

SDK refresh, streaming through the Proxy (JavaScript and React), or SDK webhooks

Experiment analysis

Variants and impression events; analysis in your tools

Multivariate flags; experimentation features growing

Built-in stats over your warehouse

SDKs and OpenFeature

All three have official SDKs for the usual server languages (Java, Go, Python, Node.js, .NET, PHP, Ruby) and for browsers, React, iOS, Android and Flutter. Unleash’s README counts 15 official SDKs plus community ones. Flagsmith says more than 15 languages. GrowthBook’s SDK index lists over twenty, including edge workers for Cloudflare, Fastly and Lambda@Edge.

OpenFeature is the safer seam. It is a CNCF incubating project that defines one evaluation API with pluggable providers. Flagsmith lists providers for Go, Java, .NET, JavaScript (web and server), Kotlin, Python, Ruby, Rust and Swift, and sits on the OpenFeature governance board. GrowthBook documents providers for JavaScript, Python, Go, .NET and Java. Unleash documents OpenFeature providers for Node.js, PHP, Python, Ruby, Rust and Swift. Check provider maturity per language before you rely on it; native SDKs usually get new features first.

For the Jaipur team: application code calls OpenFeature, a thin wrapper sets the evaluation context (user ID, city, plan, app version), and the provider choice lives in one place. A later migration then costs configuration and testing, not a rewrite.

Targeting and rollout behaviour

Capability

Unleash

Flagsmith

GrowthBook

Sticky percentage rollout

Gradual rollout, MurmurHash3 of groupId:userId

Percentage split segment, MD5 of segment and identity key

Rollout rule, FNV-1a hash of attribute and seed

Attribute targeting

Constraints on context fields; segments

Segment rules on traits

Targeting conditions on attributes; saved groups

Dependencies

Parent and child flags

Prerequisites (new in late 2026)

Prerequisite features

Values beyond on/off

Variants with payloads

Remote config values, multivariate

Typed values, JSON with schema, Configs

Experiments

Variants plus impression data; Enterprise impact metrics

Multivariate splits; experimentation features in progress

Full experiment design and analysis, bandits

Scheduled or staged changes

Release templates and safeguards (Enterprise)

Scheduled changes (Enterprise workflows)

Ramp schedules, safe rollouts

Review before publish

Change requests (Enterprise)

Approval flows (Enterprise)

The hashing row matters more than it looks. Each tool assigns buckets with a different function and a different seed. A 10 percent cohort in Unleash is not the same 10 percent in Flagsmith or GrowthBook. My drill measured this directly.

Self-hosting operations

Day-two task

Unleash

Flagsmith

GrowthBook

Minimum stack

One Node process plus PostgreSQL

API image plus PostgreSQL (frontend bundled in quick start)

One image plus MongoDB

Schema changes

Migrations at start-up

Django migrations at start-up

No SQL migrations; follow release notes

Scaling

Stateless server replicas; SDK caching; Edge where licensed

Gunicorn workers and threads; task processor; Edge Proxy

Stateless replicas; Proxy or CDN for SDK traffic

Backups

PostgreSQL backup and restore drill

MongoDB backup plus uploads storage (local volume, S3 or GCS)

Secrets to manage

API tokens (admin, client, frontend), DB credentials

Server and client environment keys, Django secret, DB credentials

JWT secret, encryption key for data source credentials, API keys, MongoDB URI

Observability

Prometheus endpoint; SDK usage metrics

Prometheus metrics, structured events, OpenTelemetry export

App logs; watch stats jobs and warehouse query cost

Release rhythm

Monthly minors with patch lines

Frequent, often several in a week

Periodic stable tags; latest tracks main

Three practical notes. First, a flag service must fail safe. SDKs cache the last known configuration in memory, and Unleash SDKs also write a backup file, so a server outage freezes flags rather than flipping them. Test this. Second, keep the admin service off the public internet. GrowthBook’s production guide recommends a firewall or VPN with only the Proxy or a CDN path for /api/features/* exposed; the same idea applies to the Unleash Admin API and the Flagsmith dashboard. Third, run PostgreSQL for Unleash or Flagsmith like any other important database: connection pooling, backups and a failover plan. My earlier posts on PgBouncer and its alternatives and PostgreSQL high availability with Patroni and CloudNativePG apply directly.

Flag definitions also belong near Git. All three have admin APIs, and teams often keep flag creation in Terraform-style code or CI scripts while leaving runtime targeting in the UI. If your clusters already run GitOps, see Argo CD and Flux for how far to push that model; flags that change many times a day are a poor fit for a pull-request loop.

Licences and the open-core line

Item

Unleash

Flagsmith

GrowthBook

Core source

AGPLv3 from 8.0.0 (Apache 2.0 before)

BSD 3-Clause

MIT (Expat) outside enterprise directories

Official OSS container

Apache 2.0 per Unleash

Same image family as source

Same image; enterprise code needs a licence key

SDKs

Permissive (unchanged)

Permissive (for example BSD and MIT packages)

MIT

Paid-only areas

RBAC, SSO, projects, change requests, release templates, impact metrics, Enterprise Edge

RBAC, SAML, LDAP, change requests and scheduling, Oracle and MySQL

SSO, SCIM, approval flows and other enterprise directory features

The Unleash change is narrower than it first sounds. The announcement says running the official Docker image without modification is unaffected, SDKs are unaffected, and AGPLv3 duties apply when you modify Unleash and offer it to users over a network. If your company bans AGPL code outright, the pre-built container under Apache 2.0 is the documented answer, but get your legal team to read the actual texts. Forking Unleash 7.x to stay on Apache 2.0 means owning security backports yourself.

GrowthBook’s Enterprise License allows modification for development and testing, but production use of the enterprise directories needs a paid subscription. Flagsmith’s Enterprise features are not in the public repository at all. Whichever you pick, write down which edition provides each feature you rely on, so nobody discovers a paywall during an incident.

Security and CVEs

I checked NVD keyword searches, the CVE Program records on cveawg.mitre.org and each repository’s GitHub security advisories on 12 October 2026. Publication dates are converted to IST, so a few fall a day after the UTC date.

Product

Published

Summary

Fixed in

CVE-2026-63462

Unleash

21 August 2026

Unauthenticated deeply nested JSON crashes the Node process through the OpenAPI validation error path (CVSS 3.1: 7.5)

7.5.2, 7.6.5, 8.0.2

CVE-2026-63004

Unleash

21 August 2026

Addon and integration webhook URLs not filtered for internal addresses, enabling SSRF by users with addon permissions (5.5)

7.5.2, 7.6.5, 8.0.2

CVE-2026-77426

Unleash

23 September 2026

Five admin API authorisation flaws, including a missing await on a permission check (CVSS 4.0: 7.1)

8.0.3

CVE-2026-76910, CVE-2026-77425, CVE-2026-63466, CVE-2026-76909

Unleash

August to September 2026

Cross-project clone and strategy reorder, Mustache escaping disabled process-wide, HTML in approval emails

8.0.3

GHSA-639f-52mg-grrc and three related advisories

Unleash

8 September 2026 (GitHub)

Cross-project IDOR on variants and feature dependencies; Enterprise SSO domain allowlist bypass

8.2.0

CVE-2024-52871

Flagsmith

17 November 2024

Bypass of ALLOW_REGISTRATION_WITHOUT_INVITE (7.5)

2.134.1

CVE-2024-52872

Flagsmith

17 November 2024

get_document endpoint not protected by permissions (7.5)

2.134.1

GHSA-c4m3-8cgx-p88g

GrowthBook

20 August 2026 (GitHub, critical)

Unauthenticated account takeover on self-hosted local email and password login via cookie JSON parsing

5.0.1

CVE-2026-91198

GrowthBook

15 September 2026

Public shared reports and experiments return raw warehouse SQL and schema details (5.3)

Record lists versions through 5.0.1; the linked GitHub issue was still open when I checked

CVE-2022-36065

GrowthBook

7 September 2022

Account creation and arbitrary file upload in weak self-hosted configurations

Commit of 29 August 2022

Read this as a pattern, not a scoreboard. Most recent Unleash issues are cross-project authorisation bugs, which bite hardest in multi-team instances. The GrowthBook takeover hit self-hosted installs using local login; Cloud and SSO users were not affected. Flagsmith’s public record is quieter and its repository showed no published GitHub advisories, but watch its [security] dependency notes in release logs.

Practical controls for all three:

Put the admin UI and admin API behind SSO or a VPN; expose only SDK endpoints, ideally through a proxy or CDN path.
Use separate tokens per environment and per application; never ship a server-side key in a mobile app.
Treat flag changes in production as privileged: audit logs on, review where your edition supports it.
Keep up with patch releases; subscribe to each repository’s security advisories.
If you use GrowthBook public report sharing, review what each shared report reveals until CVE-2026-91198 is clearly fixed.
For webhooks and integrations, restrict outbound traffic from the flag server at the network layer, whatever the application filters.

If you already run Keycloak, connecting the flag admin UI to it is the cleanest way to get offboarding right. The open-source editions mostly lack SSO, so this is often the first Enterprise feature teams pay for. See my post on Keycloak and its alternatives.

Prefer each when

Prefer

When

Unleash

You want mature server-side local evaluation, PostgreSQL only, strong flag lifecycle and stale-flag hygiene, and you are comfortable with AGPLv3 source or the Apache 2.0 container

Flagsmith

You need remote config values and trait-based segments as much as on/off flags, a permissive BSD core, PostgreSQL only, and a choice between remote and local evaluation per service

GrowthBook

Product teams will run real experiments, metrics already live in a warehouse, you want typed and schema-validated JSON flags, and MongoDB or FerretDB is acceptable to operate

OpenFeature with flagd or Flipt

You need a standard API and Git-reviewed flag files, with no product UI or experimentation yet

Decision guide

Situation

Lean toward

Why

Backend-heavy services, ops toggles and kill switches

Unleash

Local evaluation, clear strategy model, backup files in SDKs

Mobile apps that need remote config without a store release

Flagsmith or GrowthBook

Rich values and client SDKs; GrowthBook also evaluates locally on the device

Legal policy forbids AGPL anywhere

Flagsmith or GrowthBook, or Unleash official container after review

BSD and MIT cores; Unleash container stays Apache 2.0

Experimentation is a stated goal this year

GrowthBook

Warehouse-native analysis and statistics engine

Team runs PostgreSQL well, no MongoDB skills

Unleash or Flagsmith

One database type to back up and fail over

Regulated change control on production flags

Any, on Enterprise

Change requests and approvals are paid features in all three

For the Jaipur platform, my calm recommendation is:

Standardise on OpenFeature in the Java, Go and React code first, with a small wrapper for evaluation context.
Choose Flagsmith if the main need this year is remote config and mobile kill switches on a PostgreSQL-only stack, or Unleash if most flags are backend release toggles. Choose GrowthBook if the product team will really run experiments every month and someone will own MongoDB.
Do not run two flag platforms side by side for long. One platform, one naming convention, one clean-up process.

Checklist before you standardise

Write a flag naming convention and a required owner and expiry date for every release flag.
Decide the evaluation model per client: local for backends, remote or proxied for browsers and apps.
Define the evaluation context once (user ID, anonymous ID, city, plan, app version) and use the same keys in every SDK.
Prove a server outage: kill the flag server and confirm applications keep the last known values.
Prove a rollout ramp: 10 to 25 to 50 percent keeps earlier users in.
Put admin access behind SSO or VPN; issue per-environment tokens.
Back up the store (PostgreSQL or MongoDB) and run one restore.
Pin server and SDK versions; read release notes for security fixes monthly.
List which features you use are Enterprise-only in your edition.
Add a stale-flag review to every sprint or monthly operations meeting.

Common mistakes

Treating flags as permanent configuration. Release flags should die within weeks; long-lived ops flags need a different type and owner.
Shipping server-side keys in mobile or browser code.
Using different user ID fields across services, so the same user lands in different buckets.
Migrating platforms and assuming the same 10 percent of users stays in the rollout. It will not.
Exposing the whole admin service to the internet because the SDKs need one endpoint.
Running experiments on a flag tool without checking who analyses the results and how.
Ignoring the licence of the exact artefact you run (source build versus official container).

A drill I ran on 12 October 2026

Environment: shared Linux VM, 8 vCPU, about 15 GiB RAM, no root, no Docker, loopback only. Between about 10:45 and 10:52 PM IST I ran:

PostgreSQL 18.6 (binaries from an earlier drill) and Node.js 22.23.3 (official tarball, checksum verified).
unleash-server 8.2.0 from npm, with an admin token and a development client token, plus unleash-client 6.12.2 for Node.
Flagsmith SDKs (Python 6.3.0 and Node 8.1.2) in offline mode against a hand-written environment document, and GrowthBook SDKs (Python 3.2.1 and Node 1.8.0) against a hand-written features payload. I did not run the Flagsmith or GrowthBook servers: without Docker, Flagsmith needs its Django API and dashboard stack, and GrowthBook needs MongoDB or FerretDB.

Workload: one boolean release flag at 10 percent, sticky on user ID, checked for 100,000 IDs from user-0 to user-99999.

Unleash 8.2.0 server (PostgreSQL 18.6, empty database)
  ready after ~1.1 s (397 migration rows, 109 tables), RSS ~150 MiB, DB 13 MB
  Admin API: create flag 201, add gradual rollout 10% 200, enable 200
  client payload: 490 bytes
  SDK sweep: 9,995 on (9.99%), ~0.7 us per isEnabled, same set on rerun
  change 10% -> 25% via Admin API: SDK saw it after 1,034 ms (1 s poll)
  after: 25,039 on (25.04%), all 9,995 original users still on
  server killed, new SDK process: 25,039 on from backup file

Flagsmith SDK offline (percentage split segment 10%)
  Python 6.3.0: 9,962 on (9.96%), ~8 us per get_identity_flags
  Node 8.1.2:   9,962 on, ~4.4 us per call
  raise to 25%: 24,843 on, all 9,962 kept

GrowthBook SDK (rollout rule coverage 0.1 on id)
  Python 3.2.1: 10,208 on (10.21%), ~4.6 us per eval (reused instance)
  Node 1.8.0:   10,208 on, ~1 us per eval
  no id attribute: off
  raise to 25%: 25,275 on, all 10,208 kept

Overlap of the three 10% groups
  Unleash & Flagsmith 974, Unleash & GrowthBook 990, Flagsmith & GrowthBook 994
  all three: 97 (independent random sets would give about 1,000 pairwise)

What this shows:

All three keep percentage rollouts sticky and monotonic: raising the percentage only adds users. That is the behaviour you want for staged releases.
Python and Node SDKs of the same product agreed exactly, which is reassuring for mixed-language estates.
The cohorts of different products are essentially independent. If you migrate from Unleash to Flagsmith mid-rollout, about nine in ten users in the current 10 percent will drop out and a different 10 percent will join. Finish or pause rollouts before migrating, or accept the reshuffle.
Evaluation cost is microseconds in-process for all three. The real latency question is network and propagation, not the hash.
The Unleash SDK kept serving the last configuration from its backup file with the server down, as designed.

Limits of the drill: one VM and loopback; one run each; no Flagsmith or GrowthBook server, so no UI, API or propagation tests for them; no Edge, Edge Proxy or GrowthBook Proxy; no frontend SDKs; no Enterprise features such as SSO, RBAC or change requests; timings mix Node and Python and are a smoke test, not a benchmark. Scripts, payloads and results are under /workspace/revisit/drill30/.

Unlearn / re-learn

Unlearn

A feature flag is just an if with a boolean.
Open source means every governance feature is free.
A 10 percent rollout is the same users everywhere.
The flag server going down will switch features off.
Licences stay the same once you have picked a tool.

Re-learn

Context keys, hashing and stickiness decide who sees a feature.
Admin access, tokens and audit are part of the product, not extras.
Every release flag needs an owner and an expiry date.
Practise an outage and a ramp before the first exam-season release depends on them.

Closing

Feature flag platforms in 2026 are mature, cheap to start and easy to misuse. Learn how each tool evaluates: in your process, in its server, or on the user’s device. Unlearn the habit of hard-coding release toggles and calling a ConfigMap a kill switch. Re-learn the licence and edition lines, because Unleash moved to AGPLv3 this year and all three keep approvals and SSO in paid editions. Practise with a small drill like the one above: one flag, 100,000 IDs, a ramp and a server kill. Apply one platform behind OpenFeature, give every flag an owner, and delete flags as seriously as you create them.

Sources

Unleash

Flagsmith

GrowthBook

OpenFeature

OpenFeature home

Security (CVE Program records)

Internal Revisit.Tech links used in the body

comments powered by Disqus

Releted Posts

Fluent Bit, Vector and the OpenTelemetry Collector: revisit your log pipeline before you ship more logs

Manoj Shukla
October 11, 2026

A logistics company in Pune runs about 600 pods across three Kubernetes clusters. A Fluentd DaemonSet, set up in 2019 with a dozen Ruby plugins, ships about 25 crore log lines a day to Loki.

Manoj Shukla
October 12, 2026

Picture a payments and lending analytics platform in Hyderabad (an invented example, not a real client). Card authorisations and EMI schedules still land in PostgreSQL 16.

Manoj Shukla
October 12, 2026

Picture an ecommerce and last-mile logistics platform in Bengaluru (an invented example, not a real client). Order capture and inventory still run on PostgreSQL 16.