Can GrowthBook be self-hosted?

• Yes. GrowthBook self-hosts as one Docker image plus MongoDB or a MongoDB-compatible database, and the quick start is a single Compose file.

However:

• The default database is MongoDB, and the SSPL is not an OSI-approved open source license. Unleash runs on PostgreSQL.
• GrowthBook browser SDKs download the full targeting payload by default. All three mitigations (remote evaluation, encrypted endpoints, secure attribute hashing) are Enterprise on self-hosted GrowthBook. Unleash frontend SDKs receive evaluated flags on every edition.
• Every user on GrowthBook’s self-hosted Open Source plan is an admin. Unleash open source ships Admin, Editor, and Viewer roles.
• A self-hosted GrowthBook talks to two GrowthBook-run endpoints by default, telemetry and its flag CDN, plus a daily license check once you add a license key. Unleash makes one optional version check that sends an anonymous instance ID and usage counts.
• Our control plane is one service and one PostgreSQL database with versioned releases and no warehouse connection.

The short answer

Yes, GrowthBook can be self-hosted. The control plane is the service you run that stores flag configuration and answers SDK requests, and GrowthBook’s is a single Docker image holding a NextJS front end, an ExpressJS API, and a Python stats engine, plus a MongoDB instance or a MongoDB-compatible database.

The image is distroless and runs as a non-root user, and there’s a Helm chart.

GrowthBook is built around warehouse-native experimentation, and the single-image install is simple.

The question for a platform team is what you operate once that container is up: the database, what reaches the browser, who can change what, what the install talks to, and how you upgrade. That’s where GrowthBook and Unleash part, and it’s the rest of this article.

PostgreSQL instead of an SSPL database

Self-hosted GrowthBook stores its state in MongoDB. The Compose quick start uses the mongo:latest image, which is meant for a dev or staging environment; for production, the recommended option is MongoDB Atlas, a paid managed service, with AWS DocumentDB, FerretDB, and Azure DocumentDB as the alternatives.

The SSPL has not been approved by the OSI, and SSPL-licensed MongoDB is not considered open source.

So a team that self-hosts GrowthBook for an open source stack is also operating an SSPL database. GrowthBook’s fully open path is FerretDB, which converts MongoDB wire-protocol queries to SQL and uses PostgreSQL as the storage engine.

GrowthBook’s own framing is that FerretDB is for organizations that “require a 100% open-source stack,” is “free from SSPL licensing restrictions,” and lets you run GrowthBook “without any proprietary database dependencies.”

It works, but it’s extra infrastructure, separate from the quick start, and a translation layer between the app and the database you back up.

MongoDB remains a database GrowthBook supports. The app is MIT outside three Enterprise-licensed directories. The database it needs is not, unless you add that translation layer.

Unleash runs on PostgreSQL 15 or newer, with no adapter in between, and PostgreSQL is the only datastore. The Unleash server is AGPL-3.0 and the official Docker images and SDKs are Apache 2.0. Everything you run, application and database, sits under OSI-approved licenses. For a compliance reviewer with an open-source-only policy, the remaining question is whether that policy also rejects the AGPL.

Evaluated results in the browser

By default, GrowthBook’s client-side SDKs fetch the entire feature payload: all feature rules, targeting conditions, experiment configurations, and variations, and they evaluate in the browser. All targeting logic and unused variations are visible in the client.

Self-hosting the app doesn’t change that; the same payload leaves your server for every visitor. If a targeting rule references a saved group of email addresses, that allowlist ships in the payload.

GrowthBook has three mitigations, and on self-hosted GrowthBook all three are paid.

Remote evaluation sends attributes to a server you run and returns evaluated values; it must be turned on in the SDK Connection settings and requires a GrowthBook Proxy, an edge worker, or a custom endpoint. Encrypted SDK endpoints and secure attribute hashing protect teams that keep evaluating on the client.

The Proxy itself is on the Open Source plan, but remote evaluation and encrypted SDK endpoints are Enterprise, and in the license feature map remote-evaluation,encrypt-features-endpoint, andhash-secure-attributesare Pro features, with the oss plan carrying an empty feature set. So the free Proxy can do remote evaluation, but the SDK Connection setting that tells it to is paywalled.

