PostHog: self-hosting the open source product analytics platform

What PostHog replaces, and who ends up running it

Most product teams end up with a stack rather than a tool: one service for event analytics, another for session replay, a third for feature flags, something else for crash and error reports. PostHog's pitch is that all of these read from the same event stream, so a funnel, a replay and an error report can be joined on the same person and session identifiers. The README lists the components explicitly: product analytics, web analytics, session replays, feature flags, experiments, error tracking, logs, surveys, a data warehouse, data pipelines, AI observability and workflows.

The audience is product and engineering teams that already instrument their app and want the analysis layer to sit next to the code. The repository is a Python and Django application with a large TypeScript frontend, so the people who get the most out of self-hosting are teams comfortable running Docker and reading Django settings. Teams that only want a dashboard and have no interest in operating infrastructure are pointed at PostHog Cloud in the README's own getting-started section, which is listed first and marked as recommended.

The event pipeline behind flags, replays and analytics

The repository layout tells you what kind of system this is. The Python package depends on Django, Celery with celery-redbeat for scheduled work, aiokafka for the event stream, and both clickhouse-connect and clickhouse-driver for storage. Dagster appears alongside dagster-celery, dagster-k8s and dagster-postgres, which points to a separate orchestration layer for batch jobs. A self-hosted install is therefore not one process: it is a Django app, a worker pool, a message broker and a ClickHouse instance at minimum.

Events arrive through the SDKs or the API, flow through Kafka, and land in ClickHouse, which is where the analytical queries run. That is why the README can offer both visualizations and SQL over the same data, and why a single capture call can later appear in a replay, a funnel and an error alert. The trade-off is operational weight. The one-line deploy script exists precisely because wiring those pieces by hand is not a small task, and the Dockerfile comments note that Node.js services are built separately from the main image. If you self-host, you are running a distributed system, not a single binary.

Installing the open source hobby deploy

The README gives one command for a Linux host with Docker and recommends 4GB of memory. Run it on a machine you control, and the deploy script pulls and starts the stack. This is the hobby deploy, not a production-grade installation.

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

Once the instance is up, you need to send it events. The README points to three routes: the JavaScript web snippet, one of the SDKs (JavaScript, Next.js, React, Vue, React Native, Android, iOS, Python, Node, PHP and others are listed), or the API. The Python package is published as posthog and its version in pyproject.toml is pinned to Python 3.13.13, so match your interpreter before installing the backend libraries.

pip install posthog

For local development rather than the Docker deploy, the repository ships an .env.example that the file itself labels as local development only, with a warning that the bundled OIDC_RSA_PRIVATE_KEY is publicly known and must never be used in production. Copy it to .env.local and keep it off any internet-facing host.

cp .env.example .env.local

The first real check is whether an event arrives at all. Capture one event from the SDK, then open the activity view for your project. If nothing appears, the problem is almost always between the client and the ingestion endpoint, not in the query layer.

Where self-hosting stops working

The README is unusually direct about the ceiling: open source deployments should scale to approximately 100k events per month, after which the project recommends migrating to PostHog Cloud. That is a small number for any product with real traffic. A single active user session can generate dozens of events once autocapture, pageviews and replay metadata are counted, so 100k per month is a development and early-testing figure, not a production one.

The second limitation is support. The README states that PostHog does not provide customer support or offer guarantees for open source deployments, and links to a self-hosting disclaimer. There is no SLA, no escalation path and no promise that an upgrade will preserve your data layout. The Dockerfile goes further and notes that support for self-hosted Kubernetes deployments has been sunset, with a blog post linked from the file header. If your team was planning a Helm-based cluster install, that path is closed.

The third is the licence boundary. The repository's package.json declares MIT for the root package, but GitHub reports the repository licence as NOASSERTION, and the README carries an open-source versus paid section. The documentation does not enumerate which features fall on which side, so treat the split as something to read in the LICENSE file rather than assume.

How PostHog differs from a warehouse-first analytics stack

The obvious alternative for a team that wants SQL over product data is to send events into a warehouse and query them there, typically with a tool like dbt sitting on top. The difference is not the query language, because PostHog also exposes SQL. It is where the product-specific features live. A warehouse-first stack gives you events in tables and leaves session replay, feature flags, experiment assignment and error grouping to other vendors, each with its own SDK and its own identity model. PostHog puts those on the ingestion path so they share identifiers from the start.

That choice has a cost. Because flags and replays depend on the same pipeline, a self-hosted outage takes down flag evaluation as well as analytics, which is a heavier failure than losing a dashboard. Teams that treat feature flags as critical infrastructure, where an outage means a broken release, should weigh that coupling carefully. A warehouse-first stack keeps flag evaluation in a client library and the analytics in the warehouse, so the two fail independently.

Maintenance, upgrades and the licence question

The repository is not archived, and the last push was on 2026-08-29. The recent releases shown are all desktop-v0.61.x builds from late August 2026, which means the desktop client is versioned separately from the server. Nothing in the README describes the server release cadence or an upgrade path for self-hosted instances, and the README does not document rollback. If you self-host, plan to read CHANGELOG.md and the migrations before upgrading, because the pyproject.toml pins exact versions across Django, Celery, Kafka clients and ClickHouse drivers, and a partial upgrade is likely to break ingestion.

On licensing, the root package.json says MIT, but the repository-level licence resolves to NOASSERTION on GitHub and the README separates open source from paid. That combination is common for projects with an open core, but it means the MIT declaration in one file is not by itself a statement about the whole codebase. Read LICENSE and the open-source versus paid section before you build a commercial product on a self-hosted instance. This is not legal advice; if the boundary matters to your business, have counsel read the actual licence text.

Editorial conclusion

Adopt PostHog if you want analytics, session replay, feature flags and error tracking fed by one event pipeline, and you are willing to run the hobby Docker deploy or pay for Cloud. Do not adopt the open source deploy for high-volume production traffic, and do not expect support for it, because the README states plainly that open source deployments get no customer support or guarantees. Before committing, verify two things: that your expected monthly event volume fits the roughly 100k figure the README gives for open source, and that the LICENSE file in the repository, which GitHub reports as NOASSERTION, matches the open-source versus paid split described in the README.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes