PostHog

Last reviewed Aug 26, 2026 · 893 words

PostHog's own documentation tells you not to self-host it past roughly 100,000 events a month, and I would trust them on that. The "hobby" Docker Compose deploy is the only path the company supports; the Helm chart for Kubernetes was retired in 2023, so the catalogue's Kubernetes option means writing your own manifests for a stack PostHog no longer packages that way. What docker compose gives you is the core of PostHog Cloud with the scale removed: product analytics with funnels, retention and paths, session replay, feature flags, experiments, and surveys, on Postgres for metadata and ClickHouse for events. MIT-licensed with an ee/ directory under a separate licence, Python, 39,176 GitHub stars, and rated Hard in the catalogue for a reason that becomes clear the first time ClickHouse fills a disk.

Ten containers, and ClickHouse is the one that matters

The hobby install is one script:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/PostHog/posthog/HEAD/bin/deploy-hobby)"

It asks for a domain, writes a compose file, and starts, at last count, the web app, a worker, the plugin server, Temporal for async jobs, Postgres, ClickHouse, Kafka, Zookeeper, Redis, MinIO for replay storage, and Caddy for TLS on 80 and 443. The 4 GB RAM floor is honest for an idle install and optimistic under load; my rule is 8 GB and 4 cores for anything with session replay on, plus a disk you can grow, because ClickHouse holds every event and MinIO holds every recording. Set a retention policy in the first week. Recordings especially: 5,000 sessions of a busy app is tens of gigabytes.

Upgrades are bin/upgrade-hobby from the same directory, which pulls new images and runs migrations. Read the release notes before running it; ClickHouse schema migrations are the step that can take a long time on a big table, and the script will not warn you.

Session replay is the reason to bother

If you only want pageviews and referrers, this is the wrong tool by an order of magnitude of complexity. Plausible or Umami do that in one container on a fraction of the RAM, and Plausible vs Umami picks between them. PostHog's argument is everything after the pageview: watch the replay of the session where the user rage-clicked the checkout button, filter to sessions that hit a specific error, ship the fix behind a feature flag to 10% of users, and measure the experiment, all from one event stream and one SDK. Self-hosted, that entire suite comes with no seat count, which is the part Mixpanel and Amplitude charge for. Moving off Mixpanel is a PostHog decision far more often than a Plausible one.

What the self-host edition leaves out

The catalogue says "scaled down" and that is precise. You do not get PostHog's support, SAML or the advanced permissions from the paid tiers, the data warehouse, several pipeline destinations, or the capacity of their ClickHouse cluster. Community help is a GitHub discussions board. There is no automatic backup: you own pg_dump for Postgres and either ClickHouse's BACKUP command or volume snapshots for events, and the two need to be taken close together to restore cleanly. Test that before you need it, which for analytics means before the quarter's review, not after.

The cloud free tier changes the math

At last check, PostHog Cloud gives 1 million events and 5,000 session recordings a month free, with EU hosting available, then charges per event beyond that. For a side project under those numbers, self-hosting saves nothing and costs a server plus your evenings. The self-host case is narrower than it looks: data residency rules that forbid a third party entirely, an internal tool whose events must never leave the VPN, or a principled refusal to send user behaviour anywhere. The self-hosted vs SaaS TCO arithmetic applies here with unusual force because the operating burden is unusually high.

Reverse proxy and the two URLs that must agree

The bundled Caddy handles certificates if ports 80 and 443 are open to it. If you already run Traefik or Caddy in front of everything, disable the bundled one and forward to the web container on 8000, with websockets on for replay ingestion. SITE_URL in .env must match the public URL exactly, and the JavaScript snippet you paste into your app must use the same host, or events are accepted while the toolbar, replay links, and email links all break.

What I'd do

Under 1 million events a month with no residency rule: PostHog Cloud, EU region if that matters, and spend the evening on your product. Above the hobby ceiling: also Cloud, because the alternative is operating ClickHouse and Kafka yourself. Self-host only when the data genuinely cannot leave the building and volume sits under the line: the hobby script on an 8 GB VM with a separate data disk, retention set to 90 days for events and 30 for recordings, Postgres and ClickHouse backups on a nightly timer with a monthly restore drill. Run it that way and it is the best product-analytics suite you can own outright, as long as you stay under the line its own authors drew.