ConfigCat On-Premise vs self-hosted open source

Keeping self-hosted feature flags inside your network

A team that must evaluate and store feature flags inside its own network usually faces a data residency rule, an isolated network or a vendor-access restriction. ConfigCat On-Premise is a vendor-supplied Docker service sold at a quoted flat price, while open-source Unleash or Flagsmith can run in your own infrastructure under your own control, subject to each project's license terms. The choice turns on four questions: licensing, updates, support and who holds the data. Answer them in writing before comparing features, because a flag service you cannot patch or support inside your boundary creates the same exposure as one that sends data out.

Start with who holds the data. For ConfigCat On-Premise, confirm in writing which components run inside your network, whether flag evaluation or license checks ever contact the vendor, and how updates reach an offline cluster. Ask the same questions about the Proxy in offline mode, including what it caches and how it refreshes configuration. For self-hosted Unleash, you run the server, its PostgreSQL 15 or later database and the admin UI on port 4242. The official open-source Docker images stay under Apache 2.0, but Unleash's AGPLv3 announcement says that offering a modified Unleash as a public or commercial service requires publishing the source or buying a commercial license. Flagsmith's core is mostly BSD 3-Clause, while SAML and role-based access control are closed-source Enterprise features.

Before you sign anything, request written answers from ConfigCat on license term, update cadence, support response times and whether the on-premise service works with no outbound connection. Then check the open-source limits that matter to your estate. Unleash Open Source allows 1 project and 2 environments, so a multi-team deployment needs an Enterprise plan or a different design. Unleash Edge open source reaches end of life on December 31, 2026, so plan its replacement early if you rely on it for scale. If you want help mapping these checks to your environment, DeployOpen plans and deploys open-source platforms inside your own infrastructure under a written scope.

What an in-network feature flag deployment must satisfy

Keeping flags inside your network means four things hold at once: evaluation and storage stay local, the server and database sit on infrastructure you control, every update is verified before it crosses the boundary, and admin access is tightly governed. Each card below names one requirement and the check to make with the vendor or in your own environment.

Flag evaluation and storage stay local

Confirm where SDKs fetch flag definitions and where evaluation happens. In Unleash and Flagsmith, flag state lives in PostgreSQL inside your environment, and Flagsmith's optional Edge Proxies can sit close to services for lower latency. For ConfigCat, ask whether the On-Premise Docker service or the Proxy in offline mode keeps config JSON and targeting data within your network, and whether any telemetry leaves it.

Server and database on your infrastructure

Decide who operates the flag server and its database. Unleash runs from the unleashorg/unleash-server image against PostgreSQL 15 or later, with the server and admin UI on port 4242. Flagsmith's Helm chart creates its own PostgreSQL in the cluster by default, while its documentation recommends an externally managed database in production. Plan backups, failover and patching for that database as you would for any system of record.

Verified updates across the boundary

Every package, image and chart carried into an isolated network needs an integrity check before deployment. Pin the image or chart version you tested, mirror it to an internal registry, and keep the source of each artifact. Kubernetes clusters can be prepared offline by pulling images in advance and pointing kubeadm init at a private registry. Confirm with each vendor which images are signed and how their release notes are published.

Licensing that fits self-hosting

Check the license of the exact artifact you deploy. Unleash moved its server source to AGPLv3 with v8.0.0, while the official open-source Docker images stay under Apache 2.0. Flagsmith's core is BSD 3-Clause, but RBAC, SAML single sign-on and some database integrations are Enterprise features that need a license. Ask ConfigCat whether the On-Premise plan includes a license for the Docker service and what happens to it at renewal.

Controlled admin console access

The admin console can change flags that reach production, so restrict who can sign in and what they can change. Unleash Open Source offers basic roles only, while Unleash Enterprise adds SSO, SCIM provisioning, custom roles and change requests. Flagsmith places roles, permissions, change requests and audit logs at its Scale-Up plan and SAML at the same tier. Map these controls to your identity provider before go-live and confirm them in writing.

Air-gap procedures for the platform

Air-gapped operation is a process as well as a deployment. Confirm whether the vendor offers an offline installation path, how it delivers updates on removable media, and whether that path is included in your plan. Adjacent open-source tools such as GitLab, Security Onion and Wazuh publish offline guides, and vendors often reserve air-gapped support for paid editions. Ask for the offline procedure and its supported version list before you commit to a plan.

What ConfigCat On-Premise and its offline Proxy cover