Unleash frontend SDKs don’t evaluate locally. They fetch the enabled flags and variants for a given Unleash Context, already evaluated.

Evaluation runs in Unleash Edge, or in the Unleash server when the SDK calls the Frontend API directly. A direct call sends the context to that server, which is yours when you self-host. Targeting rules stay on the server on every edition, including open source, and frontend tokens are not considered secret and are safe to expose client-side.

Picture a bank gating a feature by account tier in a web app. With Unleash, the browser learns whether the flag is on for this user, not the list of tiers or the rollout percentages. The point is the safer default.

Basic roles on the open source edition

On self-hosted GrowthBook, the Open Source plan has one role: admin. Custom roles, advanced permissioning, SSO (custom OIDC), SCIM provisioning, team permissioning, and multi-tenant mode are Enterprise.

GrowthBook itself recommends that you restrict the admin role to only the people who really need it, because admins can invite users and grant permissions. On the free self-hosted plan, there’s no other role to give them.

That plan has unlimited users, flags, experiments, and API requests, and our open source edition is limited to 1 project and 2 environments, and suited for 1-4 instances. GrowthBook’s self-hosted Open Source plan is also limited to one project.

Unleash open source ships three root roles on all versions: Admin, Editor, and Viewer. Editors can manage flags but not users and roles; Viewers can read root resources but can’t see API tokens.

Project roles, custom roles, user groups, SSO, SCIM, and change requests are Enterprise. Both products are open core, and the governance ceilings look alike.

The difference is the floor: on the edition you can run yourself, we let an engineer edit flags without being an admin, and a reviewer can read without editing. For a 15-person team on a free install, that’s a change log you can trust instead of one where everyone holds the same admin privileges.

Free jumps straight to Enterprise

On GrowthBook Cloud there are three plans: Starter, Pro, and Enterprise. On self-hosted GrowthBook there are two: Open Source and Enterprise. There is no self-hosted Pro.

That matters because every self-hostable feature GrowthBook gates as Pro becomes Enterprise, at custom pricing, when you self-host.

The Pro feature set includes remote evaluation, encrypted SDK endpoints, secure attribute hashing, scheduled flag changes, prerequisites, sticky bucketing, safe rollouts, ramp schedules, code references, archetypes and simulation, multiple SDK webhooks, and CUPED and sequential testing. The event forwarder is not on either self-hosted plan.

Open source, but the step after free is a sales call.

Unleash has the same two-tier self-hosted shape: open source and Enterprise. The point is what sits on each side of the line. On the Unleash free side: PostgreSQL, evaluated results for browsers, and three roles. On GrowthBook’s free side: an SSPL database, the full payload in the browser, and one role.

What a self-hosted GrowthBook talks to by default

A self-hosted GrowthBook still reaches GrowthBook-run endpoints out of the box.

Telemetry is on by default and collects a hashed org/user identifier, IP address, and user agent; DISABLE_TELEMETRY=true turns it off.

The back end also fetches its own in-app feature flags fromcdn.growthbook.io using a public client SDK key, with a tracking plugin that attaches session ID, device ID, page URL, IP, and user agent to events. Blocking that host won’t break the app; the client falls back to defaults. It’s still an outbound dependency most self-hosters won’t expect.

With an Enterprise license, the app checks with GrowthBook’s license server daily and sends a hash of every user’s email, the git SHA and date of the installation, and the list of data source types, event trackers, and SDK languages in use. Firewalled installs must allow outbound traffic to two anycast IPs.

An air-gapped license exists, but you have to ask sales for one. Self-hosted, but two GrowthBook-run endpoints are on by default, and a third arrives with an Enterprise license.

Unleash makes one outbound call by default: a version check that sends an anonymous instance ID and anonymous usage counts. CHECK_VERSION=false turns off both. SEND_TELEMETRY=false disables only the counts. Self-hosted Enterprise uses license keys that encode the seat count and contract duration in the key itself.

