Which feature flag option fits a ConfigCat renewal or data residency review
If you are weighing a ConfigCat renewal, a bill that rises with config JSON downloads, or a residency rule that keeps flag data inside your own network, the decision comes down to who will run the flag service and what you must keep under your control. ConfigCat suits teams that want managed flags with little operating work, since the vendor hosts the service and you pay for usage under its plans. Self-hosted Flagsmith suits teams that need flag data and evaluation inside their own environment and have people who can run a Kubernetes and PostgreSQL service over time. Neither answer is correct in general, so start by checking which constraint is binding for your organization. The first factor is operations ownership. Under self-hosting, your team owns upgrades, backups, high availability, TLS, monitoring and incident response for the flag server, and the Flagsmith Helm chart's default in-cluster PostgreSQL is something the project's own Kubernetes documentation recommends replacing with an externally managed database in production. Ask who on your platform team will carry that pager, what your recovery objective for flag data is, and whether a retainer for support and upgrades fits your staffing. Confirm current release and upgrade practice against the Flagsmith GitHub releases page before you commit. The second factor is which Flagsmith edition covers your requirements. The open-source code carries no API request limits, but SAML single sign-on, role-based access control and governance features such as change requests and audit logs are Enterprise features on Flagsmith's pricing page, and the OpenShift Operator is Enterprise only. If your security review requires SSO through your identity provider or least-privilege roles for flag changes, price the Enterprise route alongside the self-hosted route. The third factor is migration effort: list your ConfigCat products, environments, segments and remote config values now, and estimate how many SDK swaps your services need before the renewal date.
Which option fits which scenario
This table maps six common situations to the option that fits best, with the reason tied to what hosted plans, Flagsmith's open-source edition and its Enterprise license each include. Read each row against your own constraints, and confirm the reason in your environment before you choose. The main takeaway is that self-hosted Flagsmith suits network-bound data and high request volume, while hosted operation, SAML and vendor support point toward a hosted or paid tier.
| Scenario | Better fit | Reason |
|---|---|---|
| Hosted flags with no server team | A hosted service, ConfigCat or Flagsmith Cloud | Self-hosting adds a Kubernetes or Docker deployment, a PostgreSQL database and upgrades that someone on your team must own. |
| Data must stay inside the network | Self-hosted Flagsmith | Self-hosting keeps the flag service and its database in your infrastructure. Confirm what hosted plans store for your data classification. |
| Need for SAML or RBAC | Flagsmith Enterprise, or a hosted plan at Scale-Up | SAML single sign-on and role-based access control are closed-source Enterprise features. The pricing page places governance features at Scale-Up. |
| High request volume on a free tier | Self-hosted Flagsmith open source | The open-source version has no API request limits, while hosted Free includes 50,000 requests per month and charges extra for more. |
| Team with an existing Kubernetes platform | Self-hosted Flagsmith with the official Helm chart | The chart fits an existing cluster, but plan an externally managed PostgreSQL database because the chart creates its own by default. |
| Team that wants a vendor support contract | Flagsmith Enterprise, or a DeployOpen retainer on self-hosted Flagsmith | Open-source Flagsmith carries no vendor support contract by default. Confirm Enterprise support terms or retainer scope in writing. |
What Flagsmith Enterprise adds and when the open-source edition is enough
Most of Flagsmith is BSD 3-Clause licensed, but the features that govern who can change what are not. Flagsmith's FAQ on open source and self-hosting states that role-based access control, SAML single sign-on and certain database integrations are Enterprise Edition features that are closed source and require a license. The open-source edition still gives you flags, remote config, segments and the self-hosted API with no API request limits, so the decision is about identity and governance, not about whether the core product works. Before you plan the migration, list the controls your auditors and security team expect for flag changes: named roles with separate permissions per environment, approval steps for production changes, and audit history that someone outside the engineering team can review.
The open-source edition is usually enough when your team is small enough that a shared set of admin accounts is acceptable under your access policy, your identity provider can be bridged without SAML (for example, through a process you already run for other internal tools), and no internal or external framework requires you to show role separation or change approval for flag changes. In that case, the Enterprise license is a cost you can defer until a specific requirement appears. If any of those three conditions fails, request a written Enterprise quote from Flagsmith before you commit to a design, because retrofitting SSO and access roles after flags are wired into production code is more disruptive than deciding early.
Confirm current edition contents directly with Flagsmith rather than relying on this page, since edition boundaries change between releases. Ask for the specific features included in the open-source and Enterprise editions, whether the Helm chart and OpenShift support you plan to use are covered by your chosen edition, and whether the Enterprise license is priced per deployment, per seat or by usage. The Flagsmith FAQ on open source and self-hosted is the starting point for that conversation, and the answers should go into your written scope before any migration work begins.
Where flag data lives and who controls the service
With ConfigCat, the provider runs the service and holds the flag data, so your evidence depends on its contracts and documentation. With self-hosted Flagsmith, you choose the cluster, database, identity provider and retention, and you also own the proof that those controls work. The cards below separate what the platform gives you from what your team must build and document.
Where the flag data sits
ConfigCat is a hosted service, so flag definitions, targeting rules and evaluation records live in the vendor's environment unless you use its on-premise option. Self-hosted Flagsmith places the data in the accounts, clusters and database you pick. Ask ConfigCat for its data location and subprocessor list, and confirm which regions your own Flagsmith deployment would use before you commit to either model.
Quick starts versus production hosting
Flagsmith documents Docker and Docker Compose for quick starts, which suit evaluation but not a production estate. For production, the official Helm chart on Kubernetes is the usual route, and it needs an externally managed PostgreSQL database rather than the in-cluster database it creates by default. Decide early which pattern your platform team will operate and who patches each layer.
OpenShift needs an Enterprise decision
Flagsmith runs on OpenShift through its Helm charts, but support for the Flagsmith OpenShift Operator is limited to the Enterprise plan. If your standard is OpenShift, separate the technical deployment from the support model. Ask whether a chart-based install meets your operations and support requirements, or whether the Operator and its support terms are part of the business case.
Identity integration sits behind Enterprise
SAML single sign-on and Okta integrations are Enterprise features in Flagsmith, and the open-source edition has no LDAP configuration out of the box. If your administrators sign in through a corporate identity provider today, map that dependency before migration. Confirm whether ConfigCat's current plan gives you SSO and which roles your team needs, so you do not discover a gap after cutover.
Roles, change control and audit logs
Roles, permissions, change requests and audit logs are governance features that Flagsmith places at the Scale-Up plan and above on its hosted pricing, and they are part of the Enterprise edition for self-hosted installs. Flag changes that affect customer-facing behavior need an approval trail and a record of who changed which targeting rule. Write down the approval workflow you need, then test whether the edition you choose can enforce it.
Evidence you must produce yourself
Whatever platform you choose, your compliance assessor will ask how access is granted, how backups are restored, how logs are retained and how changes are reviewed. Self-hosting moves those artifacts into your environment. DeployOpen can prepare the controls, configuration and evidence for a compliance assessment, but independent auditors and certification bodies issue any audit report or certification.
What running Flagsmith asks of your platform team
Flagsmith publishes an official Helm chart, so most teams deploy the application into a cluster they already run. The chart is the starting point, but the team still owns the ingress, TLS certificates, resource requests, namespaces, upgrades and rollback plans that come with it. Effort rises when the cluster is shared across several teams or when the platform already enforces strict admission policies that the chart's defaults do not satisfy.
- Chart version pinning: Pin the chart and the image version in your Git repository, then test each upgrade in a non-production cluster before promoting it.
- Ingress and TLS: Decide how the SDK traffic and the management console are exposed, and who renews the certificates.
- Resource sizing: Set requests and limits from observed load in your own environment, since flag evaluation traffic depends on your SDK usage pattern.
- OpenShift: Helm installs run on OpenShift, but the Flagsmith OpenShift Operator is only supported with an Enterprise plan, so confirm the support path before you choose that route.
- Backups of cluster state: Store the Helm values files and secrets outside the cluster so a rebuild does not depend on one person's workstation.
Before go-live, confirm with Flagsmith which chart and image versions you will support in production, and write down the upgrade procedure your on-call team will follow.
The Helm chart creates its own PostgreSQL server inside the cluster by default. The Flagsmith documentation recommends an externally managed database for production, and it offers PgBouncer as an optional connection pooler. Moving the database out of the cluster shifts backups, patching, failover and storage capacity onto a system your organization must size and monitor, but it also gives your database team the tooling they already use.
- Default in-cluster database: The chart's built-in PostgreSQL is convenient for evaluation, but confirm whether your standards allow stateful databases inside the same cluster as the application.
- Managed or external PostgreSQL: Provision a database your organization can back up, restore and patch on its own schedule, and confirm the version compatibility with the Flagsmith release you deploy.
- Connection pooling: Decide whether PgBouncer is needed based on the number of application replicas and connections your environment opens.
- Backup and restore tests: Run a restore into a separate environment before go-live and on a schedule afterward.
- Data retention: Flag evaluation history and audit data grow with usage, so agree on retention and purge rules with the data owner.
Confirm the database hosting model, backup frequency and restore time objective with your database team before the chart values are finalized.
Flagsmith's self-hosting documentation lists Redis caching options that reduce repeated reads against the database. Redis adds a second stateful component to the design, so the platform team owns its availability, memory limits and eviction behavior. Whether you need Redis, and how much capacity it needs, depends on how many SDK requests your applications generate and how often flags change.
- Cache purpose: Understand which reads the cache serves, so you can explain a cache failure to application owners in plain terms.
- Memory and eviction settings: Set a memory ceiling and an eviction policy that match your environment's expected key volume.
- High availability: Decide between a single instance and a replicated or managed Redis service, based on how your organization treats cache loss.
- Security settings: Enable authentication and network restrictions, and keep the Redis endpoint off public networks.
- Version support: Confirm which Redis-compatible versions the Flagsmith release you run supports before you upgrade either component.
Ask Flagsmith which caching option matches your expected traffic, and test behavior during a Redis restart in your own environment before users depend on it.
Flagsmith uses an asynchronous task processor for background work. Those jobs run outside the request path, so a stalled worker does not necessarily break flag evaluation, but it can delay work that the console and integrations expect to finish. The platform team must run the worker deployment, watch its queue and restart it reliably, which is a separate operational concern from the web tier.
- Separate worker deployment: Plan for the web and worker processes to scale and restart independently.
- Queue monitoring: Alert on a growing backlog or repeated task failures, not only on whether the pod is running.
- Scheduling and restarts: Confirm the worker's restart behavior after node drains and cluster upgrades.
- Shared broker dependencies: Identify which queue or broker the processor uses in your chosen release, and include it in your backup and patch plan.
- Logs and error routing: Send worker logs to the same place as your other platform logs, with an owner for each alert.
Before go-live, ask Flagsmith to confirm the task processor's dependencies for your release, and document the alerts and runbook that your on-call team will use.
Flagsmith offers optional Edge Proxies to lower latency for flag evaluation. They are not required for a basic deployment, but they add another tier that must be placed, scaled and kept in sync with the core API. Teams usually consider them when applications run in several regions or when latency to a central API becomes a measured problem. Each proxy is another service your team must upgrade, monitor and secure.
- Need assessment: Measure evaluation latency from each region before you add a proxy, so the decision rests on data rather than assumption.
- Placement: Decide where proxies run, and confirm that data flowing to them meets your residency and network rules.
- Version alignment: Upgrade proxies in step with the core API, and confirm the compatibility matrix for your release.
- Authentication and network paths: Restrict which services can reach each proxy and rotate its credentials on the same schedule as other service secrets.
- Failover behavior: Test what applications do when a proxy is unavailable, and confirm that fallback behavior is acceptable to the product owners.
If you plan to replace an existing ConfigCat Proxy deployment, confirm with Flagsmith whether an Edge Proxy meets the same need in your environment before you retire the old tier.
How the cost of each option is built up
Compare what you pay for ConfigCat with what you pay to run Flagsmith yourself. The software license is only one line: infrastructure, database operations, migration and staff time usually decide the total. Each card below marks a component as one-time or recurring and names what moves it.
ConfigCat subscription
ConfigCat bills on config JSON downloads, environments and flags, so the invoice grows with traffic and with how many environments your teams create. This recurs every billing period for as long as you stay on the service. Ask ConfigCat for the current plan limits in writing, and model download volume from your SDK count and polling interval, not from an average. Check whether the plan you need includes the features you use today.
Flagsmith open-source software
The self-hosted open-source version carries no license fee, and its FAQ states it has no API request limits. The recurring cost is the time your team spends on upgrades, security patches and configuration, not a per-request meter. Confirm which features you need sit in the open-source code rather than the Enterprise Edition, because that changes whether this line stays at zero.
Flagsmith Enterprise license
SAML single sign-on, role-based access control, and certain database integrations are Enterprise Edition features that require a license. Flagsmith quotes this on request, so it is a recurring annual or term cost you must negotiate. Governance features such as roles, permissions, change requests and audit logs start at the Scale-Up plan on the cloud pricing page, so ask whether an Enterprise license is needed for the same functions in self-hosted form.
Infrastructure and Kubernetes
Self-hosting moves the compute bill to you: cloud accounts or VMs, a Kubernetes cluster for the official Helm chart, load balancers and the Redis caching and task processing that the self-hosting docs describe. These costs recur and scale with environment count and SDK traffic. Ask your platform team to size them from the evaluation load you expect, and confirm whether OpenShift support would need the Enterprise Operator.
PostgreSQL operations
The Helm chart creates its own PostgreSQL server by default, but the Flagsmith docs recommend an externally managed database in production, with optional PgBouncer. Managed or self-run, this is a recurring cost for backups, failover, patching and storage growth. Decide early who owns the database, and price its backup and restore tests as part of the run cost, not as an afterthought.
Migration and staff time
Moving flags, segments and remote config from ConfigCat is mostly one-time work: recreating projects and environments, swapping SDKs, and checking imported values by hand. Staff time to operate Flagsmith is recurring and is the line most often underestimated. Ask any implementation partner for a fixed-scope quote with named deliverables, and ask internal owners to log the hours spent on upgrades for a full quarter before you compare totals.
What moving from ConfigCat to Flagsmith involves
The sequence turns ConfigCat flag definitions, segments and remote config into a Flagsmith environment your team runs, with each stage closed by a check that proves the new setup matches the old one before ConfigCat is retired.
Inventory products, environments and flags
Platform or product owners list every ConfigCat product, config, environment and flag that application teams rely on, and note which flags are live, which are stale and which hold remote config values rather than booleans. Each entry records its owner, the services that evaluate it and the targeting rules attached to it. The output is a reviewed inventory signed off by the teams that own the flags, so nothing is migrated by accident and stale flags can be dropped before they reach Flagsmith.
Export flag definitions through the ConfigCat API
An engineer reads products, configs, environments and targeting through ConfigCat's Public Management API and stores the results in version control, so the export can be reviewed and rerun. ConfigCat has no single bulk export, so the script must handle pagination and rate limits, and the audit log should be copied out while it is still within its retention window. Done means every flag in the inventory has a stored definition that matches what the ConfigCat dashboard shows.
Recreate projects, environments and segments in Flagsmith
A platform engineer creates the Flagsmith projects and environments that mirror the ConfigCat structure, then rebuilds segments and their rules by hand or with a script that calls the Flagsmith API. Flagsmith's built-in LaunchDarkly importer does not read ConfigCat data, so this work is manual or scripted. Done means each environment holds the same segments and rule logic as its ConfigCat source, and a reviewer has checked a sample of rules against the exported definitions.
Recreate flags and remote config values
Teams recreate each boolean flag, multivariate flag and remote config value in Flagsmith, keeping the same keys so application code does not change. Percentage rollouts and targeting rules are translated into Flagsmith segment overrides and identity-based rules. Because imports and scripts can overwrite existing data, the work is done in an empty target project. Done means every flag key exists in each environment with the expected on or off state, value and override.
Deploy the Flagsmith service in your environment
The platform team deploys Flagsmith in the chosen cloud account, data center or air-gapped network, using Docker Compose for a quick test or the official Helm chart for Kubernetes. For production, they point Flagsmith at an externally managed PostgreSQL database rather than the in-cluster database the chart creates by default, and decide whether an Edge Proxy is needed for latency. Done means the service passes health checks, backups run against the database, and access is limited to the people who manage it.
Swap SDKs and replace the ConfigCat Proxy
Developers change each application from the ConfigCat SDK to a Flagsmith SDK, keeping the flag keys unchanged. Where services used the ConfigCat Proxy, the platform team places Flagsmith's Edge Proxy close to those services if latency or load requires it. Changes ship service by service behind existing release controls. Done means each service evaluates flags through Flagsmith in staging and production, and the ConfigCat SDK calls have been removed from the code.
Run parallel evaluation and compare results
For a defined period agreed with the owners, teams compare the value each flag returns from ConfigCat with the value returned by Flagsmith for the same users and contexts, and investigate every mismatch. Segment membership, percentage bucketing and remote config types are the common sources of difference. Done means the owners of each flag have signed off that the results match, and the mismatches that remain are documented and accepted.
Retire ConfigCat after a final check
Once parallel evaluation is signed off, the team exports a final copy of the ConfigCat definitions and audit records to retained storage, removes the SDK keys from application secrets, and cancels or downgrades the ConfigCat plan according to the contract terms. Confirm the notice period and data return terms in your ConfigCat agreement before cancelling. Done means no service calls ConfigCat, the archive is verified, and the decommissioning is recorded.
Questions buyers ask before switching from ConfigCat to Flagsmith
What does moving from ConfigCat to self-hosted Flagsmith cost?
The software itself can be free: Flagsmith's open-source edition is mostly BSD 3-Clause licensed and has no API request limits. The real cost is the infrastructure and the people. Expect recurring spend on Kubernetes or container hosting, a managed PostgreSQL database, Redis if you use caching, backups and monitoring. Expect one-time spend on migration, SDK changes and testing. Costs go up if you need Enterprise features, which are licensed separately, and they go down if you already run Kubernetes and PostgreSQL platforms. Ask any partner for a quote built from a written scope that lists each component, who pays for it, and what recurs each year. Compare that against your current ConfigCat invoice, which is driven by config JSON downloads, flags and environments.
How long does a ConfigCat to Flagsmith migration take?
The timeline depends on the size and shape of your flag estate, not on the tool alone. The main drivers are the number of projects, environments, segments and remote config values, how many SDKs and services read flags, and how carefully you test each targeting rule before cutover. Flagsmith offers a built-in LaunchDarkly importer, but ConfigCat is not covered by that importer, so flag definitions must be recreated or scripted from ConfigCat's API. Plan for a parallel run in a non-production environment, a rollback path for each service, and a sign-off step where engineers compare evaluated values. No duration is given here; ask for a timeline tied to a written scope and a list of services that consume flags.
What skills does the team need to run Flagsmith on Kubernetes?
Your team needs Kubernetes operations skills, database administration skills and enough SDK work to update each application. The official Helm chart creates its own PostgreSQL server in the cluster by default, but the Flagsmith documentation recommends an externally managed database in production and offers optional PgBouncer. That means someone must own backups, upgrades, failover and connection pooling. Flagsmith also ships an asynchronous task processor, Redis caching options and optional Edge Proxies, each of which adds a component to monitor. Confirm who on your staff will be on call for the database and cluster before you choose this path.
Can our team migrate to Flagsmith without outside help?
A capable platform team can do it alone, provided it has Kubernetes, PostgreSQL and SDK experience and time to test. The open-source edition gives you the full flag and segment model without a license purchase, so the constraint is capacity rather than tooling. Teams usually struggle with the parts that look small: re-creating segment logic exactly, replacing the ConfigCat Proxy with Flagsmith's Edge Proxy where needed, and proving that each service evaluates flags the same way after the switch. If those skills are thin, an implementation partner can plan and implement the work under a fixed scope agreed in writing before work starts. DeployOpen works this way for open-source platform implementation, and ongoing support is available as a retainer.
Does Flagsmith open-source support SAML SSO and role-based access control?
No. Flagsmith's FAQ states that SAML single sign-on, role-based access control and certain database integrations are Enterprise Edition features, closed source and licensed separately. The pricing page places SAML single sign-on and governance features, including roles, permissions, change requests and audit logs, from the Scale-Up plan upward. The open-source edition also has no LDAP configuration out of the box. If your security or compliance requirements call for SSO or granular roles, price the Enterprise option or design compensating controls, and confirm the exact feature list with Flagsmith before you commit. Your identity team should decide whether a separate identity provider in front of the admin console is acceptable.
How does request volume change the cost of ConfigCat versus Flagsmith?
Request volume affects the hosted option far more than the self-hosted one. On Flagsmith's hosted plans, Free includes 50,000 requests per month, Start-Up includes 1,000,000 and Scale-Up includes 5,000,000 or more, and additional API calls on Free, Start-Up and Scale-Up cost $50 per million per month, according to Flagsmith's pricing page. Self-hosted open-source Flagsmith has no API request limits, so your cost instead scales with the compute, cache and database capacity you provision. Load test your expected evaluation traffic, including edge and SDK polling patterns, before sizing the cluster. Ask for a capacity model that shows how infrastructure grows with requests.
What should we check after importing flags into Flagsmith?
Check every imported flag by hand, because the import process overwrites existing environments and flags in the target project. Flagsmith's documentation says its importer keeps boolean on and off states, maps multivariate variations and imports archived or deprecated flags as archived, but ConfigCat sources need their own mapping. Compare each flag's default value, segment rules, percentage rollouts and remote config values in every environment. Run the same test user identifiers through both systems and record any difference. Keep ConfigCat active until the comparison is signed off and the audit history you need is exported.
How DeployOpen helps evaluate, implement and migrate Flagsmith
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For ConfigCat vs Flagsmith, we start by agreeing what the Flagsmith deployment must cover, then build and test it in your environment so the choice rests on your own requirements.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Scope maps your ConfigCat flags, remote config, segments and environments to what Flagsmith Open Source covers.
- Edition decisions such as SAML, RBAC and audit logs are identified early, with the Enterprise license question put to Flagsmith.
- We agree which cloud account, data center or air-gapped network will host the deployment and who owns each part.
How we build
- We deploy Flagsmith with Docker Compose or the official Helm chart, using an externally managed PostgreSQL database.
- We configure the asynchronous task processor, Redis caching and, where latency requires it, Edge Proxies.
- We test flag evaluation, targeting, segments and remote config against the ConfigCat behavior you rely on today.
- We harden access, backups and network paths in line with your own security policies.
How we hand over
- You receive written architecture, configuration and runbook documentation covering the deployment as built.
- Migration steps cover SDK swaps, environment recreation and a manual check of every imported or recreated flag.
- Knowledge transfer sessions walk your engineers through upgrades, backups and restore procedures.
- Evidence for compliance assessments is prepared, while independent auditors and certification bodies issue any reports.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrades are planned against Flagsmith release notes and tested in a non-production environment first.
- Security testing of the deployed application and APIs can be scoped separately under the same written process.
- Ask any provider, including us, to confirm support response terms in writing before you commit.
