Is a self-hosted Unleash a good ConfigCat alternative?
If your renewal is forcing a choice, or your security team has asked where flag evaluations and targeting data physically live, the question is whether a self-hosted Unleash server can carry that load. ConfigCat fits well when you want a hosted service with no servers to run, a fast start, and a vendor who operates the delivery path, including the CDN that serves config JSON to your SDKs. Teams that do not want to own uptime, patching or database backups usually stay on a hosted service for good reason. Self-hosted Unleash fits a different set of constraints: flag data and targeting rules must stay inside your network, and your platform team can run the Unleash server against PostgreSQL 15 or later and keep it on the port your environment expects.
Unleash also supports local evaluation in its SDKs, so the architecture is closer than the hosting model suggests. Before you commit, confirm which Unleash features your plan needs. Unleash Open Source is limited to 1 project and 2 environments with basic roles, so a single product spread across development, staging and production may fit, while several products or custom roles will push you toward a paid tier. Also review the AGPLv3 change in v8.0.0: the official open-source Docker images remain under Apache 2.0, but modifying the server and offering it as a service triggers source publication or a commercial license. The decision turns on four questions: where flag data must live, whether the Open Source limits match your project count, whether your legal team is comfortable with the licensing terms, and who will operate, patch and back up the server after launch.
Which option fits which scenario
This table matches common buyer situations to the option that usually fits better, with the reason tied to a supplied limit or operating condition. Read each row as a starting point, then confirm the limits against your own product count, environment count and network rules before you decide.
| Scenario | Better fit | Reason |
|---|---|---|
| Small team with one product and two environments | Unleash Open Source | The free edition covers 1 project and 2 environments per instance, which matches this shape without a paid plan. |
| Small team with several products | Unleash Enterprise or separate instances, confirm with Unleash | Open Source allows only 1 project, so each product beyond the first needs an Enterprise plan or its own deployment. |
| Team with many environments | Unleash Enterprise | Open Source is capped at 2 environments, while Enterprise adds unlimited projects and environments. |
| Regulated team that must keep flag evaluation inside its own network | Self-hosted Unleash | Unleash runs in your own infrastructure, so the server and flag data stay on networks you control, which ConfigCat's hosted service does not provide without its on-premise plan. |
| Team with no platform engineers | ConfigCat, or a managed Unleash contract | Self-hosting adds patching, database backups and upgrades to someone's workload, so confirm who will own them before choosing self-hosted. |
| Team that already runs Kubernetes and PostgreSQL | Self-hosted Unleash | The server runs from a standard container image against PostgreSQL 15 or later, so it fits existing cluster and database operations. |
| Team planning to run Unleash Edge for scale on the open-source edition | Unleash Enterprise or a different caching design | Open-source Edge reaches end of life on December 31, 2026, so plan the caching layer before depending on it. |
| Team that modifies Unleash and offers it as a service | Commercial license or legal review first | Under AGPLv3 from v8.0.0, offering a modified version as a public or commercial service requires publishing source or buying a commercial license. |
Where a ConfigCat alternative keeps flag data and who holds the keys
ConfigCat is a hosted service, so flag definitions and evaluation traffic run in its infrastructure under its operating model. Self-hosted Unleash moves the server, database and access decisions into your own cloud account, data center or air-gapped network, which changes who answers for each control.
Where flag data lives
With ConfigCat, flag definitions sit in the vendor's hosted environment. With self-hosted Unleash, the server reads and writes its flag configuration in a PostgreSQL database you deploy, using PostgreSQL 15 or later as the getting started guide describes. Confirm the region, backup location and any copies of flag data your team will hold in your own cloud account, data center or air-gapped network before the design is approved.
Who operates the server
In a hosted model, the vendor patches, scales and restores the service. Self-hosted Unleash makes your team or a delivery partner responsible for the unleash-server container, the database, upgrades, monitoring and disaster recovery. Decide which group carries the on-call duty for flag outages, since a failed flag server can block releases and kill switches.
Identity and access control
Unleash Open Source provides basic roles only. Project and custom roles, user groups, SCIM provisioning and single sign-on are listed under Unleash Enterprise. If your policy requires centralized joiner and leaver processes, confirm with Unleash which of these features the edition you choose includes before you assume they are available.
Audit trail ownership
A hosted vendor keeps the change history of flags and returns it through its own interface and retention settings. With self-hosted Unleash, the audit record lives in your database and logging pipeline, so you decide retention, export format and tamper protection. Export and store the history in your SIEM or log platform, and confirm whether the edition you run provides the audit functions you need for reviews.
Network reachability for workloads
Application SDKs must reach the flag server, and a self-hosted server must be reachable from every network segment that evaluates flags, including private subnets and, where required, air-gapped zones. Map each workload to its path to the Unleash API and any caching layer. Unleash Edge's open-source version reaches end of life on December 31, 2026, so a design that depends on it needs a plan before that date.
Compliance evidence
Controls and evidence for a compliance assessment are your responsibility, whether the flag service is hosted or self-hosted. You will need to show how access, change control, backups and logging work for the Unleash server. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors issue any audit reports, attestations or certifications.
How ConfigCat and Unleash compare on capabilities
This table sets ConfigCat's hosted capabilities against self-hosted Unleash, with Unleash limits taken from its documentation. Where ConfigCat details were not supplied to us, the cell says what to confirm with ConfigCat before you decide. Read the Unleash Open Source column as the free baseline, and the Enterprise rows as the features that change what you can run without paying.
| Capability | ConfigCat (hosted) | Unleash (self-hosted) |
|---|---|---|
| Local evaluation in SDKs | Confirm with ConfigCat how its SDKs download and cache config JSON for local evaluation | Supported by Unleash SDKs; evaluation runs inside the application, with Unleash Edge available as a caching layer |
| Targeting and segments | Confirm the targeting rule types and segment support on your plan with ConfigCat | Activation strategies and segments; segments must exist in the target before import |
| Percentage rollouts | Percentage options are available; confirm how they are keyed and whether assignments change when the rollout changes | Gradual rollout through activation strategies; confirm how user stickiness is set in your SDK |
| Environments | Multiple environments per product; confirm the count included in your plan | Open Source: 2 environments per instance. Enterprise: unlimited environments |
| Projects | Products and configs organize flags; confirm the limits on your plan | Open Source: 1 project. Enterprise: unlimited projects |
| Roles and access control | Confirm which roles and permission levels ConfigCat offers on your plan | Open Source: basic roles. Enterprise: project and custom roles, user groups and change requests |
| SSO and SCIM provisioning | Confirm SSO and user provisioning options with ConfigCat for your plan tier | Not in Open Source. Enterprise adds single sign-on and SCIM provisioning |
| On-premise or self-hosted option | Available through ConfigCat's on-premise plan; confirm its pricing model and terms directly | Self-hosted by design, run on PostgreSQL 15 or later in your own infrastructure |
| Licensing and support | Commercial SaaS terms; confirm the support tiers and SLAs in writing | Server source under AGPLv3 from v8.0.0, official Docker images under Apache 2.0; Enterprise support is a paid contract |
What the AGPLv3 change means for teams running Unleash
Starting with Unleash v8.0.0, the server source code moved from the Apache 2.0 license to AGPLv3. According to the Unleash blog post of June 2, 2026, the change applies to the source in the main Unleash GitHub repository and the unleash-server npm package. The official open-source Docker images stay under Apache 2.0, and the SDKs keep their permissive licenses. If your plan is to run the published images, the license you receive for the container is not the same license that governs the source code, so check which artifact your deployment pulls and where it came from before you build a compliance position on it.
Unleash states that teams running the official open-source Docker images without modifying the source are not affected by the change. The obligation changes if you modify Unleash and offer the modified version to others as a public or commercial service. In that case, the blog states you must publish the source or buy a commercial license. Internal patches that your own staff run for internal use are a different case from a product you sell to customers, so write down exactly which of these applies to your environment, including any custom strategies, forks or build pipelines that alter the server.
Have legal counsel confirm how AGPLv3 applies to your specific use, including any contractor-built customizations, before you rely on this summary. Then pin the image tag to a specific release such as v8.2.0, which was released on September 8, 2026, and test it in a non-production environment before you roll it out. Record the version, its license terms and your test results in your change records, and repeat the review when you upgrade. Check the Unleash GitHub releases page for the release notes that apply to each tag you consider.
Where Unleash Open Source stops and paid editions start
Unleash Open Source is free to run on your own infrastructure. Per the Unleash pricing page, it is limited to 1 project, 2 environments and 5,000 feature flags per instance, and it offers basic roles. For a single application team with a development and production environment, these limits may be enough. Teams that run several products, or that need a staging tier alongside development and production, reach the environment and project caps first.
- Scope: one project and two environments, such as development and production, for the whole instance.
- Flag volume: up to 5,000 feature flags per instance, counted by the pricing page.
- Roles: basic roles only, with no custom or project-level roles.
- Hosting: you run the server, the PostgreSQL database and any Edge layer yourself.
- Check: confirm the current limits on the Unleash pricing page before you size the migration, since editions change.
Before relying on the free edition, confirm that one project and two environments match how your teams organize ConfigCat products and environments today.
The Pay-As-You-Go option is priced per seat for self-hosted deployments. According to the Unleash pricing page, it costs $75 per seat per month with a 5-seat minimum. That minimum applies even if fewer people administer flags, so a small team pays for at least five seats. Your seat count is the main cost driver, and it recurs every month for as long as the subscription runs.
- Price: $75 per seat per month, per the Unleash pricing page.
- Minimum: 5 seats for self-hosted deployments, so the floor is five seats each month.
- Who pays: the seat holders are the people who log in to the admin UI, not the application servers that download flags.
- Recurring: the seat fee repeats monthly, so model it alongside your infrastructure and staffing costs.
- Ask Unleash: confirm which users count as seats, whether read-only users count, and how seat changes are billed mid-cycle.
Compare this recurring seat cost with ConfigCat's published plan terms, which are priced on config JSON downloads, flags and environments. Confirm those terms directly with ConfigCat, because the two models count different things.
Unleash Enterprise removes the project and environment caps and adds controls that larger organizations usually require. According to the Unleash OSS vs Enterprise comparison, it includes unlimited projects and environments, single sign-on, SCIM provisioning, project and custom roles, user groups and change requests. Enterprise is sold on annual contracts for cloud, self-hosted or hybrid hosting, and pricing is quoted rather than published.
- Scale: unlimited projects and environments for many products and regions.
- Identity: single sign-on and SCIM provisioning for joiner and leaver workflows.
- Access control: project and custom roles, plus user groups for team-based permissions.
- Change control: change requests for reviewing flag changes before they reach production.
- Contract: annual term, with the price set through a custom quote.
Teams with audit, separation of duties or many business units usually hit these limits first. Ask Unleash for a written quote that lists the edition, term and hosting model you intend to run.
The limit you reach first depends on how your organization uses flags. A small team running one product rarely outgrows the free edition. Teams that split flags across products, add more environments or need centralized access control usually move to a paid edition. The point at which the cost changes is tied to these team shapes more than to flag volume alone.
- Single product, two environments: the free edition is usually sufficient (illustrative).
- Several products or regions: the project cap of one is likely the first constraint (illustrative).
- Regulated teams: SSO, SCIM and change requests often become required, which points to Enterprise.
- Large admin population: per-seat pricing scales with the number of people who edit flags.
- Mixed workloads: if you run a separate staging tier, the environment cap matters.
Write down your product count, environment count, admin count and identity requirements, then map them to the editions above.
ConfigCat bills differently from Unleash, so the figures cannot be compared line by line. ConfigCat prices its plans on config JSON downloads, flags and environments, while the Unleash figures above are per seat, per project and per environment. A fair comparison needs the same usage profile priced on both sides, and that profile must include your download volume, flag count, admin seats and environment count.
- Units differ: ConfigCat counts downloads, Unleash counts seats and structure.
- Your profile: estimate download volume and admin headcount from your own logs and team roster.
- Published terms: confirm ConfigCat's current plan limits and prices on its own pricing pages.
- Hidden items: include self-hosting hours, database operations and upgrades on the Unleash side.
- Quote: request written prices from both vendors for the same profile.
Before you decide, confirm ConfigCat's current published plan terms directly with the vendor, since these may have changed.
What a self-hosted Unleash costs beyond the free edition
The Open Source edition of Unleash has no license fee, but running it moves cost into hosting, database operations, engineering time and migration. Each card below is a separate line item to price in a written quote, set against ConfigCat's plan terms, which you should obtain in writing before comparing.
Software edition and licensing
Unleash Open Source is free to self-host and limited to 1 project and 2 environments with basic roles. Moving to Enterprise adds unlimited projects and environments, single sign-on, SCIM provisioning and custom roles, and is sold on a custom annual contract. Pay-as-you-go self-hosted pricing is listed per seat with a 5-seat minimum. Ask whether your ConfigCat setup fits within the OSS limits before assuming the free edition covers it. The recurring cost is the edition decision, not the download.
PostgreSQL hosting and backups
Unleash runs against PostgreSQL 15 or later, and that database holds every flag, strategy and audit record. Hosting may be a managed service or a database you operate, and either way backup, restore testing and version upgrades recur. Confirm who owns patching, point-in-time recovery targets and the retention you need for flag history. This is typically a recurring cost, and it rises with environment count, flag volume and how strict your recovery objectives are.
Server and network hosting
The Unleash server and admin UI listen on port 4242 and can run as a container from the official open-source image. Compute, load balancing, TLS certificates and network paths to your applications are ongoing charges in your own cloud account or data center. Costs rise with SDK traffic, number of applications polling for flags and high-availability replicas. Ask your infrastructure team to size for peak SDK polling and to confirm where the server sits relative to your ConfigCat traffic today.
Engineering time to deploy and operate
Someone must deploy, upgrade and monitor the server, respond to incidents and keep SDK versions aligned with the server. Most of this is recurring effort that scales with the number of teams relying on flags, and it is usually the largest line in a self-hosted budget. The effort is not visible on an invoice, so record it as hours per month. For a fixed-scope implementation, ask for hours by role, the handover runbook and whether ongoing upgrades and monitoring are a separate retainer.
Edge or caching design
If your SDK fan-out is large, a caching layer between SDKs and the Unleash API may be part of the design. The open-source version of Unleash Edge enters end of life on December 31, 2026, according to the Unleash Edge documentation, and Unleash recommends OSS Edge users move to an Enterprise plan. Treat this as a one-time architecture decision with recurring licensing risk. Confirm during scoping whether Edge is needed at all, and if so, which supported edition and hosting you will run.
One-time migration effort
Moving flags from ConfigCat involves exporting definitions, mapping targeting rules to Unleash strategies, recreating environments and segments, swapping SDKs and running both systems in parallel before cutover. This is a one-time cost that depends on flag count, rule complexity and how many applications read flags. Ask for a quote that lists the inventory, the number of SDK integrations to change, parallel-run duration and rollback steps. Your ConfigCat plan terms and export limits will also shape the work, so request those in writing first.
Why Unleash Edge end of life changes scale designs
Unleash Edge is a caching layer that sits between SDKs and the Unleash API, so that thousands of client instances do not each call the central server for flag state. The open-source version of Edge entered long-term support on December 12, 2025 and reaches end of life on December 31, 2026. Unleash recommends that OSS Edge users move to an Enterprise plan. If your design counts on Edge for scale, this is the first decision to make, because the open-source path to a supported caching tier closes on that date.
Teams that rely on Edge have three realistic options. They can buy an Enterprise plan and keep the Edge design, which moves the cost from infrastructure time into a commercial contract. They can adopt a different caching design, such as caching in each service or running a self-managed proxy, which shifts the support burden onto your own platform team. Or they can design so the SDK path does not depend on Edge at all, which means testing how the Unleash API and PostgreSQL behave under your peak SDK polling and how much staleness your flags can tolerate. Each option changes the load profile, failure modes and the person who gets paged, so it should be settled before production rollout rather than after an incident.
Confirm current Edge guidance with Unleash before you commit to any of these paths. Ask for the written support position on OSS Edge after December 31, 2026, the Enterprise plan terms that cover Edge, and any supported migration path for your SDK versions. Record the answers in the design document alongside your load test results, so the decision can be revisited if Unleash changes its guidance.
What moving off ConfigCat for a self-hosted Unleash involves
The sequence turns ConfigCat's products, configs and flags into an Unleash instance that evaluates the same rules, proven in parallel before traffic moves.
Inventory products, configs, environments and flags
Someone on the team lists every ConfigCat product, config, environment and feature flag, along with the targeting rules and percentage options attached to each. ConfigCat has no single bulk export, so this inventory is read through its Public Management API, which exposes products, configs, environments, flags and targeting. Confirm the exact fields and access tokens your plan allows before you rely on them. The step is done when you have a complete, versioned list that someone other than the author can check against the ConfigCat dashboard.
Map targeting and percentage rules to strategies
Translate each ConfigCat targeting rule and percentage option into an Unleash activation strategy or strategy variant. Simple user, country or version conditions usually map to built-in strategies, while anything custom needs a defined equivalent. Pay particular attention to percentage rollouts, because a partial rollout re-buckets users unless the new configuration uses the same hashing inputs as the old one. The output is a mapping document in which every ConfigCat rule has a named Unleash counterpart or a recorded gap.
Create segments and custom strategies in the target
Before any import, create the segments and any custom strategies in the self-hosted Unleash instance. Unleash exports segments and custom strategies only as references, so a flag import fails or silently drops logic when those objects are missing from the target. Work in a staging instance first, and confirm that each referenced segment and strategy exists with the same name the mapping document uses. The step is done when a test import of a single flag resolves without missing references.
Recreate environments and flags in Unleash
Create the environments in Unleash and recreate the flags with the Admin API or the import feature, using the mapping from earlier steps. Self-hosted Unleash Open Source is limited to 1 project and 2 environments, so check that your ConfigCat environment layout fits those limits or that the design needs a different edition. Compare flag states, variants and rules environment by environment against the ConfigCat inventory. The step is done when every flag in scope matches its ConfigCat source in a side-by-side review.
Run both systems behind an abstraction layer
Place the application's flag calls behind an abstraction layer such as OpenFeature, with a provider for ConfigCat and another for Unleash, so that application code does not depend on either vendor. Run both systems in parallel in staging and then in production, comparing the values each returns for the same users and contexts. Swap SDKs in a controlled order and keep the ConfigCat provider available for rollback. The step is done when the comparison shows no unexplained differences for the cohorts you care about, including users inside partial rollouts.
Cut over and decommission ConfigCat
Move production traffic to the Unleash provider in stages, keeping the ConfigCat provider ready until the last cohort has been checked. Once the cutover holds, retire the ConfigCat SDK integrations, revoke API tokens and archive the exported inventory and audit records you need to keep. Confirm the retention and renewal terms of your ConfigCat plan before the subscription ends. The step is done when no service calls ConfigCat, the tokens are revoked and the archive is stored under your own retention policy.
Questions buyers ask before choosing a ConfigCat alternative
Can we self-host Unleash without outside help?
Yes, a small, single-team setup can be run by an internal engineer, since Unleash runs from the unleashorg/unleash-server image against PostgreSQL 15 or later and listens on port 4242. The work that tends to decide whether it stays simple is ongoing: PostgreSQL backups and sizing, version upgrades (the server moved to a new major line with v8.0.0), monitoring of the server and its database, and access control for the admin UI. Ask your team who will own each of these after go-live, and whether that person has capacity to handle an upgrade on a fixed schedule. If the answer is unclear, an implementation partner can take on part or all of that work under a written scope.
How long does a migration from ConfigCat to Unleash take?
The duration depends on the number of flags, the complexity of targeting rules and percentage rollouts, the number of environments, and how many SDK integrations must change. No fixed duration applies to every team, so treat any single number you see as a guess until your own flag inventory is counted. Start by listing products, configs, environments and flags through the ConfigCat Public Management API, then map each rule to an Unleash strategy and test it in a non-production environment. Ask any provider to base its timeline on that inventory and to state which steps are included in the fixed scope.
What does our team need to provide for the engagement?
Three things determine how smoothly the work goes: named owners, a staging environment, and access to your ConfigCat data. Name one owner for flag decisions, one for the platform (hosting, database and upgrades), and one for each product team that consumes flags. Provide a staging Unleash environment or agree to deploy one, and make sure someone can export ConfigCat configs and flag definitions through the Public Management API. You also need to decide on the edition, since the free tier and Enterprise differ in project and environment limits and in features such as single sign-on and custom roles.
Is Unleash Open Source enough for our flags?
Unleash Open Source is enough only if you need one project and two environments with basic roles. The pricing page also lists 5,000 feature flags per instance on the free tier, so count your flags before you commit. Teams with several products, separate production and staging stacks, or a need for single sign-on, SCIM provisioning, project-level roles or change requests will need Unleash Enterprise, which adds unlimited projects and environments. Compare your current ConfigCat product and environment layout against these limits in writing before you choose the edition.
What does the AGPLv3 change mean for internal use?
Starting with v8.0.0, the Unleash server source moved from Apache 2.0 to AGPLv3, while the official open-source Docker images remain under Apache 2.0. Unleash states that running those images without modifying the source does not trigger the change. Modifying Unleash and offering it as a public or commercial service requires publishing the source or buying a commercial license. The licensing section of this page explains these terms in more detail, but the interpretation for your organization belongs with your legal counsel. Ask counsel to review your intended deployment, including any internal forks or patches.
What should a fixed-scope quote for this work include?
A fixed-scope quote should list each deliverable, the environments in scope, the number of flags and products covered, and the acceptance criteria for each one. Ask for the hosting architecture, the PostgreSQL and backup approach, the migration method for flags, segments and rules, the SDK changes per application, and the cutover and rollback plan. Confirm whether handover documentation, staff training and post-launch support are included or sold as a separate retainer. DeployOpen does not publish a price list, and a quote follows from the written scope, so the clearer the inventory and the decision on edition, the easier it is to compare proposals.
How do we keep the Unleash Edge caching layer working after 2026?
The open-source version of Unleash Edge reaches end of life on December 31, 2026, so designs that depend on it for scale need a plan before that date. Unleash recommends that OSS Edge users move to an Enterprise plan. Ask whether your current architecture uses Edge at all, how many SDK clients it serves, and whether the latency and load characteristics justify keeping a caching layer. Your options are to move to a supported Edge deployment under an Enterprise plan, to restructure the caching design, or to test direct API access at your load. Confirm each option against current Unleash documentation before you commit.
Who is responsible for upgrades and security patches?
In a self-hosted setup, your organization owns upgrades, patching of the operating system and database, and the security of the admin UI and API tokens. Unleash releases new versions regularly, for example v8.2.0 on September 8, 2026, and you need a process to test and apply them. Decide who tracks release notes, who tests in staging, and how long a version can stay behind before it becomes a risk. Confirm the support terms of your chosen edition, and if you want an external party to handle upgrades on a recurring basis, scope that as a retainer with its own deliverables.
How DeployOpen helps you evaluate, implement and migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For ConfigCat vs Unleash, we start with the decision you need to make, then build and hand over only the parts your team needs to run.
How we scope
- We confirm which ConfigCat products, environments and flags are in use and which SDKs your applications depend on.
- We agree the Unleash edition, licensing position and hosting model with you in writing before any work starts.
- Engagements are fixed-scope, with deliverables and timelines agreed up front, and a quote follows from that written scope.
How we build
- We deploy the Unleash server from the official image against PostgreSQL in your environment, with the admin UI on port 4242.
- We map your ConfigCat targeting and percentage rules to Unleash strategies and test each mapping against sample users.
- We review Edge placement and the end of life date for open-source Edge, then document the scale design we recommend.
How we hand over
- You receive configuration, runbooks and a record of which flags, segments and environments were recreated and verified.
- We document the SDK swap, the parallel-run period and the cutover checks so your engineers can repeat them.
- We set up backup and upgrade procedures for the Unleash server and database, and document how to run them.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover Unleash version upgrades, including tracking releases such as v8.2.0 and licensing changes.
- We prepare the evidence your compliance assessors may request, while independent auditors issue any formal reports.