ConfigCat offers two ways to keep flag evaluation inside your own network. The first is its on-premise Docker service, which runs the ConfigCat service in your environment under a price quoted by ConfigCat. The second is the ConfigCat Proxy in offline mode, which serves flag configuration to your SDKs from inside your network so they do not need to reach ConfigCat's hosted endpoints at evaluation time. These are different products with different operating models. The Proxy still depends on configuration reaching it, so the reader should confirm how that configuration is refreshed, who performs the refresh, and what happens when it is stale.

The hosted service is billed on config JSON downloads, so the on-premise route changes the billing unit. A flat price replaces per-download metering, which means your cost no longer rises with each SDK fetch, but it also means you pay for whatever the quote covers and nothing more. Confirm in writing what the flat price includes: the number of instances or nodes, environments, products, seats, retained audit history, upgrades, and any support hours. Ask whether a renewal can change the price and whether usage above an agreed ceiling is charged separately.

Before you sign, request a written scope and a data flow description covering four areas. Scope should name the components delivered and the versions they run. The update process should state how new releases reach you, how security patches are delivered, and who applies them in your environment. Support terms should define response channels, hours and severity handling. Data handling should state what, if anything, leaves your network, including telemetry, license checks and logs, and where flag definitions and audit records are stored. Compare those answers with the open-source route described in the next section.

Unleash or Flagsmith for in-network flags: which fits which situation

Unleash fits teams that want a self-hosted flag server with a clear open-source core and a small, contained footprint. The Open Source edition is free to self-host, but it is capped at 1 project and 2 environments with basic roles, so it suits a single application or a pilot before a wider rollout. Since Unleash v8.0.0 the main server source code is licensed under AGPLv3, while the official open-source Docker images remain under Apache 2.0.

Project and environment limits: Open Source allows 1 project and 2 environments. Each additional project or environment, plus SSO, SCIM, custom roles and change requests, sits in Unleash Enterprise.
License from v8.0.0: The source moved to AGPLv3, but the Unleash blog states that running the official open-source Docker images unmodified is not affected. Modifying the server and offering it as a public or commercial service requires publishing the source or buying a commercial license.
Enterprise features: Single sign-on, SCIM provisioning, project and custom roles, user groups and change requests are Enterprise only.
Good fit: One product team, few environments, and a platform group comfortable running PostgreSQL 15 or later and the server on port 4242.
Watch for: Unleash Edge is the caching layer for scale, and its open-source version reaches end of life on December 31, 2026.

Before committing, confirm with Unleash how the AGPLv3 terms apply to any internal modifications you plan, and whether your environment count will stay within the free limits.

How each open-source option meets the constraint

This table compares ConfigCat's on-premise service with self-hosted Unleash and Flagsmith on license, hosting, updates, support and data location. Where a cell says to confirm, the detail is not settled in the available sources, so ask ConfigCat in writing before you decide. The main takeaway is that both open-source options move update, database and support work to your team, while the ConfigCat option depends on what its quoted price includes.

Requirement	ConfigCat On-Premise	Self-hosted Unleash	Self-hosted Flagsmith
License	Confirm the license terms in the on-premise agreement with ConfigCat.	AGPLv3 for source from v8.0.0; official Docker images stay Apache 2.0.	Mostly BSD 3-Clause; Enterprise Edition features are closed source and need a license.
Where the server runs	Docker service in your network; confirm supported hosts and orchestration options.	Your infrastructure, using the unleashorg/unleash-server image and PostgreSQL 15 or later.	Your infrastructure via Docker Compose or the official Helm chart, with optional Edge Proxies.
Who applies updates	Confirm with ConfigCat how updates are delivered and whether they can be applied offline.	Your team pulls and deploys new images, such as v8.2.0 released September 8, 2026.	Your team upgrades images or the Helm chart, such as v2.286.0 released October 15, 2026.
Support available	Confirm whether support and upgrade terms are included in the quoted flat price.	Community support for Open Source; Enterprise plans are sold on annual custom contracts.	Community support for the open-source edition; OpenShift Operator support requires an Enterprise plan.
Where the data sits	Flag data stays in your network; confirm what, if anything, the service sends to ConfigCat.	Flag configuration is stored in the PostgreSQL database your team operates.	Flag and environment data is stored in the database you run; the Helm chart creates one in-cluster by default.
Database you operate	Confirm whether an external database is required and who manages it.	A PostgreSQL 15 or later instance your team backs up, patches and monitors.	PostgreSQL; the docs recommend an externally managed database in production.
Offline or air-gapped use	Proxy offline mode is offered; confirm full air-gapped server support in writing.	Runs from images you mirror into a private registry; confirm your update path.	Runs from images you mirror into a private registry; confirm your update path.

