Open source feature flags for SaaS teams: where the free editions stop
SaaS engineering and product leads need to ship several times a week, roll features out to specific tenants, and run experiments on outcomes that live in the product database. Self-hosted GrowthBook, Unleash or Flagsmith can cover all three, but the free editions run out of room quickly. The choice between them turns on three things: which edition limits your team will hit first, how well the SDKs in your stack are covered, and where flag evaluation and experiment data are allowed to live. The three candidates are GrowthBook, Unleash and Flagsmith, and each draws the line between free and paid features in a different place.
SaaS differs from other industries in four ways that shape the setup. Targeting is usually by tenant, plan tier, region or contract status, so the attributes sent to the flag service are customer metadata, not just anonymous user IDs. Customer contracts may promise specific feature availability or staged rollouts to named accounts, which makes a flag change a commitment and not only an engineering decision. If you are under SOC 2, auditors will sample flag changes as part of change management, so you need to show who changed what, when, and who approved it. Finally, if the experiment analysis runs in a third-party SaaS tool, product data leaves your company. Confirm with your legal and security teams which of those four points apply to you before you pick an edition.
Start by mapping your needs to the editions. GrowthBook's self-hosted Open Source plan is free with unlimited users and one project, while its pricing page places SSO and SCIM, approval workflows, safe rollouts and holdouts in the self-hosted Enterprise tier. Unleash Open Source is limited to one project and two environments, so a team that separates staging and production across several services will likely need a paid plan early. Check each candidate's current edition comparison and SDK list against the languages and frameworks in your stack, because a flag platform that lacks a server-side SDK for your core service creates more work than any license fee. Ask each vendor to confirm the feature you rely on, and test it in a staging instance before committing.
Which requirements a SaaS flag platform must meet
This table maps each requirement a SaaS flag platform may face to the source that drives it, what it means for the build, and the evidence to prepare. Read it as a starting checklist: the source tells you why a requirement exists, and the build column tells you what your team or partner must configure. Your auditor, counsel and data protection officer decide how each applies to your organization.
| Requirement | Source | What it means for the build |
|---|---|---|
| Change management for flag changes | SOC 2 Trust Services Criteria, common criteria CC8 (change management) | Treat production flag changes as changes: require a named requester, a reviewer and a timestamped record for each toggle or rollout step. |
| Access control and role-based access | SOC 2 common criteria CC6 (logical access) | Limit who can edit production flags, targeting rules and API keys with roles per project and environment, and review them on a schedule. |
| Approvals and audit logs | SOC 2 common criteria CC7 and CC8, plus GDPR Article 32 on security of processing | Confirm which edition provides approval workflows and change requests, and export logs that show who changed what and when. |
| SSO and SCIM provisioning | SOC 2 common criteria CC6 and GDPR Article 32 (access and identity) | Tie platform logins to the corporate identity provider and remove leavers automatically. Check that SSO and SCIM sit in the edition you plan to run. |
| Processor instructions for user attributes | GDPR Article 28(3) | Where a provider or hosted service receives targeting attributes, the contract must limit processing to documented instructions, including transfers. Keep attribute payloads minimal. |
| Data location for targeting attributes | GDPR Article 32 and Article 28(3) for processors | Self-hosting evaluation keeps attributes inside your infrastructure. Confirm which SDK telemetry and analytics calls still leave the network. |
| Switching rights and exit planning | EU Data Act, Regulation (EU) 2023/2854, Articles 23, 25 and 50 | Data processing providers must allow switching with a maximum two-month notice period and a 30-day transitional period. Keep flag definitions exportable and documented. |
| Switching charges | EU Data Act, Article 29 | From 12 January 2027, providers may not impose switching charges. Before then, confirm in writing what a switch would cost under your contract. |
Which open-source flag platform fits which SaaS team
Each platform below can run gradual rollouts, beta groups and A/B tests, but the license, database and edition limits differ enough to change the shortlist. Start with the edition you can run in production, then check the gates your team hits first: projects, environments, seats, SSO and approval workflows.
GrowthBook for warehouse-native experiments
GrowthBook fits product teams that want experiments analyzed against their own data warehouse. Core code outside the enterprise directories is MIT licensed, but the enterprise directories fall under the GrowthBook Enterprise License, so check which paths your build includes. The self-hosted free plan has unlimited users and one project, which is usually the first limit a growing team meets. Plan for MongoDB or a compatible database, and use the official Helm chart for Kubernetes deployments.
Unleash for flag-first delivery
Unleash fits teams that want a flag server with a small operational footprint on PostgreSQL 15 or later. From v8.0.0, the source code moved to AGPLv3, while the official open-source Docker images stay under Apache 2.0 and the SDKs keep permissive licenses. Running unmodified images does not trigger the source obligation, but modifying Unleash and offering it as a public or commercial service requires publishing the source or buying a commercial license. The first edition limit most teams hit is one project and two environments.
Unleash Edge before go-live
Unleash Edge sits between SDKs and the Unleash API, so it often decides caching behavior and latency for high-traffic client applications. 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, so decide the caching path, and its cost, before your first production rollout rather than during a migration window.
Flagsmith when you compare editions first
Flagsmith suits teams that want to compare a self-hosted edition against the other two platforms before committing. Confirm with Flagsmith the license of the self-hosted edition, the free limits on projects, environments and seats, and whether SSO, role-based access and approval workflows sit in a paid tier. Also confirm the database and container images the self-hosted deployment requires, and ask for the upgrade path between editions in writing before you start a pilot.
How deployment changes for multi-tenant and single-tenant SaaS
On a multi-tenant product, one flag service usually serves many customers, so it runs as a shared workload on your own Kubernetes cluster. Flags are typically scoped by environment (development, staging, production) and by project, while tenant identifiers become targeting attributes rather than separate installs. Because every product request depends on flag evaluation, the design question is less about features and more about failure behavior when the service or network path is degraded.
- Service placement: Run the flag server and its database in a dedicated namespace with separate node pools or resource limits, so an experiment analysis job cannot starve request-path services.
- SDK caching: Confirm how each server SDK caches flag definitions in memory and how often it refreshes them, and what it returns for a flag it has never seen.
- Offline defaults: Define a safe default value for every flag in code, so a cold start or lost connection falls back to the pre-release behavior.
- Environment export and import: Promote flag definitions from staging to production as JSON, and check that segments and custom strategies exist in the target before import, because the export carries them only as references.
- Tenant targeting data: Decide which tenant attributes the SDK receives, and keep account-level data your customers consider sensitive out of the flag payload.
Before committing, ask your platform team to demonstrate a flag evaluation with the flag service stopped and confirm the fallback values match what the product should do.
Dedicated deployments give each customer its own stack, often on that customer's cloud account or in a customer-managed environment. Here the flag service is usually installed once per stack, so each customer has its own flags, its own audit trail and its own change pace. The main risk is drift: small differences in flag definitions across dozens of stacks become hard to explain to customers and auditors.
- Service placement: Decide whether the flag service runs in your account and is reached over a private link, or runs inside each customer's account as part of the deployment bundle.
- Per-environment flags: Keep one project per customer stack, with environments mirroring the customer's own change windows rather than your release calendar.
- Offline defaults for isolated networks: Some customer networks restrict outbound traffic, so the SDK must evaluate locally from a cached configuration rather than calling back for each decision.
- Configuration movement: Use environment export and import to copy a tested configuration into a new customer stack, then record which flags were changed locally after the copy.
- Version alignment: Pin the flag server and SDK versions per stack, because a support request from one customer should not depend on a version another customer runs.
Ask for a written list of which customer stacks run which flag server version and how configuration differences between stacks are detected and reported.
When the SaaS product serves EU customers and must keep their data in the EU, the flag service and its database should run in EU infrastructure, and targeting attributes should not leave that boundary. This is a placement decision first and a licensing decision second. The flag server, database, analytics queries and any telemetry each need a documented location, and the list of what still reaches outside the EU should be short and written down.
- Service placement: Run the flag server and database in an EU region of your own cloud account or in your data center, and confirm where backups and logs are stored.
- Local evaluation: Use server-side evaluation with locally cached definitions, so user attributes used for targeting are not sent to an external evaluation endpoint.
- Experiment analysis: If results are computed in a warehouse, keep that warehouse in the EU and confirm the analysis only transmits aggregated statistics.
- Configuration movement: Export flag definitions from an EU environment and import them only into EU targets, and check that the export file does not contain personal data.
- Transfer documentation: Record any support access from outside the EU, since remote troubleshooting can count as a transfer even when the data stays in place.
Ask your implementation partner to show the data flow for flag evaluation and experiment results, and confirm it matches the processor terms you hold with customers.
How a SaaS team moves from pilot to production flags
The sequence below takes a SaaS team from a limits check through a staging deployment, CI/CD wiring, vendor migration, warehouse-connected experiments and governance, so each phase ends with a known, reviewable output.
Scope free-edition limits against your usage
Product engineering and the platform lead list the flags, environments, projects and users the first year will need, then compare that list with the limits of the free self-hosted editions. GrowthBook's self-hosted Open Source plan allows unlimited users but one project, Unleash Open Source allows one project and two environments, and both lack single sign-on and approval features that Enterprise editions add. Output: a written edition decision, with the features you need beyond the free tier named and priced by the vendor's current pricing page at the time of quote.
Deploy the service in staging
The platform team deploys the chosen service in a non-production environment inside your own cloud account or cluster. For GrowthBook, this means its single Docker image plus MongoDB or a compatible database, and the official Helm chart for Kubernetes is available. For Unleash, it means the unleashorg/unleash-server image against PostgreSQL 15 or later, with the server and admin UI on port 4242. Confirm the managed database choice, backups and TLS termination with your security team. Output: a staging instance that passes a health check and a restore test of its database.
Wire SDKs and a kill switch into CI/CD
Application engineers add the vendor SDKs to a non-critical service, define default values for every flag so the application behaves safely if the flag service is unreachable, and create a kill switch flag that disables a feature without a redeploy. Pipeline owners add a step that checks flag names used in code against the flag service, so stale or missing flags fail a build. Output: a tested rollback path where toggling the kill switch in staging changes behavior within the SDK's refresh interval, recorded in the release runbook.
Migrate existing flags and run both systems
If the team already uses a SaaS flag vendor, export flag and segment definitions through that vendor's API and recreate them in the self-hosted platform. GrowthBook documents importers for LaunchDarkly and Statsig, but warns that advanced setups may contain cases the importer cannot handle and that application code must still switch SDKs. Unleash's migration guide maps targeting rules to activation strategies and recommends running both systems in parallel behind an abstraction layer before cutover. Output: a mapping table of every flag, with each unsupported case listed and resolved by hand.
Connect the warehouse and define experiment metrics
Data engineers grant the experimentation service read-only access to the warehouse that holds exposure and outcome data, such as BigQuery, Snowflake, Postgres or ClickHouse, and product analysts define primary and guardrail metrics in SQL. GrowthBook runs only SELECT queries and returns aggregated statistics, which you should verify against your own data handling policy. Output: one reference experiment reproduced on known historical data, with metric results matching an independent query written by the analytics team.
Set approvals, RBAC and audit log procedures
Security, product and engineering leads agree who can create, change, approve and retire flags in production, and map those roles to groups in the identity provider. They confirm which edition provides approval workflows, SSO, SCIM and audit history, and document how audit records are exported to the log platform. Flag retirement and stale-flag review dates are added to the operating procedure. Output: a signed-off role matrix, an approval rule for production changes, and a sample audit export that a reviewer can read without engineering help.
Go live with a controlled production cutover
The team promotes the approved configuration to production, starting with an internal cohort, and rehearses the kill switch before the first customer-facing rollout. Release managers record who approved each change and confirm that the rollback path works against production traffic. Output: a go-live record listing the production instance version, the approved configuration, the rehearsal result and the owner for each flag, which becomes the baseline for ongoing support or a retainer.
Evidence a SOC 2 auditor will sample from flag changes
This table lists the evidence items an auditor is likely to sample for flag changes, the component that produces each one, and what to confirm in your edition. Read it as a checklist: each row is a record you should be able to produce for a sampled change, from a design date for a Type 1 report or across the full observation period for a Type 2 report. Confirm with your auditor which items they will test, because DeployOpen prepares this evidence but does not issue SOC 2 reports.
| Evidence item | What it shows | Where it comes from | What to confirm |
|---|---|---|---|
| Flag change records | Who changed which flag, when, and from what value to what value | Audit log in the platform, exported to your log store | Whether the edition keeps an audit log for every flag and environment, and how long it retains it |
| Approver identity | Who approved a change before it reached production | Change requests with approval workflows (Enterprise tier on Unleash and GrowthBook) | Whether approvals are enforced in the tool or only by convention, and whether the approver is separate from the requester |
| Role assignments | Which people can edit flags, approve changes or manage environments | Project and custom roles in the platform, configured per environment | Whether roles are defined in the platform or in your identity provider, and who reviews them |
| Identity provider logs | Which accounts signed in, and whether access was granted and removed on time | SSO and SCIM provisioning logs from your identity provider | Whether SCIM deprovisioning is enabled and tested, since SSO and SCIM are Enterprise features on both GrowthBook and Unleash |
| Environment exports | What configuration moved between environments or instances, and who ran the export | Import and export records, JSON files kept with the change ticket | Whether exports are logged and stored, and how segments and custom strategies are verified in the target |
| Access reviews | Evidence that flag tool access was reviewed on a schedule and corrected | Periodic exports of user and role lists, signed off by the reviewer | Your review cadence, reviewer independence and the retention period your auditor expects |
| Report period evidence | A Type 1 report tests design at one date; a Type 2 report tests operating effectiveness across a period | Dated screenshots and configuration snapshots (Type 1), and sampled records across the period (Type 2) | Which report type your customers require, and whether the auditor will sample changes across the full observation window |
What do SaaS teams ask before self-hosting feature flags?
How much does self-hosted feature flagging cost in total?
The software licence is often the smallest line, because the free self-hosted editions of GrowthBook, Unleash and Flagsmith carry no subscription fee. The real costs are the infrastructure to run the service (a container runtime, PostgreSQL or MongoDB, and backups), the engineering time to integrate SDKs and set up CI/CD and observability, and the people who operate and upgrade the system. Paid editions add a per-seat or custom subscription. Ask any implementation partner for a quote that separates one-time setup from recurring hosting, support and upgrade work, and that states which edition each line assumes.
What does Enterprise per-seat pricing cost compared with self-hosting?
Vendor list prices are the clearest starting point. Unleash lists Pay-As-You-Go at $75 per seat per month for self-hosted use with a 5-seat minimum, so the subscription alone comes to $4,500 per month at that minimum. GrowthBook lists Cloud Pro at $40 per seat per month for up to 30 users, but its self-hosted Enterprise tier is custom priced, so you must request a quote. The per-seat cost moves with the number of users who need edit or admin access, not with the number of end users receiving flag values. Confirm whether seat counts include read-only viewers and whether the vendor's terms change for your hosting model.
Which free-edition limits cause problems first?
Limits on projects, environments, users and roles usually surface first. Unleash Open Source allows 1 project and 2 environments with basic roles, so a team with separate staging, production and regional environments will hit the ceiling early. GrowthBook's self-hosted Open Source plan allows 1 project and unlimited users, but it lacks SSO, SCIM, approval workflows, safe rollouts, sticky bucketing and holdouts, which are often needed once several teams share the platform. Map your required environments, identity provider and approval steps against the edition comparison before you commit.
Can a small engineering team run a self-hosted flag platform alone?
A small team can usually run the service, but the answer depends on who owns on-call, upgrades and access reviews. The Unleash getting started guide runs one server image against PostgreSQL 15 or later, and GrowthBook ships a Docker image and an official Helm chart, so the initial deployment is well documented. Ongoing work includes applying upgrades (GrowthBook v5.1.0 and Unleash v8.2.0 were both recent releases), patching the database, managing backups, and keeping SDKs current. Decide which of these your team will own, and where you want a partner to hold a retainer for support or upgrades.
How long does it take to ship the first production flag?
The timeline depends on the scope you agree, and no supplied figure gives a general duration. The path usually has four stages: deploy the server into your cloud account or cluster, connect identity and secrets, integrate one SDK into one service behind a flag with a safe default, and put the flag change through your release process. Teams that already run Kubernetes and CI/CD typically move faster. Ask any partner for a written plan with milestones, the first flag they will ship, and the acceptance test that proves it works in production.
How do we check SDK coverage for our languages and frameworks?
List every runtime that evaluates flags (backend services, web front ends, mobile apps and edge functions) and check each one against the official SDK list of the platform you choose. Confirm whether the SDK evaluates flags locally from a cached ruleset or calls the server on each request, because that changes latency and outage behavior. Also check how the SDK handles defaults when the server is unreachable. Unleash Edge is a caching layer between SDKs and the API, but its open-source version reaches end of life on December 31, 2026, so plan for an Enterprise plan or another caching approach. Confirm each point in the vendor documentation before you build.
Can we migrate flags from LaunchDarkly or Statsig without a rewrite?
Migration is possible, but the SDK switch in your application code is always a manual step. GrowthBook's LaunchDarkly importer uses a REST API token to pull projects, environments and flags into a preview, and its documentation warns that advanced setups may include cases it cannot handle. Its Statsig importer covers feature gates, dynamic configs and experiments, but metric sources and metrics are in beta and limited to warehouse-native Statsig metrics. Unleash's migration guide recommends exporting flag and segment definitions as JSON, recreating them, and running both systems in parallel behind an abstraction layer before cutover. Inventory your targeting rules, prerequisites and experiments first, and test each one against the new platform.
What does DeployOpen cover if we hire it to implement this?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and DeployOpen does not publish a price list, so a quote follows from that written scope. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen can also run security testing on the flag service and its SDK integrations. It does not issue audit reports or certifications, so compliance evidence still comes from your independent auditor.
What to ask an implementation partner before signing
Start by asking the partner which edition they will deploy and why. GrowthBook's self-hosted Open Source plan is free with unlimited users but one project, while the self-hosted Enterprise tier adds SSO and SCIM, approval workflows, safe rollouts, holdouts and sticky bucketing. Unleash Open Source is limited to 1 project and 2 environments, and Unleash Enterprise adds SSO, SCIM, project roles and change requests. Ask the partner to map each requirement from your release process to a specific edition feature, and to state in writing which features the free edition cannot meet. Ask them to confirm current edition limits against the vendor pricing pages on the day you sign, since these change.
Ask how the fixed scope defines SDK coverage and migration. Name every SDK your product uses, including server, mobile, edge and frontend, and require the partner to list which are supported by the chosen platform and which need custom work. If you are leaving LaunchDarkly or Statsig, ask whether the importer covers your advanced setups, since GrowthBook's documentation warns that some scenarios are not handled and that the application must still switch SDKs after import. Ask who runs the parallel-running period and who signs off the cutover. Also confirm what happens to segments and custom strategies in Unleash, which export only as references and must exist in the target first.
Ask who holds the license obligations if you modify the code. Unleash moved its source code to AGPLv3 starting with v8.0.0 while Docker images stay under Apache 2.0, and anyone who modifies Unleash to offer it as a public or commercial service must publish the source or buy a commercial license. Ask the partner to state whether any change they make will be contributed back, who keeps records of modifications, and who decides on a commercial license. For GrowthBook, ask the partner to confirm which directories fall under the Enterprise License and whether their work touches them. Finally, ask how SOC 2 evidence is delivered: which change records, access reviews and flag audit logs will be exported, in what format, and on what cadence. DeployOpen prepares evidence for an auditor, but the auditor issues the report, so confirm which Trust Services Criteria your auditor will test and who owns each artifact. Ask about exit before you sign: under the EU Data Act, providers must let you switch to another provider or to on-premises infrastructure, and switching charges end on 12 January 2027. Ask for a written exit procedure covering flag configurations, targeting data and experiment history.
How DeployOpen scopes and supports self-hosted flags for SaaS
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For SaaS teams, that means starting from the release and experiment workflows your engineers already run, then building a self-hosted flag platform around them under a written, fixed scope.
How we scope
- We map which flags, rollouts, beta cohorts and A/B tests your teams run today, and which SDKs your services use.
- We confirm the edition you need, since free self-hosted tiers and Enterprise features differ on SSO, approvals and holdouts.
- We agree deliverables, timelines and responsibilities in writing before any work starts, so the fixed scope is explicit.
How we build
- We deploy the flag platform in your environment, with its database, identity provider and SDK endpoints placed where your data rules require.
- We connect experiment analysis to your own data source, so only aggregated statistics leave the warehouse for review.
- We test rollout, kill switch and fallback behavior in staging before any production service depends on the platform.
How we hand over
- We document flag naming, ownership, role assignments, and the approval steps your release process requires.
- We provide runbooks for upgrades, backups, restores and flag cleanup, so your engineers can operate the platform.
- We deliver change records and access configuration that your compliance team can use as evidence, without claiming audit outcomes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, sized to the scope you agree.
- We track vendor release notes and license changes that could affect your deployment, and plan upgrades with your team.
- We confirm the terms for support after go-live in the written scope, including what is covered and who responds.