When a license expires, the instance goes read-only and connected applications keep receiving their current flags. For a team whose security review asks “what does this thing call home to,” the Unleash answer is one line.

Enterprise code in the repo, and who owns your patches

Both products are open core, but the shape differs. GrowthBook’s public repository has three directories under the GrowthBook Enterprise License.

That code “may only be used in production” with a valid Pro or Enterprise license (Pro is a Cloud plan; self-hosted has no Pro), and for any modifications or patches you make, GrowthBook retains “all right, title and interest.”

Without a license you may modify it for development and testing; with a license you may modify and publish patches, but GrowthBook owns them. The published image is one build containing both the MIT and Enterprise directories; the license key unlocks the latter, and it’s the same image GrowthBook Cloud runs.

The Unleash public repository is AGPL-3.0 throughout, with no commercially licensed directories. Enterprise ships as a separate image, alongside the open source one. The Unleash contributor agreement is a license grant: “You retain ownership of your Contributions,” and it grants Unleash a perpetual, irrevocable license to use, sublicense, and relicense them.

The AGPL question in short: running unmodified Unleash for your own organization creates no obligation to publish source. The AGPL’s network clause applies to modified versions you make available to users over a network.

If you fork and modify the open source server, the patch is yours, under the AGPL. With GrowthBook’s enterprise directories, the patch is theirs.

One service and one database to run

Unleash is a Node.js server and a PostgreSQL database. The Docker quick start is two containers. Edge is optional; SDKs can call the Client or Frontend API directly.

GrowthBook’s image bundles three components on two runtimes, Node.js and Python.

For production, all application state lives in MongoDB, a self-run MongoDB should be a three-node replica set, the app should run at least three instances behind a load balancer, the stats engine can be split onto a separate jobs server under heavy experiment load, and flag endpoints should sit behind an added layer: a horizontally scaled Proxy with Redis to keep instances in sync, a CDN, or SDK webhooks pushing the payload to S3.

The app needs about 2GB of memory, and GrowthBook strongly recommends a caching layer between the API and your application in production.

Experiment analysis runs in a warehouse you connect, and self-hosted plans are bring your own warehouse.

One more detail your platform team will hit: rebuilding the image from source requires a login todhi.io, the Docker Hardened Images registry, which rejects anonymous pulls. Any free Docker account works, but a Docker Hub mirror or an egress allowlist for docker.io doesn’t cover it.

Pulling the published image needs nothing; forks, internal CI, and air-gapped rebuilds need the extra registry.

The honest counterpoint: Unleash open source is suited for 1-4 instances, and SDK fan-out at scale runs through Enterprise Edge. We don’t position open source Unleash as the scale answer. The point is the shape of the control plane.

A platform team with a PostgreSQL runbook for backups, failover, and upgrades already knows how to run Unleash. Standardized on Amazon RDS for PostgreSQL? Add one database.

GrowthBook adds a document database, a replica set or managed service, a stats tier, and a warehouse if you want the experiments. If you want experimentation, that’s a different product. If you want a flag control plane, fewer parts is the point.

No SQL execution surface against your warehouse

Once you connect a data source, self-hosting GrowthBook means hosting a service that runs user-written SQL against your data warehouse. In GrowthBook’s own words, a large part of its functionality is running arbitrary user-defined SQL, and “there is always a risk,” so the recommendation is a dedicated, least-privilege database user.

Pipeline Mode needs write access to a schema. Warehouse credentials live in MongoDB, encrypted with ENCRYPTION_KEY.

The optional jobs server’s /stats endpoint has no built-in authentication unless you set PYTHON_SERVER_AUTH_TOKEN, and it should stay on a private network either way.

This follows from what GrowthBook is: an experimentation platform that reads your warehouse. It’s the intended scope, but it changes the blast radius of the thing you self-host.

Unleash has no warehouse connection. The components are the API server, the Admin UI, PostgreSQL, the SDKs, and optionally Edge.

A compromised Unleash instance exposes flag configuration, API tokens, and integration credentials, but no warehouse credentials. A compromised GrowthBook instance that has a data source connected holds credentials to your warehouse and a SQL path into it. For a security reviewer scoping a self-hosted deployment, the difference is a warehouse credential the Unleash instance does not hold.

