VWO vs PostHog: when each fits your testing stack
VWO fits teams that rely on its visual editor and a managed vendor to run marketer-led tests, while self-hosted PostHog fits teams that want experiments, heatmaps and session replay in one tool they run in their own infrastructure. The choice usually surfaces at a renewal, a data residency review or a cost review, when a team realizes its tests, behavior recordings and event data sit in three places it does not fully control. PostHog's self-host documentation describes a free Docker Compose (hobby) deployment under the MIT license, but it also states that self-hosted deployments are officially unsupported and that PostHog offers no customer support for product or infrastructure questions on self-hosted instances. That means the cost of operating PostHog is your own engineering time, not a vendor contract.
Before you compare features, check three things. First, the scale ceiling: the PostHog README says open-source deployments should handle about 100k events per month and recommends PostHog Cloud above that, so model your event volume against that figure. Second, licensing: the repository is MIT except for the ee/ directory, and premium features there require a PostHog license, so confirm with PostHog which features your plan needs and whether the posthog-foss repository covers them. Third, the sizing baseline: PostHog recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage, which you should price in your own cloud or data center.
The decision turns on three questions. Is testing led by marketers who depend on a visual editor, which VWO provides and which PostHog does not replace on a like-for-like basis? Do you need the data to stay under your own control, and can your team meet that requirement with a self-run stack? And can your team operate PostHog without vendor support, including upgrades, backups and incident response? If the answer to the first question is yes, keep VWO for those tests. If the answers to the second and third are yes, PostHog is a credible consolidation candidate, and a short proof of concept on a non-production instance will show whether the operating model is acceptable.
Which fits best: VWO vs PostHog by team scenario
This table maps five common team situations to the platform that usually fits better, along with the condition that makes each advantage matter. Read each row against your own staffing, data residency rules and mix of testing work, because the right answer changes when those conditions change.
| Scenario | Better fit | Why and when it matters |
|---|---|---|
| Marketer-led visual tests | VWO | VWO's visual editor lets non-engineers build and launch page tests. This advantage matters only when marketers launch tests without developer help. PostHog's experiments are driven mainly by code and feature flags, so expect developer time for each test. |
| Developer-led feature experiments | PostHog | When engineers wire flags and experiments into the application, PostHog keeps flags, experiments, analytics and replay in one tool. The fit holds if your team is comfortable owning the instrumentation and the self-hosted deployment. |
| Teams that need heatmaps and replay in one place | PostHog | PostHog bundles session replay and related analytics with experiments, so you avoid running a separate behavior tool beside a testing tool. Confirm that the replay features and retention you need are available in the edition you plan to self-host. |
| Regulated teams that need data to stay in their own environment | PostHog | Self-hosting keeps event and replay data on your servers, which suits data residency requirements. Before committing, confirm which features sit in the enterprise directory under a separate license, and ask your compliance lead which controls your assessor will expect to see evidenced. |
| Small teams without platform staff | VWO | Running PostHog yourself means owning upgrades, backups and capacity, and PostHog states self-hosted deployments are officially unsupported. If nobody on staff can run that work, a managed product may carry less risk even though it costs more over time. |
Where PostHog's free self-hosted deployment tops out
The free path is the Docker Compose hobby deployment, installed with a deploy-hobby script and covered by the MIT license. The PostHog self-host documentation recommends a server with 4 vCPU, 16 GB of RAM and more than 30 GB of storage, so budget for that host before anyone starts the install. Treat the hobby stack as a single node you operate yourself. The same documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support for product or infrastructure questions on self-hosted instances. Upgrades, backups, uptime monitoring and restore testing therefore sit with your team from the first day.
The README sets the scale ceiling for open-source deployments. It says they should scale to approximately 100k events per month, and it recommends moving to PostHog Cloud above that level. Estimate your event volume across every product you plan to run on the instance, including experiment exposures, pageviews and session replay, before you decide the hobby tier fits. Count the VWO traffic you are moving, not only the tests you already run. Ask PostHog to confirm in writing whether recordings count toward that figure and whether the guidance has changed, since the number comes from a README and may be revised.
The paid self-hosted product has its own deployment constraint. PostHog's self-host docs state that new Kubernetes deployments of the paid self-hosted product are no longer supported. If your platform team standardizes on Kubernetes, settle that question before you choose the paid route, and confirm with PostHog which self-hosted options remain available to you. Also check the license boundary: premium features in the ee/ directory need a PostHog license on a self-hosted instance. In practice, a free hobby instance works as a pilot environment. Production traffic above the README guidance should go to PostHog Cloud, which lists US (Virginia) and EU (Frankfurt) regions, or to a sized design you have validated against current PostHog documentation.
VWO vs PostHog: capabilities side by side
This table compares what VWO sells as one suite with what self-hosted PostHog provides. Read the PostHog column against the open-source core, then the ee directory and paid platform packages, and confirm each VWO row with your VWO account team before treating a gap as final. The main takeaway is that PostHog combines experiments, flags and replay in one codebase, while support and no-code testing need separate planning.
| Capability | VWO | PostHog self-hosted |
|---|---|---|
| A/B and split testing | Core product of the suite. Confirm current test types and plan limits with VWO. | Experiments are a listed product in the open-source core. Confirm which experiment types your version supports. |
| Visual no-code editor | Part of the VWO suite. Confirm editor access by plan with VWO. | Confirm with PostHog whether a visual editor exists in your version. Plan coded variants until verified. |
| Server-side feature flags | Sold alongside web testing. Confirm server SDK and flag scope with VWO. | Feature flags are a listed open-source product. Check which flag features, if any, sit in the ee directory. |
| Heatmaps | Sold as behavior analytics. Confirm heatmap coverage and retention by plan with VWO. | Confirm heatmap availability in your PostHog version before you plan to drop VWO Insights. |
| Session replay | Recordings are sold as behavior analytics. Confirm current retention and masking options with VWO. | Session replay is a listed open-source product. Retention and masking depend on your own configuration and storage. |
| Personalization | Offered within the VWO suite. Confirm which personalization features are included with VWO. | Not listed as a core product in the sources reviewed. Confirm with PostHog or plan a separate tool. |
| Statistics and experiment analysis | Confirm the statistical methods, sample size guidance and reporting with VWO. | Confirm the statistical methods and reporting in your version before relying on results for decisions. |
| Data location | Hosted by VWO. Confirm hosting region and data processing terms in the contract. | Self-hosted deployments run in your infrastructure. PostHog Cloud offers US (Virginia) and EU (Frankfurt) regions. |
| Licensing, support and access controls | Commercial subscription with vendor support. Confirm support levels and SSO or audit log inclusion with VWO. | MIT for the core, with ee directory under a separate license. Self-hosted instances get no vendor support. SSO, audit logs and custom roles are paid platform packages. |
How hosting, data location and licensing change the decision
Hosting and licensing decide more of this move than feature checklists do. VWO runs on vendor infrastructure, while self-hosted PostHog puts events, recordings and session data wherever you deploy it, but that choice carries licence and support obligations you must check before you commit.
Where event data lives
VWO stores test, visitor and behavior data on the vendor's hosting, so residency is governed by its contract and documentation. Self-hosted PostHog keeps analytics events, heatmap data and session recordings on infrastructure you pick. This matters most when a residency rule or a data processing agreement restricts where visitor data may sit. Confirm with VWO which regions and sub-processors apply to your account, and map where your PostHog instance and its database will run.
PostHog Cloud regions
If you want a managed PostHog option instead of running it yourself, the pricing page lists two hosting regions: US (Virginia) and EU (Frankfurt). Choose the region before you send data, because moving historical data later is not a simple switch. Teams with an EU-only residency requirement should confirm that the EU region meets their policy, and that session replay data is covered by the same commitment as event analytics.
MIT core, licensed ee directory
The PostHog repository is MIT licensed, but the ee directory is covered by a separate license. The README states that premium features from ee on a self-hosted instance require a PostHog license. Confirm with your legal team which features your design depends on, such as SSO or audit logs, because those can fall under the ee terms. Teams that require fully free software should evaluate the posthog-foss repository, which removes all proprietary code and features.
Identity and access as paid packages
SSO, audit logs, custom roles and project permissions are sold as platform packages on PostHog Cloud. If your internal security review expects SSO enforcement, role-based access and audit trails, map each requirement to the edition and licence that provides it before you design the rollout. For a self-hosted instance, confirm with PostHog whether the equivalent capability is available under your licence, and document any gap as a compensating control.
Support boundaries on self-hosting
PostHog states that self-hosted deployments are officially unsupported and that it does not provide customer support for product, infrastructure or other questions on self-hosted instances. Your team, or a implementation partner under a written scope, owns upgrades, backups, scaling and incident response. Ask who answers production incidents before a renewal decision, and confirm whether an external retainer covers the operational gap.
Compliance evidence you produce
Self-hosting moves evidence work to your side. You need records of where data is stored, who holds administrative access, how recordings are masked, how retention is enforced and how backups are tested. An auditor reviews those records, and DeployOpen prepares the systems and evidence for an assessment without issuing the audit result. Start by listing the controls your assessor will ask about, then assign an owner to each one before the migration begins.
What you lose in no-code testing when you move to PostHog
PostHog's experiments are built on feature flags and code-level setup, so the no-code workflow you have in VWO changes shape. Today, a marketer may open VWO's visual editor, change a headline or button, set a traffic split and launch. In PostHog, an experiment is attached to a feature flag and its variants are typically defined in code or through the flag and experiment configuration, which means someone with engineering access has to wire the variant into the page. Before you commit, confirm which VWO editor features your team uses today (visual changes, custom JavaScript, audience targeting, goal tracking, and any approval steps) and test the equivalent in a PostHog instance with a real page from your site. Do not assume a feature exists because the flag system supports it; check the current PostHog documentation and your own build.
Three questions decide how big this loss is. First, how many non-engineers create tests each month? If it is a handful of marketers launching small copy or layout changes, the cost is the developer time each change now needs. If it is a large group, you need a workflow for requests, review and release that does not depend on one engineer. Second, are visual variants the main workload, or are most tests server-side or logic-driven? Teams running mostly code-level experiments lose little. Teams running mostly visual tests should estimate how many changes per quarter would move into an engineering backlog. Third, who will analyze heatmaps and replays alongside experiments? In VWO these sit in one console, while PostHog brings them under one product set, so decide who owns the question of why a variant lost, and how that person will move between replay and experiment results.
Write these answers down before you migrate, and treat the first pilot as the test of the workflow rather than of the statistics. Pick one live VWO campaign, rebuild it in PostHog as the marketing team would need to do it, and time how long it takes and who had to act. If the result needs a developer for every change, plan for that as a recurring cost in your own team's capacity, or decide to keep VWO for visual work during a transition. Ask your implementation partner to document the handoff steps so the no-code gap is visible to the people who will feel it.
What each option costs to run, component by component
VWO is a commercial subscription, so the license is the recurring cost that sets the baseline. VWO's plans and their limits are presented on the vendor's pricing and quote process, and the prices are on the vendor quote, not stated here. Ask VWO to itemize the quote by product, because testing, personalization and behavior analytics are sold and limited separately.
- Licenses or subscriptions (recurring): the annual or monthly fee for each product module, plus any add-ons for domains, environments or recording capacity.
- Retention and recording limits (recurring): ask how long session recordings and insights are kept on your plan, since retention is a plan limit rather than a storage cost you control.
- Implementation and snippet work (one-time): installing the snippet, configuring campaigns and any agency or internal time to build tests.
- Staff time (recurring): marketers and developers who maintain campaigns, goals and governance inside the vendor console.
- Renewal changes (recurring risk): price and plan terms can change at renewal, so budget for a review each cycle.
Before renewing, request the quote with unit limits, overage rules and a written statement of which features are included in each plan.
PostHog Cloud is metered and hosted by PostHog, so the bill follows event volume and the plan you choose. The free tier includes the first 1 million analytics events every month, with 1 project and 1-year data retention, according to PostHog's pricing page. Pay-as-you-go raises the limit to 6 projects and 7-year data retention, and SSO, audit logs, custom roles and project permissions are sold as platform packages.
- Event-based usage (recurring): charges above the free allowance scale with analytics events, including web and product events, session replay and feature flag traffic.
- Projects and retention (recurring): moving from 1 project and 1-year retention to 6 projects and 7-year retention changes the plan cost, so model it against the data you must keep.
- Platform packages (recurring): SSO, audit logs and custom roles are separate sold items, so add them if your identity or audit rules require them.
- Migration imports (one-time): historical imports from Mixpanel or Amplitude are free of ingestion fees with the historical_migration flag, but a paid plan is needed to unlock import features.
- Staff time (recurring): event schema, dashboards and experiment setup remain internal work.
Ask PostHog to confirm which features require a paid plan in your region, US (Virginia) or EU (Frankfurt), and what a sustained event forecast would cost.
Self-hosted PostHog removes the vendor subscription for the open-source code, but you pay for infrastructure and people. The free Docker Compose (hobby) deployment is MIT licensed and installed with a deploy-hobby script. PostHog recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage, and says open-source deployments should scale to approximately 100k events per month before moving to PostHog Cloud. Features in the ee directory require a PostHog license.
- Hosting (recurring): the cloud or data center compute, network and storage for the recommended server or larger, billed by your provider.
- Storage and backups (recurring): event data grows with volume and retention, and backups need their own storage and restore testing.
- Staff time and upgrades (recurring): your engineers install, patch, upgrade and monitor the stack, and new Kubernetes deployments of the paid product are no longer supported.
- Monitoring and on-call (recurring): alerting for ingestion, storage and availability is your responsibility, since PostHog does not offer customer support for self-hosted infrastructure.
- Setup and optional support (one-time or retainer): initial deployment and hardening can be done internally or contracted, and any retainer is priced on the written scope.
Confirm your expected event volume against the approximately 100k events per month guidance, and confirm which ee features you need and whether a PostHog license is required.
How a move from VWO to self-hosted PostHog works
The sequence below moves VWO tests, heatmaps and recordings to self-hosted PostHog in an order that keeps live traffic and results safe during the overlap. It ends with a documented, closed VWO estate and a self-hosted PostHog instance your team operates.
Inventory running VWO tests and data
Export a list of every live and paused VWO campaign, its goal metrics, audience rules, traffic split, and the pages or domains it touches. Add the heatmap and session recording settings, including masking and retention, and the snippet placements on each site. Your product or growth lead and the engineer who owns the VWO snippet should sign off on the list. The step is done when every campaign has an owner and a stated decision: rebuild, retire, or keep running on VWO during overlap.
Decide which tests move and which stay
Sort the inventory into three groups: tests to rebuild in PostHog, tests to finish in VWO before the cutover, and tests to retire. Tests with a short remaining runtime often belong in the second group, since rebuilding them adds work for little result. Record the decision and the reason for each campaign so auditors and stakeholders can trace later changes. The step is done when a named owner has approved the split in writing.
Deploy and secure the self-hosted PostHog instance
Choose a deployment path before installing. PostHog's self-host documentation describes a free Docker Compose hobby deployment under the MIT license, installed with a deploy-hobby script, and recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. Confirm with PostHog whether that path fits your event volume, since the README says open-source deployments should scale to approximately 100k events per month. Your infrastructure team configures TLS, access control, backups and monitoring. The step is done when a restore from backup has been tested successfully.
Instrument feature flags and experiments in code
Add PostHog's SDK to the application and wrap each flag or experiment in a stable flag key, with the variant logic and the success event defined in code. Engineers should agree on naming conventions and on where the snippet for the visual layer will and will not run. Keep flag evaluation on the server where the outcome matters for security or pricing. The step is done when each new experiment has a documented flag key, a primary metric event and an owner in version control.
Rebuild the highest-value visual tests
Recreate the selected visual tests as code or as flags in PostHog, starting with the campaigns that drive the most revenue or conversions. Visual editing is where most teams lose time, because VWO's no-code editor lets marketers change pages without a deployment and PostHog's experiments rely more on engineering work. Ask the marketing team which no-code workflows they need to keep, and decide whether those become a deployment or are dropped. The step is done when each rebuilt test passes a QA check on desktop and mobile and its variant assignment is confirmed in PostHog.
Move historical data only if it is needed
Confirm first what PostHog can import. Its managed migrations import historical events from Mixpanel or Amplitude, using API credentials or JSONL files in an S3 bucket, and they do not cover VWO. Historical VWO results usually stay in VWO or an exported file kept under your retention policy. Ask PostHog to confirm this in writing, and note that direct imports cover at most one year of data, are not deduplicated and cannot be selectively deleted once imported. The step is done when the retention decision for VWO history is recorded.
Run both platforms in parallel and verify traffic
Keep the most important tests running on VWO and the rebuilt tests running on PostHog for a defined overlap period you agree in advance with the business owner. Compare assignment rates, page load impact and conversion counts between the two systems, and investigate any gap before it grows. Check that heatmap and recording coverage and masking settings match your policy in PostHog before you rely on them. The step is done when both platforms agree within the tolerance your analytics team set.
Close VWO campaigns and remove the snippet
Once live traffic is confirmed on PostHog, stop each VWO campaign in turn and document the final results export. Remove the VWO snippet from the site, then confirm in a browser that no VWO scripts load. Cancel or downgrade the VWO subscription only after the contract terms and exit or data export obligations are checked with the vendor. Keep the closure record with the decision log. The step is done when no VWO code runs in production and the decommission record is filed.
Questions buyers ask before switching from VWO to PostHog
Is self-hosted PostHog free to run?
The PostHog software is free to download and run under the MIT Expat license for the core repository, but the infrastructure and the people who operate it are not free. PostHog's self-host documentation describes a free Docker Compose hobby deployment, installed with a deploy-hobby script, and recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. Recurring costs include that server, backups, storage growth, and the engineering time to upgrade and monitor it. Ask your team to price the hosting and staff hours against your expected event volume, and note that the PostHog README says open-source deployments should scale to approximately 100k events per month before moving to PostHog Cloud.
How much effort does self-hosting PostHog take?
Effort depends mainly on event volume, the number of products you switch on, and how much of the stack you already run. Session replay, feature flags and experiments each add components and storage, so a deployment that starts as analytics can grow in load over time. Plan for installation, reverse proxy and TLS setup, backups, upgrades and monitoring, and check the self-host documentation for the current architecture before you size it. The README's 100k events per month guidance is the practical point where you should reassess whether a self-managed instance still fits your workload.
Why does PostHog say self-hosted deployments are unsupported?
PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support for product, infrastructure or other questions on self-hosted instances. That means your internal platform team owns every incident, upgrade and configuration decision, and community resources are the only public help. Before committing, name an owner for uptime, security patches and data recovery, and write a runbook that covers upgrades. Also note that new Kubernetes deployments of PostHog's paid self-hosted product are no longer supported, so check which deployment model fits your standards.
Can our own team do the PostHog migration without outside help?
Some teams can, especially if they already operate Docker, Postgres-backed services and a reverse proxy, and have someone comfortable with analytics instrumentation. The harder parts are rewriting VWO test logic, re-instrumenting events, validating that experiment statistics match your expectations, and keeping live tests running during cutover. An outside implementation partner can take a fixed, written scope covering installation, hardening, backups, instrumentation and documentation, while your team keeps ownership. DeployOpen implements, hardens, backs up, upgrades and documents self-hosted open-source platforms in your own infrastructure, and it prepares evidence for compliance assessments without issuing audit reports.
How long does a migration from VWO to PostHog take?
No supplied figure sets a fixed duration, so the pace is set by what you must move and how many live tests depend on VWO. Count your running campaigns, feature flags, goals, audiences and the number of pages with the VWO snippet, then decide which experiments will be rebuilt and which will be closed. If you import historical data, PostHog's managed migrations documentation says each direct import job covers at most one year of data and events are not deduplicated, so plan the import window and check for double counting. Ask any implementation partner for a timeline tied to this inventory in a written scope before work starts.
Do heatmaps and session replay come with PostHog?
PostHog's README groups its products into analytics, session replay, observability, feature flags, experiments, surveys and data pipelines, and lists session replay and feature flags among them. That covers the replacement for VWO Insights recordings and experiments in one tool, but you should confirm which capabilities, such as heatmaps, masking controls and retention, are available in the version and deployment you choose. Test masking of form fields and personal data on a staging instance before you record real users, and confirm retention settings against your privacy policy. Also check whether any feature you need sits in the ee directory, because that affects the next question.
How does the ee license affect features in self-hosted PostHog?
The PostHog repository is under the MIT Expat license, but the ee directory is covered by a separate license in its own LICENSE file. The README states that using premium features from ee on a self-hosted instance requires a PostHog license. If you need fully free software, PostHog points to the posthog-foss repository, which is purged of all proprietary code and features. Before you design the deployment, list the features you depend on, map each one to the license that covers it, and have your legal or procurement team review the ee terms with the current license file.
When should we stay on VWO instead of moving to PostHog?
Stay on VWO if your team depends on no-code visual editing by marketers, has many active campaigns that cannot be paused for a rebuild, or needs a vendor to own uptime and support. Staying also makes sense if your event volume is high enough that self-hosting would require significant operations work, or if you lack an owner for upgrades and security patches. Moving is more likely to fit if you want experiments, flags, heatmaps and replay in one system you control, and your engineers are comfortable writing test code. Ask VWO for its current plan limits in writing, and compare them with your inventory before you decide.
How DeployOpen helps you evaluate and implement self-hosted PostHog
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For VWO vs PostHog, we start with a written scope that tests whether PostHog fits your experiments, heatmaps and session replay needs, then build and hand over only what that scope agrees.
How we scope
- Inventory your running VWO tests, heatmap and recording use, and the teams that rely on each
- Confirm which PostHog features you need and whether they fall in the MIT-licensed core or the ee directory
- Agree in writing the deployment target, hosting location, data retention and who owns operations
How we build
- Deploy PostHog in your own cloud account or data center, sized against the published self-host guidance
- Configure masking for session replay and heatmap data, and verify it on pages that handle sensitive input
- Test experiment metrics and event tracking against your current VWO results before any traffic moves
How we hand over
- Document the architecture, backup routines, upgrade steps and the list of features you chose to leave out
- Record which VWO capabilities, such as no-code visual editing, will need a developer or a different tool
- Walk your platform and product teams through running experiments and reviewing recordings on the new stack
How we support
- Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Note that PostHog does not support self-hosted instances, so confirm who answers production incidents before go-live
