# PostHog's one-line self-host install curls a git ref, and its Kubernetes support is sunset

> PostHog is an open source platform bundling product analytics, session replay, feature flags, experiments, error tracking, logs, surveys, a data warehouse, data pipelines, AI observability and workflows, with MCP access from your editor. The README is unusually candid about pricing and support. The repository is where the harder facts sit: an install script fetched from HEAD, a sunset Helm path, one exact Python patch pin, and a committed private key.

**PostHog/posthog** — GitHub describes it as :hedgehog: PostHog is the leading platform for building self-driving products. Our developer tools , AI observability, analytics, session replay, flags, experiments, error tracking, logs, and more , capture all the context agents need to diagnose problems, uncover opportunities, and ship fixes. Steer it all from Slack, web, desktop, or the MCP.. The repository metadata lists Python as its primary language. The metadata lists the NOASSERTION license. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/PostHog/posthog
- Website: https://posthog.com
- Stars: 39,973 · Forks: 3,430
- Language: Python
- License: NOASSERTION
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/posthog-posthog

## The one-line self-host install fetches the HEAD ref, not a tag

The self-hosting path is one line:

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

Look at what is being fetched. The URL points at HEAD, which resolves to the default branch at the moment you run it. There is no version, no tag, no commit.

So the script is not reproducible. Two people running that line on different days get different scripts, and the only way to know what a given instance is running afterwards is to read the repository at the commit it happened to fetch.

There is also no obvious version to pin to instead, because the release feed is per artefact. The three most recent releases are a desktop build and two releases of an agent npm package, two of them on the same day, with no server release among them.

The consequence is that the documented happy path for a self-hosted install is a moving target, and the file does not offer a tagged alternative. Pinning it means reading bin/deploy-hobby out of the repository yourself at a commit you choose.

## Self-hosting is scoped to 100k events a month against a 1 million free cloud tier

Both numbers are in the README, close enough that you can compare them directly.

The cloud section says your first 1 million events, 5k recordings, 1M flag requests, 100k exceptions and 1500 survey responses are free every month, after which you pay based on usage. Two signup routes are offered, a US region and an EU region.

The self-hosting section says open source deployments should scale to approximately 100k events per month, after which it recommends migrating to PostHog Cloud. The stated recommended memory for the Docker deploy is 4GB.

That is a factor of ten between what the free managed tier absorbs and what the self-hosted path is scoped for, expressed in the same file.

The consequence is that the self-host route is framed as an evaluation path, and the project says so by pointing you at a migration guide rather than a scale-up path. If your steady-state volume is above 100k events a month, the file is telling you the answer, and it is telling you before you have done the work rather than after.

## Self-hosted Kubernetes support is sunset and the README never mentions it

The deprecation is stated in a comment at the top of the main Dockerfile:

```
# This Dockerfile is used for self-hosted production builds.
#
# PostHog has sunset support for self-hosted K8s deployments.
# See: https://posthog.com/blog/sunsetting-helm-support-posthog
```

The README's self-hosting section does not mention Kubernetes at all. It offers a one-line Docker deploy, and the table of contents has no Kubernetes entry. The documentation set it links to is self-hosting docs, a troubleshooting guide, and a disclaimer.

So a team standardising on Kubernetes finds out from a Dockerfile comment, and the recommended hardware is 4GB of memory for a Docker container rather than a resource request in a chart.

The consequence is a support boundary that is enforced rather than discouraged. If your platform standard is Kubernetes, the Compose or Helm route the project used to offer is closed, and the file gives you one blog link rather than a migration note inside the install instructions you would actually read.

## PostHog Cloud runs the same image you build for self-hosting

The same Dockerfile comment block answers a question nobody asks out loud. There is no separate cloud image, because the cloud runs this image re-tagged into a private registry.

Two consequences pull in opposite directions. In one, parity is close to guaranteed, since the artifact your team builds and runs is the artifact the vendor runs, so a self-hosted instance is not a lagging fork of a different build. In the other, there is no hardened self-host variant, so anything you change about the image, you are changing about the same code the vendor operates.

The same file also reveals the build's shape. It names six stages, a shared Node base, a frontend build, a sourcemap upload, a Node scripts build, a Django build, and a GeoIP database fetch, and it says Node.js services are built separately using a second Dockerfile.

That is at least six Dockerfiles at the top level, counting the main one, a Node one, and dedicated ones for LLM analytics, an ML mirror image scrub, Playwright, a recording rasterizer and a sandbox. The consequence for a contributor is that knowing which one builds the thing you changed is a real question, and the answer is a comment in each file rather than a page anywhere.

## The root npm manifest runs Django commands and carries deprecations as keys

The root package is a workspace root, not a library. Its name is @posthog/root, its version is 0.0.0, its description is an empty string, and its licence field says MIT.

