PostHog’s Pragmatic Pivot: The Reality of Self-Hosting FOSS Analytics

The open-core business model is notoriously difficult to balance. Give away too much, and you cannot fund development; restrict too much, and you alienate the developer community that built your momentum. PostHog has taken a highly pragmatic path to resolve this tension. By maintaining a clean, read-only Free and Open Source Software (FOSS) mirror called posthog-foss and focusing its self-hosted offering entirely on a single-node hobby tier, the company has drawn a sharp line in the sand.

This strategy makes one thing clear: if you want to run a massive, highly available, multi-node analytics platform, you should use PostHog Cloud. But if you want to run a local sandbox, manage analytics for a small-scale project, or audit the code, the MIT-licensed FOSS stack is incredibly capable.

For developers, this shift represents both a win and a warning. You get access to an impressive suite of tools under a permissive license, but the days of scaling a free, self-hosted enterprise deployment on your own Kubernetes cluster are officially over.

The Architecture of the FOSS Stack

Looking at the posthog-foss repository reveals that this is not a watered-down marketing tool. It contains the core engine of PostHog's platform, including product analytics, session replays, feature flags, experiments, error tracking, and data pipelines.

Under the hood, PostHog is a heavy, polyglot system. The repository is primarily written in Python (54.7%) and TypeScript (39.2%), but it also includes performance-critical components written in Go and Rust. The system relies on two primary databases: PostgreSQL for transactional state (users, organizations, feature flag configurations) and ClickHouse for high-performance, columnar event storage.

The FOSS repository includes directories like frontend, posthog, rust, and services, along with funnel-udf (User Defined Functions for ClickHouse to speed up funnel queries). This shows that PostHog is not holding back its core query-optimization logic. However, running this distributed architecture on a single machine requires careful resource allocation.

Hands-on with the Hobby Deploy

PostHog has deprecated support for self-hosted Kubernetes deployments and paid self-hosted licenses. Instead, they offer a single-node "hobby" deployment managed via Docker Compose.

To run this stack, you need a Linux Ubuntu virtual machine with at least:

• 4 vCPUs
• 16GB of RAM
• 30GB of storage

These requirements are non-negotiable. ClickHouse is notoriously memory-hungry, and running it alongside PostgreSQL, Redis, Kafka, and the Django backend on anything less than 16GB of RAM will quickly lead to out-of-memory errors.

PostHog has introduced an experimental Terminal User Interface (TUI) installer to simplify this setup. You can download and run the binary directly on your target machine:

curl -OfsSL https://github.com/PostHog/posthog/releases/download/hobby-latest/hobby-installer
chmod +x hobby-installer
./hobby-installer

For automated setups, you can pass CI flags and specify your domain:

./hobby-installer --ci --domain=posthog.yourdomain.com

This installer configures the Docker Compose stack and automatically provisions an SSL certificate via Let's Encrypt, assuming you have pointed an A record to your instance's IP address. If you prefer the classic installation script, you can run:

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

The Hard Math of Going Self-Hosted

Before choosing to self-host, you need to look closely at the operational trade-offs. PostHog's own documentation includes a remarkably candid flowchart designed to talk developers out of self-hosting unless they are absolute purists.

There are three major caveats to consider:

1. The Scaling Wall

The hobby deployment is strictly single-node. PostHog warns that if you ingest more than 300,000 events, 1,000 session recordings, or 300,000 feature flag API calls per month, you are pushing the limits of a single-node instance. If you exceed these thresholds, ClickHouse queries will slow down, and you risk losing data.

2. The Continuous Delivery Model

PostHog does not publish tagged releases for the self-hosted version. Instead, all commits go through their standard CI/CD pipeline, hit their cloud deployments, and immediately become available for self-hosted instances. When you run an upgrade via the hobby script, you are pulling the latest master branch:

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

This continuous delivery model keeps your instance up to date with the latest features, but it increases the risk of deployment instability. Since PostHog offers no customer support or guarantees for self-hosted instances, you assume all responsibility for database migrations and potential data loss.

3. Feature Disparity

All paid-plan features are cloud-only. If you need advanced team permissions, enterprise single sign-on, or multi-tenant configurations, the FOSS version will not suffice.

A Clear Division of Labor

PostHog's open-source strategy is a logical response to the realities of modern infrastructure. Managing a distributed ClickHouse cluster is a full-time job for a platform engineering team. By stripping away Kubernetes support and focusing on a single-node Docker Compose setup, PostHog has made self-hosting accessible for side projects and local testing, while removing the support burden of complex, custom enterprise deployments.

If you are running a small application or need a local, privacy-compliant analytics sandbox, the new FOSS repository and TUI installer are excellent additions to your toolkit. But if your application is scaling, trying to save money by hosting PostHog yourself is a false economy. The engineering hours spent maintaining the stack will quickly surpass the cost of their managed cloud.