Which fits: LaunchDarkly or PostHog for flags and analytics in one tool
Choose LaunchDarkly when feature flags and releases are the core need and product analytics already lives somewhere else. Choose self-hosted PostHog when you want flags, experiments and product analytics in one tool that runs inside your own infrastructure, and when your event volume and internal support capacity can carry it. The decision turns on three things: how much analytics you actually need, who will operate and support the stack, and how many events you expect each month.
PostHog's free self-hosted deployment, the Docker Compose hobby install, is sized for small volumes. The PostHog README says open-source deployments should scale to approximately 100k events per month and recommends PostHog Cloud above that, and the self-host documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage as a starting point. Confirm your projected monthly events against that ceiling before you plan around it. PostHog also states that self-hosted deployments are officially unsupported and that it does not offer customer support for product, infrastructure or other questions on them, so your own engineers or an implementation partner carry the operating load.
If you move to self-hosted PostHog, budget for the people who will run it, not only the server. Ask LaunchDarkly for a renewal scope that separates flag usage from analytics, then compare that with what a self-hosted deployment needs in staff time for upgrades, backups and incident response. Confirm which PostHog features you need from the ee directory, since the PostHog repository README states that premium features there require a PostHog license. If the team mainly needs release control, a flag-first tool may fit better, and the sibling comparisons cover that path.
Which option fits which scenario
This table matches common LaunchDarkly exit scenarios to the option that fits best, along with the condition that drives the choice. Read each row by starting with your data volume, whether you need analytics next to flags, and where your event data must live. Where PostHog is not the right answer, the table points to Unleash or GrowthBook.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Flags only, no product analytics | Unleash or Flagsmith | PostHog's value is its analytics stack. If you only replace release flags, Unleash fits well, subject to its 1 project and 2 environment limit on Open Source. |
| Flags plus product analytics at low volume | Self-hosted PostHog | A hobby deployment is sized around roughly 100k events per month. Below that, one tool covers flags, experiments and analytics on your own server. |
| Flags plus analytics at high volume | PostHog Cloud or a dedicated analytics stack | PostHog's README recommends moving to PostHog Cloud above about 100k events per month. Confirm your event volume and the cost of running the stack before choosing self-hosting. |
| Experiments tied to a data warehouse | GrowthBook | GrowthBook runs read-only SELECT queries against your warehouse and transmits only aggregated statistics. Choose it when the warehouse is the system of record for metrics. |
| Strict data control with in-house operations | Self-hosted PostHog or Unleash, with your own support plan | PostHog's self-hosted deployments are officially unsupported, and it offers no customer support for them. Teams need internal ownership or a separate support arrangement. |
| Need for enterprise governance such as SSO and approvals | Unleash Enterprise or self-hosted GrowthBook Enterprise | PostHog sells SSO, audit logs and custom roles as platform packages. Confirm which features your self-hosted edition includes before you commit. |
Where event data lives and who runs the stack
PostHog can run as a managed cloud service or on your own servers, and the two models put event data and operational responsibility in different places. LaunchDarkly keeps its flag management in its SaaS, so the question for both products is who holds the data, who runs the stack and who answers when something breaks.
PostHog Cloud regions
PostHog Cloud offers two hosting regions, US (Virginia) and EU (Frankfurt). Choosing a region determines where analytics events and flag evaluation data are stored under PostHog's managed service. Confirm the region for each project, check whether session data follows the same region, and ask PostHog where support and sub-processor access happen for your account.
Self-hosting on your infrastructure
Self-hosting moves event storage, flag evaluation and the database into a environment you operate, such as your own cloud account or data center. The data stays under your control, but patching, backups, scaling and incident response become your team's work. Confirm which PostHog deployment you run, because the free and paid self-hosted options differ in scope.
Hobby Docker Compose deployment
The free hobby deployment is a Docker Compose setup under the MIT license, 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 the README says open-source deployments should scale to about 100k events per month before moving to PostHog Cloud. Treat it as a pilot or low-volume setup unless your load testing shows otherwise.
LaunchDarkly's SaaS model
LaunchDarkly manages flag definitions, targeting and the dashboard in its hosted service, and its Relay Proxy keeps evaluation inside your network. Your team does not patch or scale the control plane, but flag configuration and audit history live in the vendor's environment. Ask LaunchDarkly where each data type is stored and which Relay Proxy setup you rely on.
SSO and audit logs as platform packages
On PostHog Cloud, SSO, audit logs, custom roles and project permissions are sold as platform packages rather than included in every plan. A self-hosted team must check which of these features its chosen PostHog edition includes, since enterprise features sit in the ee directory under a separate license. Map your identity and audit requirements before choosing a deployment model.
No vendor support for self-hosted PostHog
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. Your team or a implementation partner must own troubleshooting, upgrades and incident response. Build that ownership into your runbook and staffing plan, and confirm any support you buy in writing.
Compliance readiness, not certification
Hosting location and access controls feed into compliance assessments, but they do not make a deployment compliant on their own. Document where events are stored, who can read them, how access is reviewed and how the platform is patched, then ask an independent auditor to assess the result. DeployOpen prepares these controls and evidence; it does not issue audit reports or certifications.
What PostHog's free self-hosted deployment is sized for
PostHog's free self-hosted option is a hobby deployment, not a production platform for a large flag estate. The self-host documentation offers a Docker Compose setup 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. The README says open-source deployments should scale to approximately 100k events per month and recommends moving to PostHog Cloud above that. For a team whose main need is feature flags, the first question is whether product analytics volume will stay under that figure once every page view, click and custom event is captured, because flag evaluations and analytics events are not the same workload.
The more consequential limit is on the paid self-hosted product. PostHog's self-host documentation states that new Kubernetes deployments of its paid self-hosted product are no longer supported. Teams that plan a Helm or cluster-based rollout for an internal platform should not assume that path is open to them, and should confirm the current status with PostHog before designing around it. Compose remains the documented route for the free edition, so capacity planning has to fit a single-host model with its own backup, upgrade and failover plan.
Scale planning should start from event volume, retention and ownership. Ask for a written estimate of monthly events from each application, check how many of them are flag evaluations versus analytics, and decide whether the team will run the stack itself. PostHog also states that self-hosted deployments are officially unsupported and that it does not offer customer support for product or infrastructure questions on them. If the stack must be dependable for production releases, budget for an internal or partner operations function, or move flag delivery to a dedicated tool such as Unleash documentation on getting started and keep analytics separate.
What each option costs to own
This table compares who is paid for what under LaunchDarkly, PostHog Cloud and self-hosted PostHog, separating one-time work from recurring spend. Read each row as a cost component, then use the final rows to build the questions you send to vendors and your own platform team.
| Cost component | LaunchDarkly (hosted) | PostHog Cloud or self-hosted PostHog |
|---|---|---|
| Base billing unit | Service connections and client-side monthly active users, per LaunchDarkly's pricing page | PostHog Cloud bills usage; the first 1 million analytics events each month are free on the Free plan (PostHog pricing page). Self-hosted PostHog has no PostHog subscription unless you buy a paid license for ee/ features |
| Governance and security add-ons | Enterprise-only governance features are sold on top of the base plan (confirm the list in the written quote) | SSO, audit logs, custom roles and project permissions are sold as platform packages on PostHog Cloud, per the pricing page. Self-hosted use of ee/ premium features needs a PostHog license |
| Free tier limits | Confirm the free and trial scope with LaunchDarkly before planning a parallel run | Free plan: 1 project and 1-year data retention. Pay-as-you-go: 6 projects and 7-year retention (PostHog pricing page). Open-source Docker Compose deployment carries no event fee but scales to about 100k events per month |
| Infrastructure to host | None for the SaaS control plane. Your own Relay Proxy or Edge instances still run in your network | Hobby deployment recommends a server with 4 vCPU, 16 GB RAM and more than 30 GB storage (PostHog self-host docs). Larger traffic needs more compute, storage and backups that you buy and operate |
| One-time implementation and migration | Export flag and segment definitions through the REST API, then rebuild targeting elsewhere if you leave (confirm effort with your team) | Historical imports from Mixpanel or Amplitude are free of ingestion fees with the historical_migration flag, but a paid product analytics plan unlocks the import features. Direct imports cover at most one year per job, and imported events cannot be selectively deleted |
| Recurring operations and support | Vendor support is included in the contract; confirm the support tier in writing | Self-hosted deployments are officially unsupported, and PostHog offers no customer support for infrastructure questions. Upgrades, backups, monitoring and on-call fall to your staff or a retained partner |
| Staff time | Low for administration, but integration engineers still own SDK changes and flag hygiene | Plan platform engineering time for upgrades, storage growth, Kubernetes or Docker maintenance and incident response. New Kubernetes deployments of the paid self-hosted product are no longer supported |
| What to request in a written quote | Billing unit for your service connections and MAU, overage terms, support tier, data export costs and any parallel-run allowance | Event volume forecast and retention needs, plan and platform package prices, license terms for any ee/ features, hosting sizing, migration scope and who handles upgrades and incidents |
How a move from LaunchDarkly to PostHog works
The sequence separates flag migration from analytics migration, so each side is moved with the right tool and the team knows what carries over and what does not before any SDK changes.
Inventory flags, segments and experiments
Engineering and product owners list every LaunchDarkly flag, segment, environment and running experiment, noting which are release toggles, which are long-lived configuration and which feed reporting. Export the definitions through the LaunchDarkly REST API using an access token so the inventory comes from the source system, not from memory. The step is done when every flag has an owner, a status and a decision to migrate, retire or keep in LaunchDarkly until later. Expect some flags to be stale, since removing them first shrinks the mapping work.
Decide which analytics history to bring
Decide separately whether historical product events need to move into PostHog. LaunchDarkly flag definitions are configuration, not analytics data, so they never arrive through an analytics import. If you do need history, PostHog's managed migrations import events directly from Mixpanel or Amplitude with API credentials, or from JSONL files in an S3 bucket, and cover at most one year per direct import job. Events are not deduplicated, and there is no way to selectively delete imported event data, so confirm the source and the date range with your analytics owner before running anything. Confirm the current PostHog plan requirements with PostHog, since the migration docs state a paid product analytics plan is needed to unlock import features.
Map flag targeting to PostHog's model
Translate each LaunchDarkly targeting rule, percentage rollout, multivariate variant and prerequisite into the PostHog feature flag model, which uses release conditions, rollout percentages and multivariate variants. Write the mapping as a table with one row per flag, listing the source rule, the target condition and any behavior that differs. Pay attention to how each system buckets users, because a changed hash or identifier can move users between variants during a partial rollout. The step is done when a reviewer has signed off on every row and every flag that cannot be mapped cleanly has a documented workaround or a decision to keep it in LaunchDarkly.
Build the flag and experiment mapping in PostHog
Create the flags and experiments in a PostHog test environment from the mapping table, starting with low-risk release flags before experiments. Check each flag against the same test users in both systems and record any evaluation differences. Experiments need their metrics and exposure events set up in PostHog, which is a separate task from the flag definitions, so involve the analytics owner early. The step is done when the test evaluations match the mapping for every migrated flag and each experiment has a defined metric and exposure event.
Run both systems in parallel behind an abstraction layer
Place an internal flag interface in front of both LaunchDarkly and PostHog so application code asks one function for a value and the backend decides which system answers. The OpenFeature API can serve this role, with a LaunchDarkly provider for the current system and a PostHog provider for the target, if the SDK languages in use are covered. Switch flags one at a time, comparing results and logging mismatches. The step is done when the mismatch log is empty for a full review cycle of each migrated flag and the team agrees on the cutover order.
Cut over SDKs and retire LaunchDarkly calls
Replace the LaunchDarkly SDK calls in each service and client application with the PostHog SDK or the OpenFeature provider, in the order agreed in the previous step. Confirm the client-side and server-side SDKs in use have PostHog equivalents, since coverage differs by language. Remove the abstraction layer only after the last flag has moved and no service still calls LaunchDarkly. The step is done when telemetry shows no LaunchDarkly evaluations for a full cycle and the application team confirms each service reads flags from PostHog.
Plan the self-hosted operations and support model
Decide who runs the self-hosted PostHog deployment before cutover, because PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog offers no customer support for product, infrastructure or other questions on self-hosted instances. Its free Docker Compose hobby deployment is recommended for a server of 4 vCPU, 16 GB of RAM and more than 30 GB of storage, and PostHog's README says open-source deployments should scale to roughly 100k events per month before moving to PostHog Cloud. Ask whether the expected event volume and any Kubernetes plans fit these limits, and name the internal or partner owner for upgrades, backups and incidents. The step is done when the operating owner, the volume ceiling and the escalation path are written down and accepted.
Retire LaunchDarkly after a verified cutover
Once all flags and experiments run from PostHog and the operating model is accepted, export a final copy of the LaunchDarkly definitions and audit history for your records, then plan the subscription end date with your contract owner. Keep the export in your own storage with the same access controls as other configuration records. The step is done when the final export is verified as readable, the team has confirmed no service depends on LaunchDarkly, and the contract end has been recorded with the procurement owner.
When Unleash or GrowthBook fits better than PostHog
Choose Unleash when the main need is release flags and you do not need product analytics in the same tool. Unleash's self-hosted deployment runs the server from the unleashorg/unleash-server image against PostHog-independent PostgreSQL 15 or later, with the admin UI and API on port 4242. The catch is the Open Source edition, which allows 1 project and 2 environments with basic roles, so any team that needs several products, a staging and production split across multiple projects, or SSO and SCIM provisioning will be looking at Unleash Enterprise. Confirm the current limits on the Unleash pricing page before you size the deployment.
Licensing and edge design deserve a check before you commit. Starting with Unleash v8.0.0, the server source moved from Apache 2.0 to AGPLv3, while the official open-source Docker images remain under Apache 2.0. Unleash states that running those images unmodified is not affected, but an internal platform team that patches the server should have legal review the obligations. If your design relies on Unleash Edge for scale, note that the open-source version of Edge reaches end of life on December 31, 2026, so plan an Enterprise path or an alternative caching layer within that window.
Choose GrowthBook when experiments matter more than flags and your event data already lives in a warehouse. GrowthBook analyzes experiments against your own source, including BigQuery, Snowflake, Postgres and Trino, running only SELECT queries and transmitting aggregated statistics. PostHog's experimentation stores events in its own pipeline, so this model changes where the data sits and who governs it. The self-hosted GrowthBook stack bundles the Next.js front end, Express API and Python statistics engine in one image and stores metadata in MongoDB or a compatible database. Its MIT license applies outside the enterprise directories (packages/back-end/src/enterprise, packages/front-end/enterprise and packages/shared/src/enterprise), which fall under the GrowthBook Enterprise License, so confirm which features your build includes before relying on them. Ask whether your warehouse permissions can be scoped to read-only access for the GrowthBook service account.
What buyers ask before moving from LaunchDarkly to PostHog
What drives the cost of moving from LaunchDarkly to self-hosted PostHog?
The main cost is the people who run it, not the software: PostHog's self-hosted code is MIT licensed outside the ee/ directory, so the license itself is not the line item. The cost components are your infrastructure (compute, storage, backups, networking), the engineering time to deploy, instrument and maintain it, and any paid PostHog license needed for premium features in the ee/ directory. Costs rise with event volume, the number of teams using flags and experiments, and the number of SDK integrations to rewrite. Ask any implementation partner for a fixed-scope quote that lists each of these components separately, with what is one-time (deployment, instrumentation, cutover) and what recurs (hosting, upgrades, on-call support).
How long does a LaunchDarkly to PostHog migration take?
The duration depends on what you migrate and how many applications read flags today. Flag definitions are usually the smaller piece; the longer work is replacing LaunchDarkly SDK calls in each service, rebuilding targeting and experiment setups, and validating that users keep the same flag values during a parallel run. Timelines also depend on whether you bring historical analytics along. Agree a timeline in writing as part of a fixed-scope plan, and confirm the specific steps with PostHog's current documentation for your version before you commit to dates.
What does our team need to provide for the migration?
Expect to provide the following before work starts:
- Access to the LaunchDarkly projects, environments, flags and experiments you want to review, with an owner who can confirm which ones are still live
- A host in your own cloud account or data center that meets PostHog's self-host sizing guidance, plus network and DNS access
- Application owners who can change SDK calls and deploy each service during a parallel run
- A named engineer for cutover decisions, backups and upgrades after go-live
Your security team should also decide where the instance sits and who holds administrative credentials.
Can we run self-hosted PostHog ourselves without vendor support?
Yes, you can run it without vendor support, but you must plan for that. 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. Your team would own upgrades, backups, monitoring and incident response. Confirm whether your engineers can cover that on-call load, and decide whether you want an outside team on a retainer for ongoing support and upgrades.
Should we bring our historical analytics into self-hosted PostHog?
Usually only when a specific report or audit needs it, because the import path is limited. PostHog's managed migrations pull historical events from Mixpanel or Amplitude with API credentials, or from JSONL files in an S3 bucket. Each direct import job covers at most one year of data, and events are not deduplicated. Historical imports are free of ingestion fees when sent with the historical_migration flag, but a paid product analytics plan is required to unlock the import features. Once imported, there is no way to selectively delete event data, so test on a small slice first and keep a copy of the source data.
Do we need an implementation partner for this migration?
A partner is optional, but it helps when the internal team lacks time or experience with running PostHog in production. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so ask for a quote built from the written scope, and compare it with the internal hours your team would spend.
What should we check before deciding whether PostHog fits our needs?
Start with whether you need product analytics alongside flags, because PostHog's README groups feature flags and experiments with analytics, session replay and data pipelines. Check your expected event volume against the README's guidance that open-source deployments should scale to approximately 100k events per month, and check whether you need SSO, audit logs or custom roles, which PostHog sells as platform packages. If flags are the main need, compare Unleash or GrowthBook on the same checklist before deciding.
How DeployOpen works on this
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, including the feature flag and analytics stack your team chooses. We start from the decision in front of you, whether that is flags with analytics in one PostHog deployment or a split between a flag server and a separate analytics tool, and we write down what each option covers before any build begins.
How we scope
- We agree a written scope that states which LaunchDarkly flags, environments and SDK integrations are in and out.
- Scope covers whether PostHog alone fits your product analytics needs or whether Unleash or GrowthBook should handle flags.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy the chosen platform in your cloud account, data center or air-gapped network, sized to your confirmed event volume.
- We map LaunchDarkly targeting rules and flag definitions to the target platform and test each flag before cutover.
- We review PostHog's free self-hosted limits against your planned usage, and flag any paid package features you still need.
How we hand over
- We document the architecture, configuration, backup procedures and the SDK changes each application needs.
- We deliver runbooks covering upgrades, licensing terms for the chosen project and how to confirm the license applies to your use.
- We prepare the controls and evidence your compliance assessors will ask for, without issuing any audit report or certification.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Because PostHog does not support self-hosted instances, our retainer covers the operations your team would otherwise rely on the vendor for.
- We can run security testing of the flag and analytics endpoints as part of the retainer or as a separate written scope.