Licensing and updates: what you can change and what you must publish

The first question for a self-hosted Unleash design is whether you modify the server. Starting with Unleash v8.0.0, the source code in the main Unleash GitHub repository and the unleash-server npm package moved from Apache 2.0 to AGPLv3, while the official open-source Docker images remain under Apache 2.0. Unleash states that teams running those official images without modifying the source are not affected. Anyone who changes Unleash and offers it to others as a public or commercial service must publish the source or buy a commercial license. Check the Unleash blog post on the AGPLv3 change against your build pipeline, because a patched image, a forked chart or an internal fix that customers or partners reach over a network can change your position.

Two other items need a line in your register. Unleash Edge, the caching layer many self-hosted designs use for scale, reaches end of life for its open-source version on December 31, 2026. Plan your caching tier for that date, and confirm with Unleash whether an Enterprise plan is the path it recommends for your load. On the Flagsmith side, the FAQ states that most of the code is BSD 3-Clause, but Enterprise Edition features such as role-based access control, SAML single sign-on and certain database integrations are closed source and require a license. If your ConfigCat on-premise plan currently covers those controls, list them explicitly and decide which ones you will rebuild, buy or accept losing. Have counsel confirm how these terms apply to your use, including internal use, contractor access, and any product that embeds or exposes flag evaluation to outside parties. Ask the vendors in writing for the license text that governs the exact version you will deploy, and keep that record with your change approvals.

How to deploy Unleash or Flagsmith inside an isolated network

This sequence takes a team from a license decision to a feature flag server running inside a network with no route to the internet, with a documented way to update and roll back.

Confirm the license and edition
The security or legal owner confirms which edition the team will run before any build starts. Unleash moved its server source to AGPLv3 starting with v8.0.0, while its official open-source Docker images stay under Apache 2.0, so the team should record which artifact it deploys and how it will use it. Flagsmith's core is mostly BSD 3-Clause, but SAML single sign-on, role-based access control and certain database integrations are Enterprise features. Ask each vendor in writing which features the chosen edition includes, and file the answer with the deployment record. The step is done when the edition, its license and its feature gaps against the ConfigCat plan are signed off.
Build the target platform
The platform team prepares the Kubernetes cluster or Docker host that will run the server, inside the isolated network. If the cluster itself is built without internet access, kubeadm can pull control plane images in advance with its image list and pull commands, and point kubeadm init at a private registry using the image repository flag. Confirm the host can reach the PostgreSQL service and the internal network where SDK clients run, but nothing outside. The step is done when the cluster or host passes a basic health check and has no outbound route to public registries.
Mirror images and charts into a private registry
The platform team copies every artifact the deployment needs into an internal registry, on a machine that has internet access, then transfers them across the boundary. For Unleash, that means the unleashorg/unleash-server image (or unleashorg/unleash-enterprise for Enterprise) and the PostgreSQL 15 or later image. For Flagsmith, include the chart from the flagsmith.github.io/flagsmith-charts repository, its application images, and any Redis or PgBouncer images you plan to use. Verify each package's checksum or signature against the vendor's published values before import, and keep a manifest of versions. Your supply chain process should cover this check, which relates to verifying the integrity and authenticity of vendor software that NERC CIP-013-2 addresses. The step is done when every image and chart resolves from the internal registry alone.
Deploy the server against an external PostgreSQL
The database team provisions a PostgreSQL instance outside the flag server, with backup and access policy that matches the team's standard. For Unleash, point the server at PostgreSQL 15 or later and confirm the connection string. For Flagsmith, the Helm chart creates its own PostgreSQL server in the cluster by default, so set the chart to use the external database instead, and consider the optional PgBouncer layer the documentation describes. Unleash's server and admin UI listen on port 4242, so expose that port only to the internal network and place it behind your existing ingress controls. The step is done when the server starts, connects to the database and serves its health endpoint from inside the network.
Configure the admin UI and access controls
The identity or platform team sets up administrator accounts, roles and login rules before any engineer uses the console. Unleash Open Source limits you to 1 project and 2 environments with basic roles, so plan the project structure against that limit or confirm the cost of Enterprise. Flagsmith's SAML and governance features such as roles, change requests and audit logs start at its Scale-Up plan, so decide whether local accounts meet your policy. Record who can change production flags and how changes are reviewed. The step is done when a test account has only the permissions the change policy assigns, and the settings are exported into the configuration record.
Connect SDKs and any edge or proxy component
The application team points each SDK at the internal server URL and loads a server-side key for each environment. Where high request volume is expected, decide whether to place a caching layer in front of the server. Unleash Edge is the component that replaces LaunchDarkly's Relay Proxy in an Unleash design, but the open-source version of Edge reaches end of life on December 31, 2026, so Unleash recommends OSS Edge users move to an Enterprise plan. Flagsmith offers optional Edge Proxies for lower latency. Test an evaluation from a sample service in each network zone. The step is done when each SDK returns the expected flag value and the team has logged the caching decision.
Document the update and rollback procedure
The platform team writes the runbook that governs every future version change, because your team now owns upgrades. Each update follows the same cycle: pull the new image or chart into the internal registry, verify it, back up the PostgreSQL database, apply the change to a staging environment, then promote to production. Record the database backup point before each change so the team can restore it if the new version fails. Track the release notes of the chosen product, such as Unleash GitHub releases and Flagsmith's GitHub releases, and assign an owner to review security advisories. The step is done when a staging upgrade and a restore from backup have both been performed and the runbook is approved.

