Does self-hosted GrowthBook cost less than VWO for your team?
The answer depends on seats, flag volume, warehouse query spend and the internal time needed to run the platform, not on a licence line alone. VWO's plan prices are not published on this page, so start with a written quote from VWO that lists the modules, seat count, environments, domains and recording retention in your current contract. Then compare that against GrowthBook's self-hosted Open Source plan, which is free with unlimited users and unlimited API requests but allows only one project. Most teams with more than one product area will hit that project limit first, so count projects before you count seats.
Paid GrowthBook options change the picture. The GrowthBook pricing page lists Cloud Pro at $40 per seat per month for up to 30 users and 3 projects, and Enterprise at custom pricing. Self-hosted Enterprise adds SSO and SCIM, advanced permissioning, approval workflows, safe rollouts, ramp schedules and holdouts, none of which the free self-hosted plan includes. Ask GrowthBook for a written Enterprise quote for a self-hosted deployment, and confirm which of these features your governance and release controls require before you total the two sides.
The costs that never appear on a licence line are the ones to model. You pay for hosting the single Docker image that bundles the front end, API and statistics engine, plus a MongoDB or compatible database, which the self-hosting documentation suggests running as a managed service in production. Warehouse queries run as read-only SELECT statements in your own Snowflake, BigQuery or similar account, so compute spend sits with your data platform team and appears on your warehouse bill. Ask that team to estimate query cost at your expected experiment volume, then add internal engineering time for flag migration, upgrades and on-call support.
Which cost components differ between VWO and self-hosted GrowthBook
This table compares the cost components a team pays for under VWO and under self-hosted GrowthBook, with each row marked as one-time or recurring. VWO plan limits and prices are set in your written order form, so confirm them there before comparing. The main takeaway is that self-hosting replaces a vendor subscription with infrastructure, database, warehouse and staff time that continue to recur.
| Cost component | VWO (commercial) | Self-hosted GrowthBook |
|---|---|---|
| Licence or subscription (recurring) | Billed per plan (Growth, Pro, Enterprise) and per product. Confirm flag, environment, domain and recording retention limits in the order form. | The Open Source plan is free for self-hosting, with unlimited users, 1 project and unlimited API requests. Paid self-hosted Enterprise is quoted separately. |
| Enterprise controls (recurring if licensed) | Controls such as SSO, permissions and approval steps depend on the plan you buy. Confirm each one in writing. | Self-hosted Enterprise adds SSO and SCIM, advanced permissioning, approval workflows, safe rollouts, ramp schedules, sticky bucketing, holdouts and multi-armed bandits. The free plan does not include these. |
| Application hosting (recurring) | Included in the subscription. Confirm where data is hosted and which regions are offered. | GrowthBook's front end, API and Python statistics engine ship in one Docker image. Run it on Docker or Kubernetes with the official Helm chart. Compute is billed by your cloud provider. |
| Metadata database (recurring) | None for the customer to run. | Stores metadata in MongoDB or a compatible database. Docs suggest a managed service such as MongoDB Atlas or AWS DocumentDB for production. You pay the service or the staff who run it. |
| File storage (recurring) | None for the customer to run. | Choose local storage, Amazon S3 or Google Cloud Storage for uploads. Storage charges depend on upload volume and retention. |
| Warehouse queries (recurring) | Analysis runs inside VWO. Ask whether any data export or warehouse connection carries an extra fee. | GrowthBook runs read-only SELECT queries on your warehouse and receives only aggregated statistics. Warehouse compute is billed by your provider and grows with experiment volume. |
| Implementation and migration (one-time) | Inventory running campaigns and flags, rebuild tests, and swap the VWO snippet and SDKs. Ask VWO for export options. | Plan the SDK change, metric definitions and test rebuilds. Documented importers cover LaunchDarkly and Statsig. Ask GrowthBook whether a VWO import path exists. |
| Operations, upgrades and skills (recurring) | The vendor handles upgrades. Confirm support hours and response terms in the contract. | Your team schedules image, database and Helm chart upgrades and tests them in staging. GrowthBook publishes releases such as v5.1.0. Support is available through a paid plan or a retainer such as DeployOpen's. |
How VWO's Growth, Pro and Enterprise limits shape the bill
VWO's plan limits are not published as figures in this research, so treat any cost comparison as provisional until you have a written quote. The Growth, Pro and Enterprise tiers were reviewed only in demo form, which means the number of feature flags, environments, domains and the recording retention period may differ from what your account would receive. Ask VWO to state each limit in the order form or quote, and check that it applies to your contract term. Pay particular attention to how environments are counted for server-side flags, since a limit that looks generous on a pricing summary can run out once you add staging and production copies of the same flag set.
VWO sells testing, personalization and behavior analytics as a bundle, so a single line on the invoice can cover several products with different units of measure. That makes a like-for-like comparison hard. GrowthBook is a feature flag and experimentation tool, and it does not replace heatmaps, recordings or personalization, so the cost you avoid by moving may be only part of what VWO charges. Build your comparison by product: testing and flags on one line, behavior analytics on another, and any personalization module on a third. Ask the vendor to price each module separately so you can see which parts you would actually replace.
Behavior analytics deserves its own check. Recording retention for VWO Insights is governed by its separate behavior analytics plan rather than by the testing tier, so a limit you confirm for experiments does not tell you how long session recordings are kept. Ask for the retention period for Insights in the order form, along with the number of recorded sessions included and any overage terms. If retention is part of your data residency or privacy commitments, record the agreed period in your renewal file so it can be compared against the self-hosted option at the time of decision.
What moves the GrowthBook side of the comparison
The GrowthBook side of this comparison is not one price. Each driver below changes a different cost line, from the paid tier and identity features to the database, the warehouse bill and the people who run the stack. Size them separately before you compare totals with VWO.
Seats and SSO requirements
The free self-hosted Open Source plan allows unlimited users, but single sign-on and SCIM provisioning sit in the self-hosted Enterprise tier. If your identity provider must federate logins and deprovision users automatically, that requirement moves you off the free plan. Ask GrowthBook for a written quote covering your exact seat count and whether approval workflows and advanced permissioning are needed, since those also sit in Enterprise.
Projects beyond the free one
The self-hosted Open Source plan includes one project. Splitting products, teams or business units into separate projects is a licensing decision before it is a technical one. Count the projects you need on day one and in the next year. Each additional project may require a paid tier, so confirm whether your structure can live inside a single project with separate environments and permissions.
Warehouse size and query frequency
GrowthBook runs read-only SELECT queries against your own warehouse, so compute for experiment analysis is billed by your warehouse provider, not by GrowthBook. Cost rises with the volume of events scanned, the number of metrics, and how often results refresh. Before you commit, ask your data team to estimate scan volume per experiment and to set refresh schedules. Confirm which warehouse your events already live in, such as Snowflake or BigQuery.
Availability and hosting shape
A single Docker container suits a pilot, but production availability pushes you toward a managed MongoDB service such as MongoDB Atlas or AWS DocumentDB, and toward Kubernetes with the official Helm chart. Each choice adds a recurring infrastructure line and an on-call burden. Ask whether your uptime target requires redundant application nodes and a replicated database, and whether your platform team already runs Kubernetes.
Statistics and data engineering skills
Self-hosting moves analysis work onto your team. Someone must define metrics, validate SQL against your event schema, and interpret results without over-reading early data. A team with an experienced data engineer and an experimentation lead needs less outside help than one without. If those skills are thin, budget for training or a fixed-scope implementation engagement, and confirm the expected effort in a written scope before work starts.
Enterprise features and migration scope
Advanced features such as holdouts, sticky bucketing, safe rollouts and multi-armed bandits appear in the self-hosted Enterprise tier, so check which ones your VWO campaigns depend on. Migration also adds one-time work: rebuilding visual tests as coded experiments and checking importer output, which GrowthBook notes may miss advanced setups. Ask for a feature-by-feature gap list before you sign.
How warehouse queries change the experimentation budget
Running experiments against your own warehouse moves the analysis cost from a vendor's event meter onto your existing data platform bill, where you can see and tune it.
Connect GrowthBook to the existing data source
Your data engineering or analytics team adds the warehouse connection in GrowthBook, using a read-only credential scoped to the schemas that hold exposure and metric tables. GrowthBook supports a range of sources, including BigQuery, Snowflake, Redshift, Databricks, ClickHouse, Postgres, MySQL and Trino. Confirm with your team that the credential cannot write, drop or alter tables, and that the warehouse's own query tags or labels are set so experiment queries can be identified later. The step is done when a test metric query returns results in the GrowthBook interface.
Define exposure and metric queries
Analysts define the metrics each experiment will read, such as conversion events or revenue per user, and the exposure source that records which users saw which variation. Each metric becomes a SQL query that GrowthBook runs against the warehouse. Ask the data team how many metrics are expected per experiment and whether the underlying tables are partitioned or clustered by date, because both affect how much data each query scans. The step is done when every planned metric has been validated against a known period of data.
Run read-only SELECT queries on schedule
When an experiment is running, GrowthBook issues SELECT statements to the warehouse to compute results, and it only reads from the data source. The number of queries depends on how often results refresh, how many experiments and metrics are active, and how large the scanned tables are. Ask your data team for the current refresh frequency and for a recent month of query volume and cost, broken down by tool or label. The step is done when query activity for GrowthBook appears in the warehouse's usage reporting.
Aggregate results inside the warehouse flow
The statistical work happens after the warehouse returns aggregated figures, so GrowthBook receives counts, means and variances for each variation rather than row-level event records. The Python statistics engine in the GrowthBook deployment then computes significance and intervals from those aggregates. Confirm with your privacy or security team that this matches the data-handling approach you have documented, and record what leaves the warehouse in your data flow diagram. The step is done when a sample experiment result can be traced back to the aggregated query output.
Track warehouse spend against experiment activity
Finance and the data team review warehouse charges for experiment queries against the number of experiments running and the refresh settings in use. Compute and storage are billed by your warehouse provider under your existing contract, so changes in experiment volume show up on that invoice rather than on a GrowthBook line item. Ask the warehouse vendor or your account team how query costs are billed for your edition and whether reserved or committed capacity applies. The step is done when the team agrees on a monthly review and a threshold that triggers a look at refresh frequency or metric count.
Compare total cost with the vendor quote
Put the warehouse query estimate next to the GrowthBook licensing tier you need, the hosting and database costs described elsewhere on this page, and the commercial platform's quote for the same experiment volume. Ask each vendor for pricing in writing against an agreed usage profile, and ask GrowthBook which self-hosted features you require, since Enterprise capabilities are licensed separately from the free self-hosted Open Source plan. The step is done when all cost components sit in one comparison sheet with the assumptions stated.
Questions buyers ask about VWO and GrowthBook costs
What drives the cost of self-hosting GrowthBook compared with VWO?
The main cost drivers are infrastructure and staff time, and the Open Source tier carries no per-seat subscription. Self-hosted GrowthBook bundles its front end, API and statistics engine in one Docker image and stores metadata in MongoDB or a compatible database, so you pay for the servers or cluster that run it, a managed database that the self-hosting docs suggest for production, file storage, and the people who operate upgrades and backups. Warehouse queries add cost in your own data platform, because GrowthBook runs read-only SELECT queries against your warehouse and that compute appears on your warehouse bill. VWO's plan prices are not supplied here, so request a written quote covering the plans, add-ons and recording retention you need. Compare one-time migration work separately from recurring operations and warehouse spend.
How long does a migration from VWO to GrowthBook take?
The duration depends on scope, and no migration timeline is supplied here. The drivers are the number of running campaigns, how many visual tests must be rebuilt in GrowthBook's editor or as coded experiments, how many flags and targeting rules exist in application code, how many metrics must be defined on your warehouse, and how many integrations change. Campaign inventory, flag cleanup, and a period of parallel running before VWO campaigns close will extend the work beyond the technical cutover. Ask for a timeline tied to a written inventory of campaigns, flags, metrics and integrations, and confirm which steps the vendor, a partner or your own team will own.
Can an internal team migrate from VWO to GrowthBook without outside help?
It can, for a small and well-documented setup, but the answer depends on skills and capacity. The team needs people who can deploy and operate a Docker or Kubernetes workload with a MongoDB-compatible database, configure SSO and backups, connect a data warehouse using read-only credentials, and change application code to call GrowthBook SDKs. You also need someone who can define metrics and read experiment statistics, and an owner for rebuilding visual tests and coordinating with marketing. GrowthBook's migration docs cover importing, but importers document limits for advanced setups, so plan for manual rework. If skills or capacity are short, DeployOpen can plan, implement, integrate and document the migration under a fixed scope agreed in writing before work starts.
Which GrowthBook features require the paid self-hosted Enterprise tier?
According to GrowthBook's pricing page, the self-hosted Enterprise tier adds these features beyond the free self-hosted Open Source plan:
- SSO and SCIM
- Advanced permissioning
- Approval workflows
- Multi-armed bandits
- Safe rollouts
- Ramp schedules
- Sticky bucketing
- Holdouts
Your team may need only some of these, so list the ones you rely on today, such as SSO for access control or holdouts for measurement. Enterprise pricing is custom, so confirm the current inclusion of each feature on the pricing page and request Enterprise pricing in writing before you budget for it.
Does GrowthBook's license allow use of its enterprise directories?
Code outside GrowthBook's enterprise directories is MIT Expat licensed, which permits broad use, according to the project's LICENSE file. The directories packages/back-end/src/enterprise, packages/front-end/enterprise and packages/shared/src/enterprise fall under the GrowthBook Enterprise License, so code in them is governed by separate terms. Before you deploy features from those directories, have your legal team read the LICENSE file and the Enterprise License, especially if you modify the build or offer GrowthBook-based services to others. Ask GrowthBook to confirm in writing which terms apply to your self-hosted Enterprise tier, and record that confirmation in your procurement file.
What does the free self-hosted GrowthBook plan limit?
GrowthBook's pricing page lists the self-hosted Open Source plan as free with unlimited users, one project and unlimited API requests. Projects are the main constraint, so a team that needs separate projects for brands, product lines or regions will reach the limit at one. The hosted Cloud Pro plan is listed at $40 per seat per month for up to 30 users and 3 projects, but that is a cloud subscription, so it does not change the self-hosted limits. Decide whether separate projects are required for ownership and access control, or whether tags and naming conventions are enough. Then check which Enterprise features you need before choosing between free self-hosting and a paid self-hosted tier.
What should we request in a quote for a self-hosted GrowthBook migration?
Ask for a fixed-scope proposal in writing, with deliverables and timeline agreed before work starts. DeployOpen does not publish a price list, and a quote follows from that written scope. Include:
- Projects, environments, applications and SDKs in scope
- An inventory of VWO campaigns, visual tests, flags and metrics, with what migrates and what is retired
- Hosting target, database choice, backups, and Docker or Helm deployment
- Warehouse connections, read-only credentials and metric definitions
- Enterprise features in scope, and whether the Enterprise tier is quoted separately
- Cutover, parallel running and VWO closure steps
- Upgrade handling after handover, noting that GrowthBook v5.1.0 was released on September 22, 2026
Ask the vendor to identify which items are one-time and which recur.
What a move from VWO to GrowthBook costs in effort
The effort of leaving VWO sits mostly in people's time, not in software licenses, so start by inventorying what is actually running. List every live campaign, its traffic allocation, its goal and its audience rules, and separately list every feature flag or server-side test your engineers have wired into the product. Each item is either a visual test to rebuild, a coded experiment to port, or a stale artifact to retire. Ask your VWO account team to export campaign and goal configurations in a form you can read, and confirm what that export contains, since no supplied fact documents a VWO-to-GrowthBook importer. GrowthBook's documented importers cover LaunchDarkly and Statsig, so treat VWO migration tooling as unconfirmed until the vendor states otherwise in writing.
The recurring effort is the rebuild. Visual tests built in VWO's editor must be recreated in GrowthBook's visual editor or rewritten as coded experiments, and the second route usually needs developer time because the variation logic moves into your codebase. Swapping the VWO snippet and any SDKs is a release-managed change that touches every page or service where the old code loads, so plan it per surface and confirm that both tools are not double-counting exposures during the overlap. Expect your data engineers to define metrics on your own warehouse, since GrowthBook reads results from sources such as Snowflake or BigQuery with read-only SELECT queries. Those metric definitions are one-time work per metric but must be reviewed whenever event schemas change.
Closing campaigns is the step most likely to break live tests. Decide for each running campaign whether it finishes in VWO, is restarted in GrowthBook, or is stopped with a documented decision, and avoid moving traffic between tools mid-test, because the two systems will assign users to variants differently. Ask GrowthBook and your internal analytics owner to agree on how overlapping results will be reported during the transition. Ask your implementation partner to write the cutover plan as a fixed-scope deliverable with rollback steps for each surface, and ask for the effort split between your team and the partner so you can compare it with a quote.
How DeployOpen scopes a fixed-price GrowthBook implementation
DeployOpen approaches VWO cost vs self-hosted GrowthBook as a written, fixed-scope engagement inside your own cloud accounts, data centers or air-gapped networks. We agree on what is replaced, what is migrated and what evidence is delivered before any work starts, so your team can compare the real cost components against a quote built from that scope.
How we scope
- Inventory every VWO plan component you pay for, including flags, environments, domains and recording retention, and map each to a GrowthBook counterpart.
- Confirm which GrowthBook features you need, such as SSO, approvals or holdouts, and whether they fall under the self-hosted Enterprise tier.
- Agree in writing on the warehouse sources, metrics and hosting target, and on the deliverables and milestones before work begins.
How we build
- Deploy GrowthBook in your environment, with MongoDB or a compatible managed database, using the Docker image or the official Helm chart.
- Connect GrowthBook to your existing warehouse so experiments run read-only SELECT queries against your own data.
- Rebuild priority tests and flags in GrowthBook, then test SDK integration and statistics results against your current VWO readings.
How we hand over
- Document the architecture, configuration, data source connections, metric definitions and the VWO shutdown steps in a handover pack.
- Walk your platform and analytics teams through running experiments, managing flags and reviewing results before closing the engagement.
- Provide the evidence your assessors or internal auditors will ask for, while noting that independent auditors and certification bodies issue any formal attestation.
How we support
- Ask about upgrade and backup responsibilities during scoping, since GrowthBook releases such as v5.1.0 need planned updates.
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, priced separately from the fixed-scope build.
- Confirm with us which security testing, such as application or API testing, you want scheduled against the GrowthBook deployment.
