Open Source Split Alternatives

Unleash separates deploying code from releasing a feature. A change can go to production switched off and be turned on when the team is ready, which retires the long-lived feature branch and the merge that comes with it.

Flags are evaluated by an SDK inside your application through a single function call, so the language you work in barely matters. Unleash supports 15 official client and server SDKs and more than 15 community ones, and writing your own is a documented option.

The self-hosted server covers the core of feature management, while several governance capabilities belong to the Enterprise edition.

• Flag evaluation: backend and frontend SDKs check state against the Unleash API at runtime.
• Testing in production: run new code against real production data without exposing every user to it.
• Parallel work: several features move at once without a branch per feature.
• Role-based access control: Enterprise adds rules for who may change which flags.
• Change requests: Enterprise gates flag changes behind review before they take effect.
• SSO and SCIM: Enterprise adds single sign-on and automatic user provisioning.

Getting started locally takes git and Docker. Clone the repository, bring the compose file up, and the interface answers on port 4242 with a default admin login. Running the source directly through Node.js is covered in the contributing guide.

For production, Unleash needs a persistent server, with deployment guides for Heroku and DigitalOcean and documentation on configuration options for anything more involved.

The top one percent of companies spend thousands of hours building experimentation, feature flagging and analytics in house. GrowthBook exists so the other 99 percent get the same platform without paying for expensive third party SaaS or hacking together unmaintained libraries.

It is warehouse native, querying eleven data sources including BigQuery, Snowflake and Databricks rather than keeping its own copy of your events. Metrics are defined in SQL, from simple conversion rates to ratios and quantiles, and 24 SDKs cover React, Python, Kotlin, Swift and more.

The platform pairs the rollout side with the measurement side.

• Targeted flags: support advanced targeting, gradual rollouts and experiments from a single definition.
• Stats engine: runs CUPED, sequential and Bayesian analysis, post-stratification, bandits and SRM checks.
• Analytics suite: builds dashboards from warehouse data and shares them with the team.
• Documentation in place: attaches screenshots, custom meta fields and Markdown throughout the app.
• Webhooks and REST API: drive integrations and custom workflows.
• MCP server: creates features, starts experiments and cleans up stale flags from an agent.

GrowthBook is open core, most of the code under the permissive MIT license with several directories governed by a separate commercial enterprise license. Self-hosting is a clone and a docker compose up, using the prebuilt public image that needs no registry credentials, with the app waiting on port 3000.

Flagsmith wraps a section of code in a flag so a feature can be switched on or off for different environments, users or user segments, without shipping new code to do it. It removes the deploy-to-change cycle that turns every small release decision into a full build.

The platform covers web, mobile and server side applications through SDKs for more than fifteen languages, among them TypeScript, .NET and Java, and it integrates with frameworks such as React and Next.js. A single Docker Compose file brings up the whole stack and bootstraps an admin user, an organization and a project on first run.

The feature set centers on controlling who sees what and when.

• Feature flags: release code behind a switch and toggle it remotely per environment.
• Segments: target beta testers or cohorts, then run A/B and multivariate tests against them.
• Remote configuration: change values in running applications without deploying again.
• Organization management: keep work in organizations, projects and roles for team members.
• Integrations: connect Flagsmith to the tools a team already uses.

Hosting runs on premise or in a private cloud, which keeps flag evaluation and user data inside your own network. Most of the platform is open source under the BSD 3-Clause license, with a few repositories under MIT, while enterprise governance features need a paid license. A hosted version exists for teams who would rather not run it themselves.

Flipt v2 keeps feature flags in Git rather than in a database. Flag definitions live in your repositories next to the code they gate, which brings full history and blame on every change, branches for testing flag edits before production, and deployment through the CI/CD pipeline you already have.

That choice removes a lot of infrastructure. There is no database and no external dependency by default, just a single binary started by an install script or a Docker image. Flags reach client-side SDKs over a server-sent events streaming API, so updates propagate instantly without polling.

Environments map onto Git in whichever shape fits the organization.

• Environment per branch: development, staging and production each track their own branch.
• Environment per directory: flags are organized by microservice or team inside one repository.
• Environment per repository: separate repositories for different products or security domains.
• Complete isolation: every environment carries its own namespaces, flags and configuration.

