Optimizely or self-hosted GrowthBook: which fits your experimentation program
A renewal, a move to MAU-based pricing or a data residency requirement is usually what brings a team to compare Optimizely Feature Experimentation and Web Experimentation with a self-hosted GrowthBook deployment. Optimizely fits best when you want a vendor-run suite, visual editing across Web Experimentation for marketing and conversion teams, and a support contract that answers for the platform. Those are real operating benefits, and they come with a vendor you rely on for uptime, upgrades and roadmap. Self-hosted GrowthBook fits when experiments should be analyzed in your own warehouse with read-only SELECT queries, when event and assignment data must stay inside your infrastructure, and when you have a team able to run the GrowthBook application and its MongoDB-compatible metadata store as a service you own.
Be clear about what you are taking on. The self-hosted GrowthBook image bundles the Next.js front end, Express API and Python statistics engine, so you carry the upgrade cadence (the project's current release is listed on its GitHub releases page), backups, TLS, identity and on-call response. Confirm with your security team which data sources the stats engine will query, and confirm the license position for your use: the code outside the enterprise directories is MIT licensed, while those directories fall under the GrowthBook Enterprise License.
Three questions should drive the decision. First, is the free self-hosted Open Source plan's limit of one project enough for your program, or do several business units need separate projects? Second, do you need the visual editor, approval workflows, sticky bucketing, holdouts or SSO and SCIM, which the self-hosted Enterprise tier adds, and is that tier worth its custom price? Third, who will operate the stack day to day, and do they have the database and Kubernetes skills to keep it patched? If the answers point to a single project, a small platform team and a warehouse you already trust, GrowthBook is a strong fit. If they point to heavy visual testing by non-engineers, Optimizely may be the simpler path.
Which option fits which situation
This table matches common buyer situations to the better fit between Optimizely and self-hosted GrowthBook. Read each row against the free self-hosted limits and the paid self-hosted features, because those limits decide most of the answers.
| Situation | Better fit | Reason |
|---|---|---|
| One product team testing features in code | Self-hosted GrowthBook (free Open Source plan) | The free self-hosted plan covers one project with unlimited users and unlimited API requests, which suits a single application if the team accepts SDK integration work. |
| Marketing team running web tests without developers | Optimizely Web Experimentation or a separate web testing tool | GrowthBook's visual editor and script tag sit on paid tiers, and the fit depends on whether client-side-rendered pages are in scope. Confirm before choosing. |
| Regulated buyer keeping event data in its own warehouse | Self-hosted GrowthBook | GrowthBook runs read-only SELECT queries against the customer's warehouse and transmits only aggregated statistics, so raw events stay in place. |
| Multi-brand organization with many projects | Self-hosted GrowthBook Enterprise or Optimizely | The free self-hosted plan allows one project, so several brands need paid self-hosted Enterprise. Ask for a written quote covering project count and seats. |
| Team needing approval workflows and holdouts | Self-hosted GrowthBook Enterprise | Approval workflows, holdouts, safe rollouts, ramp schedules and SSO with SCIM appear only in the paid self-hosted tier, not the free plan. |
| Team with no platform engineers | Optimizely, or GrowthBook Cloud with a support plan | Self-hosting adds MongoDB, the container image, upgrades and backups to someone's workload. Without that capacity, a managed option or an implementation partner is safer. |
| Organization that must avoid a single vendor's SDK | Self-hosted GrowthBook, with OpenFeature in front | OpenFeature providers keep application code independent of one flag vendor, which lowers the cost of a later move. Confirm GrowthBook provider support for your languages. |
What runs when you self-host GrowthBook
GrowthBook ships its Next.js front end, Express API and Python statistics engine in a single Docker image, so the first deployment decision is less about how many services to run and more about where the metadata database and the warehouse connections sit. Application state, including flags, experiments, users and settings, lives in MongoDB or a compatible database. The GrowthBook self-hosting documentation suggests a managed service such as MongoDB Atlas or AWS DocumentDB for production. Ask your team whether a managed database fits your residency and backup rules, and whether your platform group already runs MongoDB operations, since patching, backups and restore tests for that database become your responsibility if you self-manage it.
For Kubernetes, GrowthBook maintains an official Helm chart, which gives platform teams a supported starting point for the image, configuration and secrets. File uploads can go to local storage, Amazon S3 or Google Cloud Storage, and the choice affects how you back up and restore those files. Confirm the storage option against your disaster recovery plan before go-live, and check the current chart and image versions against the GrowthBook GitHub releases page because the image moves with each release. Plan for upgrades as a recurring task, not a one-time install.
The statistics engine and the data source connections need the most careful sizing and access control. Experiment analysis runs inside your deployment and queries your own warehouse, and GrowthBook documents that it runs only SELECT queries and transmits only aggregated statistics. Even so, the service account behind each connection should be read-only, scoped to the event and assignment tables that experiments need, and reviewed like any other production credential. Size the engine and its query load with your warehouse team, because large experiments against high-volume event tables can drive both compute time and query cost. Treat those connection settings as the highest-risk part of the deployment and document who can add or change them.
Where your experiment data lives and who controls it
Experiment programs touch user events, assignments and business metrics, so the location of that data and the people who can reach it matter as much as the feature set. The cards below cover where GrowthBook computes results, where it runs, how access is governed, what stays with Optimizely, how compliance evidence is produced and what the license allows you to change.
Analysis stays in your warehouse
GrowthBook runs read-only SELECT queries against your own data source, such as Snowflake, BigQuery or Postgres, and transmits only aggregated statistics back to its application. Raw event rows do not need to leave the warehouse for analysis. Check which tables the experiment queries touch, who owns the service account GrowthBook uses, and whether that account has write permissions you did not intend to grant.
Hosting in your cloud or data center
The self-hosted deployment ships as a single Docker image that bundles the front end, API and statistics engine, with metadata in MongoDB or a compatible database. An official Helm chart covers Kubernetes. You choose the region, network path and backup approach, and you own the uptime and patching. Confirm where SDK traffic flows, since application servers and browsers still call the GrowthBook endpoint for flag decisions.
Identity through SSO and SCIM
Self-hosted Enterprise adds SSO and SCIM along with advanced permissioning and approval workflows, which the free self-hosted Open Source plan does not include. Map who can edit flags, launch experiments and view results to your identity provider groups, and confirm that deprovisioning removes access promptly. If your policy requires these controls, price the Enterprise tier into the comparison from the start.
What stays with Optimizely
Optimizely hosts your flag configuration, experiment results and, depending on the product, event data within its own service. Before any contract ends, inventory what exists there and decide what must be exported. Ask Optimizely in writing which data formats, delivery methods and retention periods apply to your account and region, and whether any export feature changes before your migration window.
Compliance evidence, not attestations
DeployOpen configures the platform, documents access paths, logging and backups, and prepares the evidence an assessor will ask for. DeployOpen does not issue audit reports or certifications. Independent auditors and certification bodies decide whether your controls meet a framework. Ask your auditor early which evidence they expect for experiment data and whether warehouse query logs count as part of the trail.
Modifying the code under license
Code outside GrowthBook's enterprise directories is MIT licensed, so you may modify and redistribute that part under its terms. Code in the enterprise directories falls under the GrowthBook Enterprise License, which governs what you may change in the paid features. Have legal review the license text against your planned customizations, especially any patches to SSO, approvals or the statistics code.
What the free self-hosted plan includes and what it leaves out
The self-hosted Open Source plan from GrowthBook is free and includes unlimited users, one project and unlimited API requests, according to the GrowthBook pricing page. For a single product team with one codebase, that covers the core work of creating flags, running experiments and reading results from your own warehouse. The first decision is whether you need more than one project. Each team, product or domain that needs its own flags, metrics and experiments counts against that single project, so map your Optimizely projects and environments before you assume the free tier fits. Confirm with GrowthBook how environments are counted in the current edition, since the limit is stated in projects only.
The self-hosted Enterprise edition adds SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts, as listed on the GrowthBook pricing page. Several of these matter directly if you run Optimizely today. Approval workflows and advanced permissioning control who can ship a change to production, and holdouts measure the long-term effect of a set of features. Sticky bucketing keeps users in the same variation across sessions. If your current setup depends on any of these, treat them as a licensing requirement and price them in the migration plan rather than assuming the open-source code provides them.
The GrowthBook LICENSE file states that code outside the enterprise directories is MIT Expat licensed, while the directories packages/back-end/src/enterprise, packages/front-end/enterprise and packages/shared/src/enterprise fall under the GrowthBook Enterprise License. Legal and procurement teams should confirm which terms apply to each directory and to the edition you deploy, and ask GrowthBook to confirm current edition terms in writing before you budget. Verify the license text against the GrowthBook LICENSE file and the version you intend to run, because feature sets and terms can change between releases.
What each option costs to own, by component
Optimizely and self-hosted GrowthBook invoice different things, so the comparison has to be made component by component. Some costs are one-time, some recur, and several depend on usage you can measure before you sign anything.
Optimizely contract
Optimizely sells Feature Experimentation and Web Experimentation on custom plans, and the packaged plans are billed on monthly active users. Web Experimentation counts every visitor who loads the snippet, so traffic growth raises the bill even when you run no new tests. The contract is recurring and usually runs on a term. Ask for the MAU definition in writing, how overage is billed, and whether Feature and Web Experimentation are priced separately.
GrowthBook license tier
Self-hosted GrowthBook's Open Source plan is free with unlimited users, 1 project and unlimited API requests, according to GrowthBook's pricing page. Self-hosted Enterprise adds SSO and SCIM, advanced permissioning, approval workflows, holdouts and safe rollouts, and is quoted on request. This is the main recurring license line if you need more than one project or any of those controls. Ask for the license price, term, and whether it covers the Enterprise directories under GrowthBook's own license.
Servers and MongoDB hosting
GrowthBook ships its front end, API and statistics engine in one Docker image, and stores metadata in MongoDB or a compatible database. The documentation suggests a managed service such as MongoDB Atlas or AWS DocumentDB for production. Compute, storage, backups, and high availability are recurring costs you pay to your cloud or hosting provider, and they grow with the number of environments and experiments. Confirm sizing with your platform team before estimating.
Warehouse query costs
GrowthBook runs read-only SELECT queries against your own warehouse, such as Snowflake or BigQuery, and receives only aggregated statistics. You pay the warehouse for that compute, so the cost is recurring and driven by how many experiments run, how many metrics each one tracks, how long analysis windows are, and how often results refresh. Ask your data team to estimate query volume from a sample of planned experiments and check whether the warehouse has a separate compute pool for experimentation.
Migration effort
Migration is mostly one-time work. Flagsmith and GrowthBook document LaunchDarkly importers, and GrowthBook documents a Statsig importer, but the LaunchDarkly guide warns that advanced setups may include scenarios it cannot handle, and the application still has to switch to a GrowthBook SDK. Optimizely has no built-in importer in this comparison, so flags, experiments and metrics are rebuilt by hand or through the API. Request a fixed-scope inventory before committing to a timeline.
Internal staffing and SSO needs
Someone must own upgrades, backups, SDK changes, metric definitions and access reviews, and this work recurs for as long as you run the platform. Identity integration and approval workflows also add setup and review work. Count the hours your platform, data and security teams will spend each month, and decide whether that time comes from staff you already have, a retained support arrangement, or a new hire. Ask what the Enterprise tier would cost you before planning the SSO and approval design.
What a move from Optimizely to GrowthBook involves
The sequence turns Optimizely flags and experiments into GrowthBook flags, warehouse-backed metrics and SDK calls, with both systems running side by side until the results agree. The output is a cutover that your team can explain to the people who read experiment results.
Inventory flags, experiments and events
Export a list of every Optimizely feature flag, rollout, experiment, audience and metric in use, and note which application code calls each one. Your engineers and product owners do this together, because the list decides what must be rebuilt. Optimizely's Experimentation Events Export is the source for historical event data, so confirm its current delivery options in the Optimizely documentation before you rely on it. The step is done when every active flag and experiment has an owner and a status in one shared inventory.
Stand up a self-hosted GrowthBook instance
Deploy GrowthBook in your own cloud account or data center using the Docker image or the official Helm chart for Kubernetes, backed by MongoDB or a compatible database. Platform engineers own the work, including hosting, TLS, backups and access control. Confirm with GrowthBook's self-hosting documentation which edition covers the features you use, since the free self-hosted Open Source plan lacks SSO, approval workflows and holdouts. The step is done when the instance serves a test project and your backup restore has been tested.
Connect the warehouse and rebuild metrics
Connect GrowthBook to the warehouse that already holds your event data, such as Snowflake or BigQuery. Analysts recreate each Optimizely metric as a SQL-defined metric, because GrowthBook runs read-only SELECT queries and sends only aggregated statistics back. Your data team should agree on exposure and conversion definitions before any results are compared. The step is done when a sample metric returns the same counts that a known query returns against the warehouse.
Recreate flags through the API or by hand
GrowthBook does not document an Optimizely importer, so the flag recreation is manual or scripted against GrowthBook's API. Engineers recreate each flag with its fallback value, targeting rules, rollout percentages and environments, and record each mapping in the inventory. Ask Optimizely and GrowthBook for their current guidance on this path. The step is done when every inventoried flag exists in GrowthBook with the same default value and targeting in a non-production environment.
Swap the SDK calls in the application
Developers replace Optimizely SDK calls with the GrowthBook SDK for each language in use, and for web experiments, swap the Optimizely snippet for the GrowthBook script or SDK. The change should keep the same flag keys and user identifiers, so that bucketing stays stable for users who were already enrolled. Code review and automated tests confirm that each call path still returns a value. The step is done when no production code path imports the Optimizely SDK and the test suite passes.
Run both systems in parallel and compare results
Serve traffic through both systems for an agreed overlap period, and compare exposure counts, conversion counts and the resulting effect estimates for the same experiments. Analysts investigate any gap by checking assignment logic, event timing and metric definitions. Keep a written log of the differences and the reasons for each. The step is done when the differences are explained and accepted by the experiment owners and the analytics lead.
Cut over and retire Optimizely
Switch production traffic fully to GrowthBook, remove the Optimizely snippet and SDKs from the code, and set a read-only archive of your Optimizely results for audit purposes. Confirm the end date of your Optimizely contract and any data export obligations with Optimizely before the final switch. Operations staff monitor error rates and flag evaluation during the first days. The step is done when Optimizely serves no production traffic, the archive is verified and the runbook is handed to the team that will run GrowthBook.
Questions buyers ask before choosing GrowthBook over Optimizely
What does it cost to run GrowthBook yourself, and who pays for what?
Self-hosting GrowthBook has no license fee on the free plan, but you pay for the infrastructure and the people. The cost components are the servers or Kubernetes capacity that run the bundled Next.js front end, Express API and Python statistics engine, a MongoDB or compatible database (the self-hosting docs suggest a managed service such as MongoDB Atlas or AWS DocumentDB for production), object storage for uploads, and the warehouse query costs your experiments generate. Staff time is the largest recurring item: someone must upgrade, back up and monitor the stack. Ask any provider for a written split of one-time setup and recurring run costs, and ask which of those costs your warehouse vendor bills separately.
How long does a migration from Optimizely to GrowthBook take?
The duration depends on how many flags, experiments and metrics you run, how many of them use advanced targeting, and whether your metrics already exist in your warehouse. GrowthBook documents an importer for LaunchDarkly and Statsig, but no built-in importer for Optimizely, so flags and experiments are recreated through the API or by hand. Other drivers are SDK changes in each application, rebuilding metrics on your warehouse, and parallel checks of results against your Optimizely events export before cutover. No timeline figure is supplied here, so ask any implementation partner for a timeline tied to a written inventory of your flags, experiments and services.
Is the free self-hosted GrowthBook plan enough for one project?
The self-hosted Open Source plan includes one project with unlimited users and unlimited API requests, according to the GrowthBook pricing page. That fits a single product area with one team. It stops fitting when you need a second project for another product or business unit, or when you need features that sit only in the self-hosted Enterprise plan, such as SSO and SCIM, approval workflows, holdouts, sticky bucketing and safe rollouts. Map each Optimizely product line you use to a project and confirm the plan limits with GrowthBook before you commit.
Does the GrowthBook visual editor work on a self-hosted install?
Whether the visual editor is available depends on the plan and deployment you choose, so confirm it with GrowthBook before you plan a web testing workload. Treat visual editing as a separate decision from flag-based experiments in code. Teams that run marketing and conversion tests on the Optimizely Web snippet should check the editor's support for their rendering model, especially client-side-rendered single-page apps, and count how their visitor traffic will be measured under the new plan. A separate guide in this series covers that replacement in more detail.
Can an internal team run GrowthBook without outside help?
A team with platform engineering, data engineering and product analytics skills can run GrowthBook without outside help, and many do. The work includes deploying the Docker image or Helm chart, operating MongoDB, configuring the warehouse data source with read-only SELECT access, instrumenting SDKs in each application, and defining metrics that match finance and product definitions. The skills gap usually sits in statistics and metric governance rather than in infrastructure. If you engage an outside firm, it should work from a written scope with agreed deliverables and handover, and DeployOpen works this way on fixed-scope engagements and retainers.
Do SSO and approval workflows require the GrowthBook Enterprise plan?
Yes, according to the GrowthBook pricing page, SSO and SCIM, advanced permissioning and approval workflows are listed as self-hosted Enterprise features, not part of the free self-hosted Open Source plan. If your security policy requires federated sign-in or change approval on production flags, budget for the Enterprise plan or find a compensating control in your own tooling, and confirm the exact feature list and terms with GrowthBook in writing. Ask whether the license covers the enterprise directories in the code, since those are under the GrowthBook Enterprise License rather than MIT.
How does the Optimizely events export affect cutover?
The events export determines how much history you can compare against, and it should be captured before the contract ends. Export your experiment and event data while Optimizely is still active, then run GrowthBook and Optimizely in parallel on the same traffic for a period you agree on before switching. Compare exposure counts, assignment consistency and metric results between the two systems and investigate gaps before you retire the old snippet or SDK. Confirm the export format, delivery method and retention terms with Optimizely, since these details decide how much history reaches your warehouse.
Where GrowthBook may not fit, and what to confirm first
GrowthBook fits many experimentation programs, but the free self-hosted Open Source plan allows one project, so any organization running several products, business units or isolated experiment programs will hit that limit quickly. Confirm the project count you need before you plan around the free tier. Treat the advanced controls as a separate line item: SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts all sit in the self-hosted Enterprise plan according to the GrowthBook pricing page. If your release process or audit trail depends on approvals or role separation, the Enterprise license is part of the design, not an optional extra.
GrowthBook analyzes experiments in your own warehouse, so it only works well where event data already lands in a supported source such as Snowflake, BigQuery or Postgres. If your Optimizely results come from its own event pipeline, you need to confirm that the same events, user identifiers and metric definitions exist in the warehouse before cutover. The visual editor for web experiments depends on a paid GrowthBook tier, so do not assume it comes with the free self-hosted plan. Ask Optimizely directly about current contract terms, data export options and feature parity, since these change and no published comparison replaces the written terms. Finally, test the stats engine against an experiment whose result you already know, comparing sample sizes, confidence intervals and the direction of the effect before you commit to GrowthBook for decisions.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks. For Optimizely vs GrowthBook, we start with a written scope that covers which Optimizely products and flags you run today and where your experiment data lives.
How we scope
- Inventory of Optimizely Feature Experimentation flags, environments and experiments in use
- Decision on whether Web Experimentation needs a separate path or is out of scope
- Warehouse, data source and metric definitions GrowthBook would read from
- Choice of GrowthBook self-hosted edition, based on the approval and bandit features you need
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
How we build
- Deployment of GrowthBook in your environment, with MongoDB or a compatible database configured for production
- Integration of GrowthBook SDKs in place of Optimizely SDKs, with flag evaluation tested in your applications
- Read-only warehouse connections set up and checked against the SELECT-only access model
- Security testing of the deployment, its access controls and its API surface
- Backup, upgrade and runbook documentation for the GrowthBook stack you operate
How we hand over
- Written documentation of configuration, flag and experiment structure, and data source setup
- Side-by-side checks of experiment results against your existing Optimizely records before cutover
- Evidence and control documentation prepared for your compliance assessors, who issue any audit reports
- Knowledge transfer sessions with the engineers and analysts who will own GrowthBook day to day
- Clear list of open items, such as features on GrowthBook's paid tiers that you have chosen not to adopt
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Tracking of GrowthBook release notes and planning for upgrades in your change process
- Periodic review of warehouse query activity and data source permissions
- Scope changes handled through a written change to the original agreement
- Confirm current GrowthBook license terms and tier features directly with the vendor before you decide