Evidence that an in-network flag deployment produces

An auditor or security reviewer will not accept a flag service on trust. The six items below are the records that show where flag data flows, what software runs, who can change it, and how the system recovers. Each one applies whether you choose ConfigCat's on-premise service or a self-hosted Unleash or Flagsmith deployment.

Architecture and data flow record

This is a diagram and written description of every component that touches flag evaluations: the server, its database, SDK connections, any proxy or edge cache, and the network zones they cross. For ConfigCat On-Premise, ask the vendor which components run in your network and which, if any, send telemetry or config data outside it. For open-source options, the record must also name the database and any caching layer you add, such as Unleash Edge, which reaches end of life on December 31, 2026. Check that the diagram matches the running system, not the vendor's reference design.

Container images and verification records

List every image you deploy, its exact tag or digest, and the source it came from. Unleash publishes official open-source Docker images under Apache 2.0, and Flagsmith ships a Helm chart that creates its own PostgreSQL by default unless you change it. Keep the image manifests and any signature or checksum checks you performed when moving images across an isolated boundary. Confirm with each vendor how it publishes signed artifacts and whether its verification method is documented.

Access control and admin audit trail

Reviewers want to see who can create, change or delete flags in production, and whether those changes are logged. Unleash Open Source limits you to basic roles, while project and custom roles, change requests and SSO belong to Unleash Enterprise. Flagsmith places roles, permissions, change requests and audit logs on its Scale-Up plan and SAML single sign-on on Enterprise. Capture the role matrix, the identity source for admin logins, and an export of the audit log showing a sample change. Confirm which of these features your chosen edition actually includes before you promise them.

Backup and restore test results

A backup policy is not evidence until someone has restored from it. Record the database backup schedule, where copies are stored inside your network, who can read them, and the date and outcome of the last restore into a separate environment. Flag configuration is small but critical, since a lost production environment means every rollout state is lost too. For Flagsmith and Unleash, the database holds the flag state, so PostgreSQL backup and restore is the test that matters. Ask ConfigCat which export or backup options its on-premise plan includes and how they are restored.

Update and change records

Keep a dated log of each upgrade, the version moved from and to, the release notes reviewed, and the test run before promotion. Unleash v8.0.0 changed the server license to AGPLv3, so a version change can also be a licensing change for your legal team. Flagsmith's self-hosted releases and Unleash's GitHub releases are the sources to track. Include the approval record and rollback plan for each change, and confirm with ConfigCat how on-premise updates are delivered and how long you are given to apply them.

Vendor terms or open-source license record

Store the signed ConfigCat On-Premise agreement, including support scope, update rights and data handling terms, or, for open-source use, the license file for each component you run. Flagsmith's core is BSD 3-Clause with Enterprise Edition features under a closed license, and GrowthBook is MIT outside its enterprise directories, so the license text must match the features you deployed. Ask counsel to confirm that the license of each component permits your intended internal use, and file the answer alongside the terms.

What does self-hosting feature flags cost and take?

What drives the cost of running feature flags inside our own network?

The cost is set by four components: the infrastructure that runs the flag server, the database behind it, any commercial license you need for the features you require, and the people who migrate and operate the system. For an open-source server such as Unleash or Flagsmith, the software itself has no license fee for the open-source edition, so infrastructure, database and labor carry most of the spend. Infrastructure and database size depend on how many SDKs and environments you run, how much caching you add, and whether you need high availability. Enterprise licensing enters the picture only when you need features such as single sign-on, SCIM, custom roles or change requests, which both vendors reserve for paid tiers.

Which costs are one-time and which recur after go-live?

