The trade self-hosting actually makes
PostHog Cloud bills by usage; self-hosting removes that meter and replaces it with infrastructure spend plus engineering time. The infrastructure spend is usually the easier half to estimate. The engineering-time half - who provisions it, who upgrades it, who gets paged when ingestion falls behind - is where self-hosting decisions go wrong when they are made on cost alone.
What operating self-hosted PostHog actually involves
| Responsibility | What it means in practice |
|---|---|
| Infrastructure sizing | Provisioning compute and storage against real (not estimated) event volume, with headroom for growth |
| Upgrade cadence | Self-hosted deployments do not update themselves - someone owns tracking releases and applying them |
| Backup & restore | Backups that have actually been tested with a restore drill, not just scheduled and forgotten |
| Incident response | Ingestion or query-layer incidents need an owner and a runbook, the same as any production data system |
When self-hosting is the right call
- Event volume is high enough that usage-based Cloud billing is a meaningful line item
- Data residency or compliance requirements make a vendor-hosted instance a harder sell
- The team already operates comparable infrastructure (databases, queues, ingestion pipelines) and has the on-call rotation to absorb one more system
When it usually is not
If nobody on the team currently owns production infrastructure operations, self-hosting PostHog does not remove that gap - it adds a system into it. That is a scoping conversation worth having before deployment, not after the first missed upgrade.
This deployment-and-ops angle is also where we intersect with PostHog pricing directly: self-hosting is a pricing lever as much as a technical decision, and should be evaluated as one.