Its scripts are where it gets interesting, because a JavaScript manifest is the entry point for Python work. There is a script that shells out to a bash file to build the Python schema, one that runs a Django management command to generate source configs, and migration scripts that activate a virtualenv and run migrate and migrate_clickhouse.

Then there is the deprecation scheme. Scripts are retired by adding a sibling key whose name is a comment and whose value is an empty string:

```
"// DEPRECATED - use hogli migrations:run instead": "",
"// DEPRECATED - use hogli format:python instead": "",
"// DEPRECATED - use hogli format:js instead": ""
```

The consequence is two-fold. A contributor running a Django migration has to go through Node tooling to do it. And the deprecation markers are not comments a parser strips, they are keys that ship in the published manifest, which means both the old script and its replacement stay in the file and you choose.

## Python is pinned to a single exact patch release

The project manifest states:

```
requires-python = "==3.14.7" # Pin full version to control Python upgrades explicitly
```

An exact patch pin. Not a floor, not a compatible range, a specific interpreter build.

Above it, the file explains its own dependency convention at length. It says to prefer the compatible-release operator over a floor, to pin exactly only when necessary, and that the compatible operator signals to security, developer experience and dependabot that a dependency can move within its range without pulling the team in, while an unbounded floor gives no such signal.

The dependency list then does the other thing. Most entries use exact pins, from aioboto3 and aiohttp through celery, dlt and dagster, with a smaller number using the compatible operator, among them aiokafka, django, dj-database-url and django-cors-headers.

The consequence is an environment that has to be built to a patch level. A machine on the previous patch or the next one will not resolve, and the stated convention is not the one the file mostly follows, which undercuts the signalling argument it just made.

## The example env file ships a working OIDC private key and warns in capitals

The env example opens with a warning that is worth reading literally:

```
# WARNING: This file is for LOCAL DEVELOPMENT ONLY.
# NEVER use these values in production. The OIDC_RSA_PRIVATE_KEY below is publicly
# known and would allow anyone to mint valid OAuth tokens if used in production.
```

And then it provides the key, in full, in PEM form. The project is not hiding it and not pretending it is a placeholder.

The rest of the top level shows that committing env files is an established pattern here rather than an accident: there is a development env file, a local example, and a services env file alongside the example.

The consequence is one specific failure mode. Anyone who copies the example into a production deployment, which is the ordinary way this value would arrive there, is running an OAuth issuer whose signing key is published in a public repository. The warning is correct and prominent, and it does not help the person who deploys at two in the morning without reading the first three lines. Rotating that key is a deployment step, not an optional hardening step.

## Conclusion

Use PostHog if you want one platform for product analytics, replay, flags, experiments, error tracking and LLM observability rather than five vendors, and if the per-tool free tiers are enough for your volume. Do not self-host expecting production support, because the file states plainly that no customer support and no guarantees are offered for open source deployments, and treat the hobby deploy as an evaluation route since the stated ceiling is roughly 100k events a month against 1 million on the free cloud tier. Before you deploy, check three things: that your orchestrator is Docker rather than Kubernetes, since Helm support is sunset; that the install script is pinned, since the one-liner fetches the HEAD ref; and that you have replaced the OIDC signing key, because the example env file ships a working one that anyone reading the repository can use.

## FAQ

### How much does PostHog cost?

Every tool has a generous monthly free tier, and the cloud section gives the numbers: your first 1 million events, 5k recordings, 1M flag requests, 100k exceptions and 1500 survey responses are free every month, after which you pay based on usage. Self-hosting is free but unsupported, with no customer support and no guarantees offered for open source deployments.

### Is PostHog still open source?

The repository is presented as the open source platform, the root package manifest declares MIT, and the README carries an open-source versus paid section alongside a free tier for each tool. Worth knowing: the repository's own licence metadata field reads NOASSERTION rather than naming a licence, so a scanner reading that field gets no answer while one reading the package manifest gets MIT.

### how to install posthog

The recommended route is signing up for PostHog Cloud, with separate US and EU regions. To self-host, the file gives one line on Linux with Docker and recommends 4GB of memory, and states that open source deployments should scale to approximately 100k events per month. Note that the main Dockerfile records that support for self-hosted Kubernetes deployments has been sunset.

### Is PostHog safe to use?

The repository contains a concrete warning rather than a general assurance. The example env file states that it is for local development only, that the values must never be used in production, and that the OIDC RSA private key it contains is publicly known and would let anyone mint valid OAuth tokens if it were used in production.

### how to use posthog mcp

Connect the MCP to bring PostHog into Claude Code, Cursor, or any MCP-compatible agent. The same surface is described as the fourth way to steer the platform, alongside Slack, the web app, and PostHog Desktop.

## Sources

- [Official documentation](https://posthog.com)
- [Official README](https://github.com/PostHog/posthog#readme)
- [Project repository](https://github.com/PostHog/posthog)
- [Release notes](https://github.com/PostHog/posthog/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/posthog-posthog