ConfigCat cost vs self-hosted Flagsmith

The Flagsmith edition you choose decides which of your current ConfigCat controls you can keep after the move. Most of the Flagsmith codebase is BSD 3-Clause licensed, but the Enterprise Edition features are closed source and require a license, including role-based access control, SAML single sign-on and certain database integrations. The self-hosted open-source version has no API request limits, so request volume alone does not force a paid tier. Governance is the constraint that matters: according to the Flagsmith pricing page, roles, permissions, change requests and audit logs start at the Scale-Up plan, and Enterprise, which covers self-hosted deployment under a contract, is custom priced.

Before you decide whether the free edition is enough, map every ConfigCat control your teams use today. List who can change flags in production, whether approvals or change requests are required, whether SSO through your identity provider is mandatory, which roles need to be scoped by project or environment, and whether audit history is part of a compliance evidence set. Each item either works in the open-source edition or belongs to the Enterprise line. Ask Flagsmith to confirm the current entitlement for each control in writing, because the edition boundaries are set by the vendor and can change between releases.

Treat the license decision as a cost input, not a footnote. If the mapping shows that SSO or audited change control is a hard requirement, the Enterprise quote becomes part of the total cost of ownership and should be requested alongside the Kubernetes and PostgreSQL work. If only basic flag management is needed, the open-source edition may cover the workload, but confirm that the team accepts the lack of governance features as an operating risk. Record the decision, the controls it relies on and the date it was checked, so the choice can be revisited at the next renewal or ConfigCat plan change.

Running self-hosted Flagsmith is mainly an infrastructure commitment, and the decisions that shape its recurring cost sit in the deployment design. Flagsmith publishes an official Helm chart, flagsmith/flagsmith, from its chart repository. By default that chart creates a PostgreSQL server inside the cluster, but the Flagsmith Kubernetes documentation recommends an externally managed database for production. Your team should decide early whether that database is a managed service in your cloud account or a platform-run instance, because the backup, patching, failover and restore tests for PostgreSQL then belong to someone specific. The documentation also offers optional PgBouncer for connection pooling, which you should load test against your own request pattern before relying on it.

The rest of the stack adds components that need owners. Flagsmith runs an asynchronous task processor for background work, so the worker deployment must be monitored and scaled alongside the API. Redis caching is available as an option, and your team has to decide whether to run Redis yourselves or use a managed equivalent. Optional Edge Proxies can reduce latency for distributed services, but each proxy is another deployment to version, certify and keep close to your SDK traffic. The Flagsmith documentation also notes that OpenShift is supported through the Helm charts, while support for the Flagsmith OpenShift Operator is only available with an Enterprise plan. If your platform standard is OpenShift, ask Flagsmith to confirm in writing what support covers before you choose that path.

These choices drive recurring cost more than the license does. Each component adds upgrade work for every Flagsmith release, plus compute, storage, backup retention and monitoring. The on-call burden also grows with the number of moving parts, since a flag evaluation outage can start in the API, the database, the cache or an edge proxy. Ask any implementation partner for a written scope that names who patches PostgreSQL, who owns the Helm values, who answers pages at night and how upgrades are tested against a staging copy. Those answers, not the flag count, determine the operating cost you will carry each year.

Moving to Flagsmith is mostly a one-time cost, paid in engineering time, and the largest share of it is the export. ConfigCat has no single bulk export, so flag definitions have to leave through its Public Management API. Someone must script the reads, handle rate limits and save the output in a form Flagsmith can be rebuilt from. Expect to recreate projects, environments, segments and remote config values in Flagsmith by hand or through its API. Flagsmith's built-in importer reads LaunchDarkly, not ConfigCat, so confirm with Flagsmith whether any ConfigCat tooling exists before you budget for the work.

Code changes are the second one-time item. Each service that calls the ConfigCat SDK needs its client replaced with a Flagsmith SDK, and any ConfigCat Proxy deployment needs a decision. Flagsmith offers optional Edge Proxies for lower latency, documented in its self-hosting guide, and these are the likely replacement where the proxy served evaluation inside your network. Confirm that the SDK languages and versions your services use are supported, then test evaluation results for each targeting rule, since percentage rollouts and user bucketing may differ between the two vendors.

Run both systems in parallel before cutting over. Keep ConfigCat as the source of truth, mirror each flag into a non-production Flagsmith environment first, and compare evaluations for the same test users in both. After any import, check every flag by hand: confirm targeting rules, percentage values, segments and remote config values match. Archive nothing in ConfigCat until the comparison is clean and the audit history you need has been exported. Ask your internal team or implementation partner for a written migration plan that names cutover criteria, a rollback step and an owner for each environment.