Self-hosting keeps flag data inside your own infrastructure, with OIDC, JWT and OAuth authentication, audit trails and file-based secrets management in the open source build. GPG commit signing, merge proposals for reviewing flag changes and Vault or cloud secret manager integration are Pro features. Flipt v1, the database-backed release, still lives on the main branch for anyone not ready to move.

FeatBit separates deploying code from releasing features. Something ships dark, goes to one percent of users, expands as it holds, and switches off without a redeployment when it does not, all controlled by a simple if or else in your own code rather than a DevOps task.

Getting running takes a git clone and a docker compose up, after which the portal answers on port 8081. You then import an official SDK and call a variation function with a user object; the SDK returns that user's value and the code branches on it. SDKs cover .NET, JavaScript, React, Node.js, Java, Python, and Go, alongside OpenFeature providers.

Around the flags themselves sits the machinery a team needs.

• Targeting and segments: assign users to specific variations, or include and exclude them by attribute through reusable segments.
• Experimentation: run feature-level A/B tests anywhere in the stack and read usage insights during a rollout.
• Feature workflow: flag triggers, scheduled changes, and change approval requests automate how a flag moves.
• Access control: define access levels per project, environment, or team, with an audit log of flag changes.
• Integrations: webhooks reach DataDog, New Relic, Grafana, Growthbook, and Slack, while OpenTelemetry carries traces and metrics.
• Relay proxy: host a flag service in a customer's private environment or nearer end users.

Deployment runs from docker compose to Kubernetes manifests and Helm charts. FeatBit is open core: the bulk of the code is MIT, certain features need a valid license key, and a professional edition targets teams past millions of daily users.

Featurevisor keeps feature flags, experiment variations and remote configuration as files in a Git repository. Flag changes then travel through the same branch, review and history that application code does, which removes the separate dashboard where toggles get flipped with no trail behind them.

The flow has three steps. A project is defined declaratively in the repository, a CI pipeline builds static JSON datafiles and uploads them to a CDN or a server of your choosing, and SDKs inside the application fetch a datafile and evaluate features against the context the application supplies. A project is assembled from attributes as the inputs for conditions, segments as reusable targeting rules, features carrying flags, variations and variables, and global variables with their own targeting and lifecycle.

The use cases the project documents follow from that structure.

• Progressive delivery: roll a feature out gradually instead of shipping it to everyone at once.
• Decoupled releases: separate deploying the code from releasing the feature it carries.
• Experiments: run A/B and multivariate tests through variations.
• Entitlements: gate features by role, and test in production safely.
• Remote configuration: change typed values without a deploy.
• Ownership: establish who owns each feature, with dependency management and safe deprecation.

SDKs cover JavaScript, React, React Native, Vue, Next.js, Go, Python, PHP, Ruby, Java, Kotlin, Swift, Rust and Elixir, with OpenFeature providers for most of them. An official agent skill teaches tools such as Claude Code and Cursor how to create features, write rollout rules and debug evaluations, and a local catalog command reviews every change in the browser.

Abby is a feature management and A/B testing platform built around a simple, statically typed API, so flags and experiments are declared in the same language as the application that reads them. Alongside the SDKs it ships a dashboard, which keeps the people who do not write code out of the codebase.

The repository is a Turborepo monorepo managed with pnpm and written entirely in TypeScript. A Next.js app on the T3 stack serves the dashboard, a second Next.js app with Nextra serves the documentation, and one core SDK sits underneath every framework client.

What ships is deliberately small.

• Typed SDKs: a core JavaScript package backs the React, Next.js, Angular and Svelte clients.
• Dashboard: teammates who do not write code manage flags and experiments without opening a pull request.
• Privacy: no personalized user data is tracked and no marketing cookies are set.
• Self-hosting: the platform runs from this repository, with a hosted version for anyone who would rather not operate it.
• Tooling: TypeScript, ESLint and Prettier are wired across every package in the workspace.

Getting a local instance up is a clone, a pnpm install, a package build, a database start, an environment file copy, a migration and the dev server. Sign-up runs through email, and the bundled MailHog inbox catches the one-time link so an account can be created without any mail provider configured.