Should you self-host PostHog or use PostHog Cloud?
For most teams, PostHog Cloud is the default, and self-hosting is the exception you have to justify. Choose Cloud when you want no infrastructure to run, need the paid features, or can work within one of the two hosting regions, US (Virginia) or EU (Frankfurt). The free tier includes the first 1 million analytics events each month, and SSO, audit logs, custom roles and project permissions are sold as platform packages, so budget for those if your security team needs them. Self-hosting is realistic when a legal or contractual requirement keeps event data in infrastructure you control, when your volume sits near the roughly 100k events per month that PostHog's README gives as the scale for open-source deployments, and when you already have engineers who will patch, back up and upgrade the stack.
Be clear about what the free self-hosted path does not include. The Docker Compose hobby deployment is MIT licensed and installed with a deploy-hobby script, but PostHog states that self-hosted deployments are officially unsupported and that it does not provide customer support for product or infrastructure questions on them. Premium features in the ee/ directory also require a PostHog license on a self-hosted instance, so confirm with PostHog which capabilities you need before you commit. If you need fully free software, the posthog-foss repository is the route PostHog points to, but check that it covers the features your teams depend on. Sizing guidance starts at a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage, and that is a minimum, not a capacity plan for growth.
Before deciding, run a written check. Measure your current monthly event volume, list the data categories and residency terms your legal team requires, and ask who will be paged at 2 a.m. when ingestion stalls. If a regulator or contract needs EU-only processing, compare that need against the EU (Frankfurt) Cloud region before assuming you must self-host. If you do self-host, ask for a quote from an implementation partner that covers installation, backups, upgrades and monitoring as a fixed scope, and confirm in writing who fixes a failed upgrade. The PostHog self-host documentation is the next read for the deployment requirements.
How PostHog self-hosted and PostHog Cloud compare on the factors that decide it
This table compares PostHog self-hosted and PostHog Cloud on license, support, hosting, volume guidance, retention, identity features and Kubernetes status. Read each row against your own event volumes, compliance obligations and staffing, because the right choice often turns on support expectations and data location rather than on license alone.
| Factor | PostHog self-hosted | PostHog Cloud |
|---|---|---|
| License | Core repository is MIT Expat, but premium features in the ee/ directory need a PostHog license. Teams needing fully free software can use the posthog-foss repository. | Vendor-run service. Confirm with PostHog which features and terms apply to your plan under its own agreements. |
| Vendor support | Officially unsupported. PostHog does not offer customer support for product, infrastructure or other questions on self-hosted instances. | Vendor-run hosting and support, with support scope set by your plan. Confirm response expectations on the pricing page or with sales. |
| Hosting region | Chosen by you, in your own cloud account, data center or network. Region is your decision and your responsibility. | Two regions: US (Virginia) and EU (Frankfurt). Confirm whether these meet your residency and transfer requirements. |
| Event volume guidance | Open-source deployments should scale to approximately 100k events per month. PostHog recommends moving to Cloud above that level. | First 1 million analytics events free every month on the Free plan. Usage pricing applies beyond the free tier. Confirm current rates on the pricing page. |
| Projects and retention | Set by you through your own storage and configuration. Confirm retention policy and project structure against your data rules. | Free plan: 1 project and 1-year data retention. Pay-as-you-go: 6 projects and 7-year data retention. |
| SSO, audit logs and custom roles | Platform features are not sold as a separate package for self-hosting in the same way. Confirm which identity and audit features the ee/ license covers for your deployment. | Sold as platform packages on Cloud. Confirm which package includes SSO, audit logs, custom roles and project permissions before you commit. |
| Kubernetes for the paid self-hosted product | New Kubernetes deployments of the paid self-hosted product are no longer supported. Confirm current deployment options with PostHog before planning. | Not applicable. PostHog operates the hosted service. |
Where event data lives and what compliance work moves to you
The two models split responsibility differently for where event data sits, who can reach it and what an assessor will ask for. Cloud moves most hosting and platform controls to PostHog, while self-hosting keeps them in your hands, along with the evidence that proves them.
Data location in each model
PostHog Cloud offers two hosting regions, US (Virginia) and EU (Frankfurt), so the region is a choice you make when you set up the project. A self-hosted instance stores events wherever you deploy it, which means your cloud account, data center or network decides residency. Confirm the chosen Cloud region against your data transfer and residency obligations before ingestion starts, because moving data later is not a simple setting change.
Access control and who holds the keys
On PostHog Cloud, PostHog operates the infrastructure, so your control rests on project permissions and the contract you hold with the vendor. Self-hosting puts the database, backups, encryption keys and administrator accounts under your control, which gives you more options but also makes you the party who must restrict and log access. Ask who can reach the database and object storage directly, not only who can log in to the application.
Premium features behind the ee license
Code in the ee directory is covered by a separate license, and the README states that using its premium features on a self-hosted instance requires a PostHog license. SSO, audit logs, custom roles and project permissions are sold as platform packages, so a self-hosted team that needs them must budget for a license. Check which controls your assessor expects, such as audit logging or role separation, and confirm whether they are in the free code or the ee directory before you design around them.
Retention settings and data deletion
Retention is a configuration decision that affects both models. The Free plan on PostHog Cloud includes 1-year data retention, while the Pay-as-you-go plan raises this to 7 years, so the plan you pick sets an upper bound on how long your data is kept. In a self-hosted instance, you define retention and deletion yourself and must show how they run. Document the retention period your policy requires and confirm how each model enforces it.
Evidence an assessment will request
An assessment needs documented controls and artifacts such as configuration records, access reviews, backup test results, change records and logs. On PostHog Cloud, much of the infrastructure evidence comes from PostHog's own compliance documentation, which you should request directly. Self-hosted deployments are officially unsupported and PostHog provides no support for infrastructure questions, so you produce this evidence yourself. DeployOpen prepares systems, controls and evidence for compliance assessments, but does not issue audit reports or certifications. Independent auditors and certification bodies do that work.
Vendor compliance documentation to confirm
Before you rely on either model for a regulated workload, obtain PostHog's current compliance documentation, data processing terms and sub-processor list directly from the vendor. Ask which attestations or reports cover the Cloud region you chose and whether any cover a self-hosted deployment at all. Treat the answers as the baseline for your scope, since vendor documentation can change and this page does not reflect it.
Which features you can use in each model
The free Docker Compose (hobby) deployment is installed with a deploy-hobby script and falls under the MIT license that covers the PostHog repository outside its ee directory. Teams get the MIT core, which includes the product areas named in the README: product analytics, web analytics, session replay, error tracking, logs, feature flags, experiments, surveys and data pipelines. Nothing in that core is locked behind a paid tier, but the deployment is officially unsupported and PostHog does not offer customer support for product, infrastructure or other questions on self-hosted instances.
- Core product areas: the MIT code covers analytics, replay, flags and surveys, outside the ee directory.
- No ee features: premium features from the ee directory are not part of the hobby install.
- Scale guidance: the README says open-source deployments should scale to about 100k events per month and recommends PostHog Cloud above that.
- No vendor support: PostHog does not support self-hosted infrastructure questions, so fixes depend on your team or an outside implementer.
- Hardware baseline: the docs recommend a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage.
Before you rely on a feature, confirm in the current self-host docs and the LICENSE files that it sits outside the ee directory.
Teams that need premium features on their own infrastructure must run code from the ee directory, which is covered by a separate license in ee/LICENSE. The PostHog README states that using premium features from ee on a self-hosted instance requires a PostHog license. This is the only path to those features on self-hosted infrastructure, so the license, not the Docker Compose install, determines what you can switch on. Ask PostHog exactly which features your license covers before you design around them.
- Separate license: ee code is not MIT, so read ee/LICENSE before you modify or redistribute it.
- Feature gating: premium features from ee require a PostHog license on self-hosted instances.
- Support scope: confirm in writing whether a paid self-hosted license includes support, since the docs say the free deployment does not.
- Kubernetes limit: the self-host docs state new Kubernetes deployments of the paid self-hosted product are no longer supported.
- Fully free alternative: teams that cannot accept any proprietary code can use the posthog-foss repository, which is purged of all proprietary code and features.
Confirm current feature availability in each edition with PostHog before you commit, because the split between ee and MIT code can change between releases.
PostHog Cloud gives access to the full product on hosted infrastructure in two regions, US (Virginia) and EU (Frankfurt). The pricing page says the first 1 million analytics events are free every month and that the Free plan includes 1 project and 1-year data retention. Pay-as-you-go raises this to 6 projects and 7-year data retention. SSO, audit logs, custom roles and project permissions are sold as platform packages, so identity and access controls are a purchase decision, not a default.
- Regions: choose US (Virginia) or EU (Frankfurt) hosting at the account level.
- Free plan limits: 1 project and 1-year data retention on the Free plan.
- Pay-as-you-go limits: 6 projects and 7-year data retention.
- Access controls: SSO, audit logs, custom roles and project permissions come as platform packages.
- Migrations: historical imports from Mixpanel or Amplitude need a paid product analytics plan, and imported events cannot be selectively deleted.
Confirm the current package contents, regional data residency terms and any contractual commitments with PostHog before you rely on them for regulated workloads.
What running PostHog yourself costs in people and infrastructure
The biggest cost of self-hosting PostHog is usually staff time, not the server. PostHog's self-host documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage for the free Docker Compose (hobby) deployment, which you pay for as ordinary cloud or data center capacity in your own account. That line item recurs every month and grows if you add storage for retained events, because you hold the data yourself. The people cost is what the documentation leaves out. Your team owns installation through the deploy-hobby script, upgrades, backups, monitoring, and recovery after failures. 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, so every incident lands on your engineers. Estimate that effort by listing who would be on call for the analytics stack and how many hours a quarter they can give it.
Cloud pricing is a different kind of cost. PostHog's pricing page publishes usage pricing in US (Virginia) and EU (Frankfurt) regions, and the first 1 million analytics events each month are free on the Free plan, which includes 1 project and 1-year data retention. Your bill then scales with event volume and the plan you choose, and the Pay-as-you-go plan raises the project count to 6 and retention to 7 years. The cost drivers are event volume, retention length, number of projects and any platform package you buy. Ask PostHog for a written quote that shows the expected monthly events for each product you plan to use, the retention period, the region, and whether session replay or feature flags are included in the volume you are pricing.
The license line applies only if you need features from the proprietary ee/ directory. The PostHog README says premium features there on a self-hosted instance require a PostHog license, and SSO, audit logs, custom roles and project permissions are sold as platform packages on the Cloud pricing page. Before you commit to either path, ask PostHog to confirm in writing which of these features you need, what a self-hosted license costs for them, and whether it is priced separately from infrastructure. If you only need the MIT-licensed core, the posthog-foss repository is the free route the README names, and you should confirm with your own counsel that it covers your requirements.
What your team runs in each hosting model
This table shows which operating duties sit with your team in each hosting model and which ones you must confirm with PostHog. Read each row as a question to answer before choosing. The main takeaway is that the free self-hosted path leaves nearly every operating duty with your team, while PostHog Cloud moves infrastructure work to PostHog but adds usage pricing and a choice of hosting region.
| Area | Self-hosted (hobby deployment) | PostHog Cloud |
|---|---|---|
| Infrastructure ownership | Your team provisions the server, network and Docker Compose stack. Recommended size: 4 vCPU, 16 GB RAM, over 30 GB storage. | PostHog runs the platform. Choose US (Virginia) or EU (Frankfurt) hosting and confirm data location terms. |
| Upgrades | Your team plans and applies upgrades. Confirm the supported upgrade path with PostHog, since self-hosted installs are officially unsupported. | PostHog maintains the hosted service. Confirm how changes are announced and whether any change needs action from you. |
| Backups and storage | Your team owns backups, retention and disk growth. Event data imported through migrations cannot be selectively deleted once loaded. | Retention depends on plan: 1 year on Free, 7 years on Pay-as-you-go. Confirm backup and restore commitments in writing. |
| Scaling and event volume | PostHog's README puts the open-source ceiling at about 100k events per month and recommends Cloud above that. | First 1 million analytics events are free each month, then usage pricing applies. Confirm current rates on the pricing page. |
| Premium features and identity | Premium features in the ee directory need a PostHog license. Confirm which SSO and audit features you can run. | SSO, audit logs, custom roles and project permissions are sold as platform packages. Confirm what your plan includes. |
| Security patching | Your team applies operating system, container and PostHog image patches. Confirm patch notices with PostHog before relying on them. | PostHog applies platform patches. Ask for its vulnerability management and disclosure process before you sign. |
| Incident response and vendor support | Your team runs incident response. PostHog offers no customer support for infrastructure or product questions on self-hosted instances. | Support scope depends on your plan. Confirm response times and escalation paths in writing before go-live. |
| Compliance evidence | Your team produces control evidence for its hosts, configuration and access. DeployOpen can prepare it but does not issue audit reports. | Request PostHog's security and assurance documents and confirm which third-party reports it can share with you. |
How to move between self-hosted PostHog and PostHog Cloud
This sequence shows how a team decides whether to move its event data between the two hosting models, what each move depends on, and how to confirm the result before cutting over. It ends with a documented, reversible-in-planning path rather than an untested switch.
Assess event volume and retention needs
The engineering lead or analytics owner counts monthly events across all sites and apps, then compares that figure with the roughly 100k events per month that PostHog's README gives for open-source deployments. Record the retention period you need, since the Free plan on PostHog Cloud lists 1-year retention and Pay-as-you-go lists 7-year retention. Done when you have a written volume and retention figure that someone outside the team has reviewed, and you know whether the current hobby deployment is still within its stated range.
Decide on the target cloud region
The privacy or compliance lead chooses between the two PostHog Cloud hosting regions, US (Virginia) and EU (Frankfurt), based on where your users' data must reside and which data processing terms your contracts require. Confirm the region choice in writing with PostHog before any data moves, because the region shapes where historical and live events will be stored. Done when the decision record names the region, the reason for it, and the approver.
Confirm plan features and licence needs
The platform owner checks which features the team relies on, such as SSO, audit logs, custom roles or project permissions. The PostHog pricing page says these are sold as platform packages, and the README says premium features in the ee directory on a self-hosted instance need a PostHog license. Ask PostHog to confirm in writing which plan and packages cover each feature so that no capability is lost during the move. Done when every required feature is mapped to a plan or package with a written confirmation.
Plan the event pipeline and feature flag cutover
The platform engineer maps every SDK and snippet that sends events to the current self-hosted host, then prepares the new project keys and host settings for PostHog Cloud. Feature flags need a separate plan, because flag definitions and evaluation depend on the instance that serves them, so the team should decide how each flag is recreated and checked before traffic moves. Run both destinations in parallel for a short check if PostHog confirms it is supported for your setup. Done when a cutover runbook lists each SDK change, each flag, the rollback step, and the person who signs off the switch.
Scope historical data imports carefully
Historical data is the step where mistakes are hardest to undo. PostHog's managed migrations import events from Mixpanel or Amplitude using API credentials, or from JSONL files in an S3 bucket, and each direct import job covers at most one year of data. Events are not deduplicated, so overlapping date ranges or re-runs can double count. A paid product analytics plan is required to unlock these import features, and there is no way to selectively delete event data once imported. Done when the import plan lists each source, date range and job, and the team has agreed that nothing will be imported without a test run first.
Test the import and validate the counts
The analytics owner runs a small import against a single one-year window in a non-production project, then compares event counts, funnels and key dashboards with the source tool for the same period. Because events are not deduplicated, the test must also confirm that rerunning a job does not change totals. Done when the test report shows matching counts within the tolerance the owner has set, and the team has accepted the date ranges for the full import.
Cut over and confirm the live pipeline
The platform engineer switches SDK configuration and feature flag evaluation to the new host during the agreed window, then watches ingestion, error rates and flag results on both sides. The team keeps the old instance running until the new data is verified, since the Docker Compose hobby deployment is officially unsupported and PostHog does not offer support for self-hosted infrastructure questions. Done when the new host receives live events from every site, the flag results match the expected values, and the sign-off record is filed.
Confirm the move with PostHog and retire the old host
Before decommissioning, the platform owner asks PostHog to confirm in writing any remaining steps, data handling terms and the status of the old data. Only after that confirmation should the team shut down the self-hosted instance, remove stored credentials and update the data inventory. Done when the written confirmation is on file, the old instance is archived according to your retention policy, and the data map and privacy notices reflect the new hosting location.
What buyers ask before choosing PostHog Cloud or self-hosting
Is self-hosting PostHog free, and what does it cost to run?
The software is free under the MIT license for the code outside the ee directory, but running it is not free. You pay for the server, storage, backups, monitoring, and the engineering time to install, patch and upgrade it. PostHog's self-host documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage for the free Docker Compose hobby deployment. Those are one-time setup costs plus recurring infrastructure and staff time. Ask any implementation partner for a written scope that lists what is installed, who runs upgrades, and what backup and monitoring they cover, because those choices drive most of the recurring cost.
Is the PostHog hobby deployment supported?
No. 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. Support for the hobby setup therefore has to come from your own team or from a partner you contract separately. Confirm in writing who answers incident calls, who applies security fixes, and how long a fix can take to reach your environment before you depend on the deployment for production analytics.
How many events can a self-hosted PostHog handle before moving to Cloud?
PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends migrating to PostHog Cloud above that level. Your actual ceiling depends on the server you choose, the event payload size, the number of dashboards and queries your team runs, and how much you need to retain. Treat 100k events per month as a planning threshold, not a guarantee, and load test with your own event profile before committing. If your volume is already above that level, the vendor's own guidance points toward Cloud.
How long does a self-hosted PostHog setup take, and what does the team need?
No fixed duration is published for a PostHog setup, so ask for an estimate tied to your scope. The effort depends on the deployment path you pick, your hosting environment, how you configure SSL, storage and backups, how many SDKs you connect, and whether you migrate historical data. The team needs Linux server administration, Docker or container skills, database operations, and someone who can read PostHog's logs and upgrade notes. If you plan to use Kubernetes, note that PostHog's self-host docs say new Kubernetes deployments of its paid self-hosted product are no longer supported, which changes the staffing and architecture discussion.
Can a small team run self-hosted PostHog on its own?
A small team can run the hobby deployment alone if it already operates Linux servers and Docker, accepts that no vendor support is available, and has a clear owner for upgrades and backups. The harder part is ongoing operations: patching the host, watching disk growth, restoring backups, and reacting when a release changes behavior. If nobody on the team has that background, or if the analytics feed a regulated process, an outside partner can plan, install, document and support the system under a fixed-scope agreement, with ongoing support available as a retainer.
When do PostHog's ee features require a paid license?
The ee directory is covered by a separate license in ee/LICENSE, and the PostHog README says that using premium features from that directory on a self-hosted instance requires a PostHog license. Features in that directory are the ones to check against your requirements, such as SSO, audit logs, custom roles and project permissions, which PostHog's pricing page says are sold as platform packages. Teams that need fully free software can look at the posthog-foss repository, which the README describes as purged of all proprietary code and features. Confirm with PostHog which features you need before designing around them.
What does an outside implementation partner scope for PostHog?
A partner scopes the work in writing before starting, typically covering the target environment, the install method, integration with your data sources and identity system, backup and restore, monitoring, hardening, documentation, and handover. Most engagements are fixed-scope, so the scope, deliverables and timeline are agreed up front, and the price follows from that scope. DeployOpen does not publish a price list. Ask for a quote that names each deliverable, who operates the system after handover, and which upgrades and support hours are included or priced separately as a retainer.
Which Cloud region and plan should a team compare first?
PostHog Cloud offers two hosting regions, US (Virginia) and EU (Frankfurt), and a Free plan that includes the first 1 million analytics events each month, 1 project and 1-year data retention. The Pay-as-you-go plan raises the project count to 6 and data retention to 7 years, and pricing beyond the free tier is usage based. Compare the region against your data residency rules, the retention period against your policy, and the event volume against the free allowance. Confirm current usage pricing on the pricing page before you budget.
When self-hosting PostHog is realistic for your team
Self-hosting PostHog is realistic when a specific constraint outweighs the operating burden. The most common one is data location: a regulator, a customer contract or an internal policy requires that event data never leave your own cloud account, data center or network. If that requirement is firm, Cloud is not an option regardless of price, and the question becomes whether your team can run the stack well. Start by checking the requirement in writing, including whether it covers session replay recordings, feature flag evaluations and person properties, since all of them are data you would host. Confirm with your legal and compliance owners whether a Cloud region (US in Virginia or EU in Frankfurt) satisfies the requirement before you commit to operating your own instance.
Low event volume is the second condition, and it is the one most often misjudged. The free Docker Compose hobby deployment, installed with a deploy-hobby script, is aimed at small installs, and the PostHog README says open-source deployments should scale to about 100k events per month before migrating to Cloud. Self-hosting also needs an existing platform team. The hobby deployment recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage, and someone must own upgrades, backups, monitoring and capacity growth. Be aware that PostHog states self-hosted deployments are officially unsupported and that it offers no customer support for infrastructure questions, so the team carries every incident. Ask whether you have an engineer who can own that for years, not only for launch.
Cloud is the better choice when volume is growing, when you need features sold as platform packages such as SSO, audit logs and custom roles, or when you lack a platform team. The Free plan includes 1 project and 1-year data retention, and the first 1 million analytics events are free each month, so Cloud is also the cheaper place to evaluate the product before deciding. Self-hosting is not free in the sense that matters: you pay for servers, staff time and the risk of unsupported operation. If you do need premium features on your own instance, the PostHog README says a PostHog license is required for ee directory functionality. For fully free software, the posthog-foss repository is the option, but confirm its feature set and maintenance status directly with PostHog before you plan around it.
How DeployOpen scopes, deploys and supports self-hosted PostHog
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For PostHog, we start by testing whether self-hosting fits your event volume, premium feature needs and support expectations before any build work begins.
How we scope
- Confirm expected monthly event volume, retention needs and whether premium features under the ee license are required.
- Agree in writing which hosting region, cloud account or data center will hold PostHog and its data.
- Document the fixed-scope deliverables, timeline and any ongoing retainer before work starts, with a quote following from that scope.
How we build
- Deploy the chosen PostHog configuration inside your environment, using the documented self-host path and sizing guidance for your load.
- Harden the instance, configure identity integration, backups and access controls, and test them against the agreed requirements.
- Run application and infrastructure security testing on the deployed instance and record the findings and fixes.
How we hand over
- Deliver runbooks covering installation, upgrades, backup restore and the decision record for self-hosting versus PostHog Cloud.
- Document data flows, retention settings and evidence needed for compliance assessments, without issuing any audit report or certification.
- Walk your platform, security and compliance teams through the handover so they can operate the instance without us.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the initial build.
- Confirm in the written scope which upgrade, patching and incident responsibilities sit with DeployOpen and which stay with your team.
- Review the self-hosted setup periodically against PostHog's current documentation, since its self-hosted deployments are officially unsupported by PostHog.
