# GrowthBook: self-hosted feature flags, experiments and warehouse-native analytics > GrowthBook is an open core platform for feature flags, A/B testing and product analytics that queries your own warehouse. Here is how the pieces fit, how to start it with Docker, and where the model stops making sense. **growthbook/growthbook** — Open Source Feature Flags, Experimentation, and Product Analytics - Repository: https://github.com/growthbook/growthbook - Website: https://www.growthbook.io - Stars: 8,470 · Forks: 868 - Language: TypeScript - License: NOASSERTION - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/growthbook-growthbook ## The gap GrowthBook is aimed at The README states the problem plainly: large companies build in-house experimentation and flagging platforms, everyone else either pays for a third party SaaS tool or assembles unmaintained libraries. GrowthBook is an attempt to occupy that middle ground as an open core product, so the audience is teams with enough engineering to run a service and enough analytics to care about experiment statistics, but not enough headcount to build a stats engine from scratch. The scope is broader than a flag service. Feature flags with targeting and gradual rollouts sit next to a statistics engine that the README describes as supporting CUPED, Sequential, Bayesian, Post-Strat, Bandits and SRM checks, plus a product analytics suite for dashboards. That combination is the reason to look at it rather than a plain toggle service: the same assignment decision that ships a feature also feeds the experiment readout. The warehouse-native label is the more consequential design choice. GrowthBook does not ask you to pipe every event into its own store. It queries data sources you already operate, and the README lists eleven, naming BigQuery, Snowflake and Databricks. Metrics are defined in SQL, which means a conversion rate or a ratio or a quantile is a query you can read and edit rather than a black box. ## How flags, experiments and the stats engine connect The repository is a pnpm monorepo. The root package.json defines a workspace with separate packages for the back end, the front end, shared code, a stats package, and the JavaScript and React SDKs, and the dev script activates a Python virtual environment from packages/stats before starting the apps in parallel. That layout tells you where the boundaries are: the TypeScript application serves flags and renders the UI, while the statistics work runs through a Python component. The Dockerfile confirms the polyglot runtime. Its comments describe a final image where Node 24 supervises the application alongside a Python 3.11 gbstats virtual environment, assembled by copying from build stages because the hardened base image is distroless and has no shell. The same comments pin the build to Debian 12 to keep the glibc of the Python environment and a kerberos native addon ABI-compatible, and warn against moving to Debian 13 without re-validating both. That is a concrete maintenance constraint rather than a marketing statement. The client side is SDK-driven. The README says there are 24 SDKs, naming React, Python, Android and iOS among them. An SDK asks for a flag value for a user, the assignment is computed from targeting rules, and experiment exposure is recorded so the warehouse query can attribute outcomes. The README also mentions webhooks and a full REST API for integrations, and an MCP server that can create features, start experiments and clean up stale flags. Those are the seams where GrowthBook plugs into the rest of your tooling. ## Installing GrowthBook with Docker Compose The README gives a three-command path for running it yourself. It clones the repository, enters it, and starts the Compose stack detached: ```bash git clone https://github.com/growthbook/growthbook.git cd growthbook docker compose up -d ``` After that, the README says to visit http://localhost:3000. The Compose file maps port 3000 and also port 3100 for the growthbook service, and starts a mongo service alongside it. Persistent data lives in two named volumes, uploads and mongodata. The stack pulls the published image, which the README notes needs no registry credentials. If you build from the Dockerfile instead, the hardened base images come from Docker's dhi.io registry, and the Dockerfile comments state that registry rejects unauthenticated requests, including metadata reads, with a 401 that does not name DHI. A one-time docker login dhi.io with any free Docker account is required in that path. The connection between the two services is a single environment variable in the Compose file: ```yaml environment: - MONGODB_URI=mongodb://root:password@mongo:27017/growthbook?authSource=admin ``` That default points at the root user with the password password, which is fine for a local trial and wrong for anything reachable from a network. The Compose file is a starting point, not a deployment. For a first real use, create a feature flag in the UI, read its value through one of the SDKs, and only then wire up a warehouse data source so the experiment statistics have something to query. ## Where the warehouse-native model costs you Querying your own warehouse removes a data pipeline, and it also makes GrowthBook dependent on systems it does not control. If a warehouse credential expires, a table is renamed, or a scheduled query falls behind, the experiment readout degrades even though flag delivery keeps working. Flag serving and experiment analysis have different failure modes, and only one of them is on the critical path for your application. The statistics engine is also opinionated in ways that matter. CUPED, Sequential testing, Bayesian methods, Post-Stratification and Bandits are not interchangeable defaults; each changes what a result means and how long you have to wait for one. GrowthBook exposes them, and choosing among them is your team's job. A product team without anyone who can read the documentation on sequential testing will get numbers it cannot interpret. Then there is the licence boundary. The README describes GrowthBook as an Open Core product where the bulk of the code is MIT but several directories fall under the GrowthBook Enterprise License. The repository metadata reports the licence as NOASSERTION, which is consistent with a split licence rather than a single identifier. The practical consequence is that you cannot assume every directory in the tree carries the same permissions, and the README points to the LICENSE file for the full text. Self-hosting the MIT portion and self-hosting the whole application are different propositions. ## GrowthBook alternatives and how they differ The two comparisons people search for most are LaunchDarkly and PostHog, and the differences are structural rather than cosmetic. LaunchDarkly is a hosted flag service. You send flag evaluation to its infrastructure or use a streaming SDK, and experimentation is layered on top of that. GrowthBook inverts the arrangement: you run the application, and analytics is computed by querying your own warehouse. The trade is operational burden for data ownership. If your organisation cannot run a Mongo-backed service and manage warehouse credentials, the LaunchDarkly model asks less of you. If your analytics team already lives in Snowflake or BigQuery and refuses to export event data, GrowthBook's approach avoids that argument entirely. PostHog bundles product analytics with flags and session replay in one product with its own event store. GrowthBook does not store your events; it reads them where they already are and defines metrics as SQL. That means no second copy of user data to govern, and also no built-in session replay or autocapture. If you want a single tool that ingests events itself, PostHog is closer to that shape. If you have already invested in a warehouse and a transformation layer, GrowthBook sits on top of that investment instead of competing with it. Unleash is the closer comparison on the flag side: an open source flag service you host, with a narrower analytics story. GrowthBook's differentiator is the statistics engine and SQL-backed metrics, not the toggle API. ## Maintenance, releases and upgrade cost The repository is not archived, and the last push was on 2026-09-21, so the project is under current development. Recent releases are v5.0.0 on 2026-07-20 and v5.0.1 on 2026-08-19, following v4.4.0 on 2026-05-27. A major version bump within the last few months is worth noting if you are already running an older deployment: v5 is a breaking boundary by convention, and the release notes are the place to check what moved. The upgrade cost is dominated by the runtime, not the application code. The Dockerfile pins Python 3.11 and Node 24, and its comments explicitly warn that moving the base from Debian 12 to Debian 13 requires re-validating the gbstats virtual environment and the kerberos native addon together. Anyone maintaining a fork or a custom image inherits that constraint. Anyone pulling the published image does not, but also does not control when the base changes. The development workflow assumes pnpm workspaces and a Poetry-managed Python environment for the stats package, as the root scripts show. Contributors and anyone building from source should expect to install both toolchains. The README points to CONTRIBUTING.md for local setup rather than repeating it. On licensing, the split between MIT directories and GrowthBook Enterprise License directories is the fact to check against your own use. The README does not enumerate which directories fall on which side, so read the LICENSE file in the repository before you assume a given feature is covered by the permissive terms. This is a description of what the repository states, not legal advice. ## Conclusion Adopt GrowthBook if you already have a data warehouse and want flag targeting, experiment assignment and metric analysis to live in one place you run yourself. Do not adopt it if you have no warehouse to point it at, or if you need a support contract that covers the directories carrying the GrowthBook Enterprise License. Before rolling it out, verify the licence boundaries in the LICENSE file, confirm the Docker Compose stack starts on your host, and check whether your warehouse is one of the eleven data sources the documentation lists. ## FAQ ### Is GrowthBook open source? It is an open core product. The README says the bulk of the code is under the MIT licence, while several directories are governed by the separate GrowthBook Enterprise License, and it points to the LICENSE file for the full text. ### How does GrowthBook work? A self-hosted TypeScript application serves feature flags to 24 SDKs and stores configuration in MongoDB, while experiment analysis is computed by querying your own data warehouse, with metrics defined in SQL. The statistics engine runs through a Python component bundled in the same image. ### What is GrowthBook used for? Feature flags with advanced targeting and gradual rollouts, A/B experiments read out through a statistics engine that supports CUPED, Sequential, Bayesian, Post-Strat, Bandits and SRM checks, and a built-in product analytics suite for dashboards. ### growthbook how to use The README's path is to clone the repository, run docker compose up -d, then open http://localhost:3000. From there you create flags in the UI, read them through an SDK, and connect a data source so experiment metrics can be queried. ### growthbook vs launchdarkly GrowthBook is self-hosted and computes experiment statistics by querying your own warehouse, while LaunchDarkly is a hosted flag service. GrowthBook asks more of your infrastructure and gives you the data and the SQL metric definitions. ### growthbook vs posthog PostHog ingests events into its own store and bundles analytics with flags and session replay. GrowthBook does not store your events; it reads them from your warehouse and defines metrics as SQL, so there is no second copy of user data to govern. ## Sources - [growthbook/growthbook on GitHub](https://github.com/growthbook/growthbook) - [Issues](https://github.com/growthbook/growthbook/issues) - [Project website](https://www.growthbook.io) - [README](https://github.com/growthbook/growthbook/blob/main/README.md) - [Releases](https://github.com/growthbook/growthbook/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/growthbook-growthbook