One-time costs usually include the initial deployment, the migration of flag definitions and segments, rewriting or swapping SDK calls, parallel-run testing and staff training. Recurring costs include hosting and database capacity, backups, patching and upgrades, monitoring, on-call coverage and any annual Enterprise subscription. Recurring labor is often the largest item because every new Unleash or Flagsmith release needs to be tested against your environment before rollout. Ask ConfigCat for its on-premise pricing as a flat recurring fee and compare that against your own recurring infrastructure and staffing lines for the same period.

What should we ask ConfigCat for in an on-premise quote?

Ask ConfigCat to put the following in writing: what the flat fee covers, the term length, how updates to the Docker service are delivered and supported, what support response is included, whether the Proxy in offline mode is part of the plan, and which environments, configs and seats are counted. Also ask what happens to the fee if you need more capacity, how renewals are priced, and what exit terms apply if you later move to another platform. Compare those answers with the open-source route on the same sheet so the decision rests on like-for-like line items.

How long and how much effort does an in-network deployment take?

Duration and effort depend on scope, and no figure applies to every organization. The main drivers are the number of flag projects and environments, the number of SDK types in your applications, how many segments and targeting rules must be recreated, the database and high-availability design you require, and how much integration with your identity and logging systems is needed. Unleash documents a scripted LaunchDarkly migration path, and Flagsmith documents an importer for LaunchDarkly, but those tools do not cover ConfigCat, so the ConfigCat migration will be closer to a manual mapping exercise. Ask any implementation partner for a written scope and timeline before work begins.

What does the work need from our own team?

Plan for platform engineers who can run PostgreSQL, container or Kubernetes workloads and certificate handling, plus application engineers who will change SDK integrations and test rollouts. Product owners must confirm which flags, segments and percentage rollouts are still live, because stale flags are the most common reason migrations run long. Security and compliance staff should review access roles, audit logging and the offline package process if the network is isolated. For Flagsmith on Kubernetes, the official Helm chart creates its own PostgreSQL by default, while the docs recommend an externally managed database in production, which is a design decision your team must make early.

Can our internal team run this without outside help?

Many teams can, provided they have the skills listed above and time to test upgrades. The open-source editions cover core flag management, but features that matter to large organizations, such as SAML single sign-on, role-based access control and change requests, sit behind paid tiers in both Unleash and Flagsmith. If you need those features, budget for the license or accept the limits. Outside help is useful for a fixed-scope deployment, hardening, documentation and migration testing, while ongoing upgrades and testing can be handled through a retainer. Whichever route you choose, put the operating model and the handover in writing.

How could licensing changes affect the decision?

Licensing is a material risk for this decision. Starting with Unleash v8.0.0, the server source moved from Apache 2.0 to AGPLv3, while the official open-source Docker images stay under Apache 2.0 according to Unleash's June 2, 2026 announcement. Unleash states that running those images unmodified is not affected, but anyone who modifies the server and offers it as a public or commercial service must publish source or buy a commercial license. Flagsmith is mostly BSD 3-Clause with closed-source Enterprise features. Have counsel review the terms for your exact use, including any internal modifications, before you commit.

How DeployOpen deploys feature flags under this constraint

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a team weighing the ConfigCat On-Premise plan against running Unleash or Flagsmith, we start by confirming where flag data and SDK traffic must stay, then build and hand over the option that fits.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
The written scope names the flag platform, the environments, the SDKs in use and the data residency boundary
We confirm which ConfigCat features your teams depend on, such as targeting, segments and remote config values
We record who holds administrator access, who approves licensing decisions and who runs the server afterward

How we build

We deploy Unleash or Flagsmith in your environment, with the database, caching and edge layer sized to your SDK traffic
We map ConfigCat targeting and percentage rules to the chosen platform and test each mapping against sample users
We check that the open-source edition covers the project, environment and access-control needs in your written scope
We test the deployment, including access controls and the dependencies that would stop flag evaluation if they failed

How we hand over

We document the installation, configuration, upgrade steps and SDK changes so your team can operate the platform
We provide backup and restore procedures for the flag database and a record of the configuration as delivered
We prepare the evidence your compliance assessor may ask for, without issuing any audit report or certification ourselves
We walk your engineers through the runbook and the rollback path before cutover

How we support

Ongoing support, upgrades and continuous testing are available as retainers agreed separately from the initial scope
We track license and release changes for the platform you run, so upgrade decisions reflect the current terms
We can rerun security testing on the flag service and its integrations as your configuration changes
Quotes follow from the written scope, and we confirm the support level your team needs before it is signed