Versioned releases you can pin

Unleash uses semantic versioning with release notes on GitHub, and self-hosters follow a documented upgrade guide.

GrowthBook recommends thelatesttag for both dev and production, with specific version tags released about once a month. latestis updated with every commit to the main branch. GrowthBook runs this tag in Cloud and calls it generally safe for production, and says it “may occasionally have minor bugs.”

The default Compose file uses the floating growthbook/growthbook:latest and mongo:latest tags.

A change-controlled team pins a version in a Helm values file, tests it in staging, and promotes the same artifact to production. When the recommended tag is latest, the image you tested isn’t necessarily the one production pulls on its next restart. A versioned release is what change control is built on.

Three hosting models, with edge nodes in your network

GrowthBook offers Cloud or Self-Hosted, and its Proxy runs in your infrastructure in front of either.

Unleash offers three hosting models: cloud-hosted, where we run the API server and Edge; hybrid, where we host the API, Admin UI, and database and you run Enterprise Edge near your applications; and self-hosted, where you run the API, the database, the Admin UI, and Enterprise Edge.

With self-hosted Unleash Edge, client-side context is processed entirely within your infrastructure. Unleash Enterprise Edge is the supported, commercial option. The open source Edge is in long-term support from December 10, 2025, with end of life on December 31, 2026.

The use case is a team that wants a vendor-run admin plane and database but needs end-user context to stay inside its own VPC. Hybrid gives them that as a named, supported model, and the same Edge carries over if they later self-host everything.

Try the install

The Unleash Docker quick start is two containers: Unleash and PostgreSQL. Run it, connect an SDK, and compare what you’re operating.

FAQs

Can GrowthBook be self-hosted?

Yes. It ships as one Docker image plus MongoDB or a MongoDB-compatible database, with a Compose quick start and a Helm chart. Unleash self-hosts as one server plus PostgreSQL, which means fewer components to run and no warehouse connection.

Is self-hosted GrowthBook free?

The self-hosted Open Source plan is free, with unlimited users, flags, experiments, and API requests. Every user on it is an admin, and there’s no Pro tier, so the step after free is Enterprise at custom pricing. Unleash open source gives you Admin, Editor, and Viewer roles on the free edition.

What database does GrowthBook require?

MongoDB or a MongoDB-compatible database; the fully open path is FerretDB with PostgreSQL as the storage engine. Unleash runs directly on PostgreSQL 15 or newer, with no adapter.

Is MongoDB’s license open source?

Not by the OSI’s standard. The SSPL has not been approved by the OSI, which is why a team with an open-source-only policy lands on PostgreSQL, the database Unleash runs on.

Do GrowthBook browser SDKs download targeting rules when you self-host?

Yes, by default they fetch the full payload, rules and variations included. Remote evaluation, encrypted SDK endpoints, and secure attribute hashing keep rules or values off the client, but on self-hosted GrowthBook all three are Enterprise. Unleash frontend SDKs receive evaluated flags on every edition.

Which self-hosted features need Enterprise?

Every self-hostable feature GrowthBook gates as Pro on Cloud, plus the Enterprise set: remote evaluation, encrypted SDK endpoints, secure attribute hashing, scheduled flags, prerequisites, sticky bucketing, safe rollouts, custom roles, advanced permissioning, SSO, SCIM, team permissioning, multi-tenant mode, approval workflows, exportable audit logs, and SDK streaming.

Unleash Enterprise covers SSO, SCIM, change requests, and analytics, but roles and server-side frontend evaluation are already in open source.

Why self-host Unleash instead?

You operate one service and one OSI-licensed PostgreSQL database, your browsers get evaluated results instead of targeting rules, non-admin roles exist on the free edition, the install makes one optional outbound call, a version check with an anonymous instance ID and usage counts, which CHECK_VERSION=false turns off, releases are versioned, and nothing in the control plane holds warehouse credentials.

For a feature-flag control plane you run yourself, that’s a smaller control plane to operate. Unleash’s own comparison still recommends Enterprise for production scale.