PostHog Self-Hosted
IntermediateWeb AppSelf-hosted PostHog: product analytics, session replay, and feature flags with every event on your own server.
Published 27 September 2026
About PostHog Self-Hosted
PostHog is an open-source product platform: event analytics, funnels, retention, session replay, feature flags, experiments, and surveys in one tool. The self-hosted deployment (PostHog calls it the hobby deploy) runs the MIT-licensed core on a single Linux server and keeps every event, recording, and person profile on it.
The deployment is a small platform, not an app. The official Compose file starts around 40 containers: PostHog's web, worker, and ingestion services, PostgreSQL for people and configuration, ClickHouse for events, Kafka and Redis for the ingestion pipeline, object storage for recordings, and a workflow engine. That's why the floor is 4 vCPUs and 16 GB of memory on a dedicated server. The install script also sets up Caddy, which requests a Let's Encrypt certificate for your domain, so the instance serves HTTPS without a separate proxy.
It comes with firm limits. PostHog recommends self-hosting only below about 300,000 events, 1,000 recordings, and 300,000 feature-flag calls a month, offers no support for self-hosted instances, and keeps every paid-plan feature on Cloud. Above that volume its advice is to scale the server up or move to Cloud, with a migration tool for the data.
The stack fits one case well: data that can't leave your infrastructure, at a volume a single server handles. Teams choosing on price alone usually do better on Cloud, whose free tier covers 1 million events a month.
Key Features
- ✓Event analytics, funnels, retention, and paths on your own server
- ✓Session replay, with recordings kept in the deployment's own object storage
- ✓Feature flags, experiments, and surveys from the same instance
- ✓ClickHouse event storage with Kafka and Redis in the ingestion pipeline
- ✓HTTPS through Caddy by default, or Traefik, NGINX, or a self-hosted PaaS
- ✓All events, recordings, and person profiles stay on infrastructure you control
When to Use PostHog Self-Hosted
- →Products whose privacy policy prohibits sending behavioral data to a third party
- →Regulated or internal tools that must keep analytics inside their own network
- →Teams evaluating PostHog's full product before committing to Cloud
- →Side projects and internal apps under about 300,000 events a month
- →Engineers who want to study or extend PostHog's open-source codebase
Pros
- Every event, recording, and person profile stays on your server
- Analytics, replay, flags, experiments, and surveys in one self-hosted tool
- No per-event billing within the volume one server handles
- MIT-licensed core that you can audit and modify
Cons
- The official deployment needs 4 vCPUs and 16 GB of memory on a dedicated server
- PostHog recommends it only below about 300,000 events a month and offers no support for it
- Paid-plan features are Cloud-only
- Around 40 containers, including ClickHouse and Kafka, to upgrade, back up, and debug yourself
Hosting Options for PostHog Self-Hosted
PostHog's own docs describe the target as a Hetzner-class VM with 4 vCPUs and 16 GB, and a 16 GB instance there costs around €20/mo. That makes a flat-rate root VPS the cheapest way to meet the official floor, with backups and upgrades of the whole bundle left to you.
A root Droplet with snapshots and a cloud firewall in the panel. Meeting PostHog's 16 GB floor means a larger Droplet, about $96/mo, several times the VPS price elsewhere in this list; it fits teams already running on DigitalOcean who want PostHog in the same account and region.
The budget path to the 16 GB floor: Hostinger's KVM plan with 4 vCPUs and 16 GB costs a fraction of the big clouds, often under $20/mo on a long term. Fewer regions than the larger providers, and with around 40 containers on the box, snapshots before each upgrade matter.
An EC2 instance with 4 vCPUs and 16 GB runs well over $100/mo on demand, plus EBS volumes for ClickHouse and PostgreSQL. It fits when the data must stay inside an existing AWS account or VPC. An Application Load Balancer with AWS Certificate Manager can take over TLS from the bundled Caddy.
A Compute Engine instance with 4 vCPUs and 16 GB costs around $100/mo, plus persistent disks for ClickHouse and PostgreSQL. It fits when the data must stay inside an existing Google Cloud project. Cloud Load Balancing with Google-managed certificates can take over TLS from the bundled Caddy.
These are highlighted picks. To see all the tools, check the Hosting & Cloud category.
Reverse Proxy Options for PostHog Self-Hosted
What PostHog's install script already sets up: a Caddy container that requests a Let's Encrypt certificate for your domain and routes capture, replay, flags, and the web app. Choosing it means keeping the official configuration, the least work to maintain across upgrades.
Replaces the Caddy container PostHog's install script sets up, for servers that already route everything through Traefik. Route the whole domain to PostHog's proxy service rather than to individual containers, since capture, replay, flags, and the web app are separate services behind one hostname.
Self-Hosted PaaS Options for PostHog Self-Hosted
Free and self-hosted, and able to run a Docker Compose deployment behind its bundled proxy. PostHog's Compose file is large and changes between releases, so running it through Coolify means re-syncing that file on each upgrade instead of using PostHog's upgrade script.
Free and self-hosted, with Compose deployments behind its bundled Traefik. The same caveat as Coolify applies: PostHog's roughly 40-container file changes between releases, and its upgrade script assumes the official layout, so expect to maintain the Compose file yourself.
PostHog Self-Hosted Add-ons
Each addition below extends this stack with a capability the base stack works fine without. None are required: include the ones your product actually needs when building this stack, and skip the rest.
Tunnel Add-ons
Add a tunnel when you're self-hosting without a static IP or can't open inbound ports — a home server, a VPS behind restrictive network policies, or anywhere a reverse proxy alone can't reach the internet.
Makes PostHog reachable over HTTPS through an outbound-only connection, with no inbound ports or static IP, for an instance inside a private network. The tunnel terminates TLS, so disable the bundled Caddy's certificate request and point the tunnel at PostHog's proxy service.
Frequently Asked Questions about PostHog Self-Hosted
Why self-host PostHog instead of using PostHog Cloud?
Data control, and little else. PostHog Cloud's free tier covers 1 million events, 5,000 recordings, and 1 million feature-flag requests a month, which is more than PostHog recommends for a self-hosted instance (about 300,000 events, 1,000 recordings, and 300,000 flag calls a month). Self-hosted instances also get no support, and every paid-plan feature stays on Cloud. What self-hosting buys is that no event, recording, or person profile ever leaves your server. If that's a hard requirement, this stack meets it; if the goal is saving money, Cloud usually wins.
What does the server need to run?
PostHog's official target is a Linux VM with 4 vCPUs, 16 GB of memory, and more than 30 GB of storage, and its installer treats 8 GB as a hard floor. The weight comes from the bundle: PostgreSQL, Redis, ClickHouse, Kafka, object storage, and a workflow engine run beside PostHog's own services, around 40 containers in all. Give PostHog the server to itself, and add disk as recordings and events accumulate.
What needs backing up, and how do upgrades work?
Three stores. ClickHouse holds events, PostgreSQL holds people, dashboards, flags, and settings, and the object storage volume holds session recordings. Back up all three before any change, since PostHog makes no guarantees about data on self-hosted instances. Upgrades run through PostHog's upgrade-hobby script, which pulls new images and applies migrations. Snapshot the whole server first where your host allows it: with this many services, rolling back a snapshot is simpler than restoring each database separately.
What happens when I outgrow the self-hosted instance?
PostHog gives two paths: scale the server up, or move to Cloud. Scaling up works for a while, but the deployment stays a single server, and PostHog no longer supports multi-node self-hosting. Moving to Cloud uses PostHog's migration tools: one copies metadata (dashboards, insights, cohorts, feature flags, experiments), and another reads events straight from your ClickHouse and imports them into a Cloud project. Historic imports are free, but the Cloud project needs a paid product analytics plan to accept them.
Which reverse proxy should front PostHog?
Caddy by default: PostHog's install script sets it up, requests a Let's Encrypt certificate for your domain, and routes capture, replay, flags, and the web app, which keeps you on the official configuration. Traefik or NGINX work just as well when the server already runs one for other sites, and Coolify or Dokploy put PostHog behind their bundled proxy. With any of them, route the whole domain to PostHog's internal proxy service rather than to individual containers, and allow large request bodies for session recordings.
Stacks Related to PostHog Self-Hosted
Sentry Self-Hosted
InfrastructureSelf-hosted Sentry error tracking on your own infrastructure, with PostgreSQL, Redis, ClickHouse, and Kafka under the hood.
Airflow Self-Hosted
InfrastructureSelf-hosted Apache Airflow: the standard data-pipeline scheduler on your infrastructure.
GitLab Self-Hosted
InfrastructureSelf-hosted GitLab with Docker: your code, your CI, your infrastructure.
Superset Self-Hosted
InfrastructureSelf-hosted Apache Superset: BI dashboards that never leave your server.
Scores
Popularity4/5
PostHog is a fixture of product-engineering discussion with broad developer marketing behind it; most developers have encountered the name even without running it.
Learning Curve4/5
The product is approachable; the self-hosted bundle is the work, since ClickHouse and Kafka operations are specialized skills this stack asks of you.
Flexibility5/5
Product analytics, session replay, feature flags, experimentation, and surveys in one self-hosted platform: the widest functional surface in this family.
Performance5/5
Built on ClickHouse with Kafka ingestion, an architecture designed for billions of events that rewards real hardware.
Portability5/5
The entire dataset lives in your own ClickHouse and PostgreSQL instances, queryable and exportable independently of the platform.
Tools in the PostHog Self-Hosted Stack
Databases
DevOps & CI/CD
Data Engineering & ETL
Observability & Monitoring
Add-ons (optional — add any, or none)
Tunnel
PostHog Self-Hosted Pricing
PostHog's self-hosted core is free under the MIT license, but it needs a 16 GB server with 4 vCPUs to itself: around $15-45/mo on a VPS, or about $100/mo on AWS or Google Cloud. PostHog Cloud's free tier covers 1 million events and 5,000 recordings a month, more than PostHog recommends for a self-hosted instance, so this stack costs more than Cloud at small volume. Its value is keeping the data on your own infrastructure.
16 GB of RAM and 4 vCPUs, PostHog's official target; the installer treats 8 GB as a hard floor. A dedicated server, not a shared small VPS.
MIT-licensed core without event metering; paid-plan features are Cloud-only.
The install script's Caddy handles HTTPS; Traefik, NGINX, Coolify, and Dokploy are free if you swap it.
PostHog Self-Hosted System Requirements
source- CPU
- 4 vCPU
- RAM
- 16 GB
- Disk
- 30 GB or more of storage
- OS
- Linux (an Ubuntu VM, per the official hobby deploy)
PostHog's docs describe the target as a Hetzner-class VM, and the installer treats 8 GB of memory as a hard floor: the bundle runs PostgreSQL, Redis, ClickHouse, Kafka, object storage, and a workflow engine together.