readystack/posthog repository overview

⁠PostHog

readystack/posthog:master-20261022-b904ac8-CE-ubuntu24.04-r2

Source, recipe and records

• Source and build recipe: https://readystack.dev/products/posthog/recipe⁠
• Upstream source at this release's pinned commit: https://github.com/PostHog/posthog/tree/b904ac8008e531c8aaeaf58e523cf97cff9fba41⁠
• Product page: https://readystack.dev/products/posthog⁠
• Hermetic Build Kit for this release (free with an account): https://readystack.dev/products/posthog⁠
• Release history (JSON): https://readystack.dev/api/releases/posthog⁠
• Defect record: https://readystack.dev/defects.html?product=posthog⁠
• Today's scan: https://readystack.dev/products/posthog#pp-grade⁠
• Report an issue: https://github.com/ReadyStackFree/readystack/issues/new?template=bug.yml&product=posthog⁠
• Signing key (cosign): https://readystack.dev/keys/cosign.pub⁠

A cosign-signed build of github.com/PostHog/posthog default branch (master) at commit b904ac80 (2026-10-22T00:52:01Z, upstream CI green); MIT, with the Enterprise ee/ directory removed, built clean-room from official upstream source by ReadyStack⁠.

⁠Who uses it and why

Who: Product teams and developers who want to see how people use their web or mobile app.

Why: PostHog captures events from a product, automatically or through your own instrumentation, and lets you analyse user behaviour with visualisations or SQL.

Use case: A team ships a new sign-up flow and wants to know where people drop out. PostHog records each step as an event; the team charts how many users reach each step, finds the screen where people give up, and checks the effect after changing it.

About the upstream project, written from its own description: https://github.com/PostHog/posthog⁠

⁠What you get

Signature, user and attestations below were measured on the published digest sha256:385bee71d9e77689906bbed4ba2fbf3ce7519484ce9cb2ce43ff93143a787f39 on 2026-10-30.

• Scan scores — we scan every image we publish every day (an SBOM made with syft, vulnerabilities matched with grype, scored with cerodeo-v1, the rubric ce.rodeo published until 2026-10-26) and record each scan with how its score was derived. This release's first and latest scan: https://readystack.dev/products/posthog⁠
• ReadyStack release check — passed at release on 2026-10-29: no fixable critical or high vulnerability (Docker Scout and OSV), a non-root user, SBOM and provenance attached. This is ReadyStack's own test, not a Docker grade; vulnerabilities published since then are in today's result at https://readystack.dev/queue⁠.
• Signed — cosign signature by the ReadyStack release key (fingerprint 04daa92344a52dbc) on this release's index digest sha256:385bee71d9e77689906bbed4ba2fbf3ce7519484ce9cb2ce43ff93143a787f39; verify with cosign verify --key https://readystack.dev/keys/cosign.pub readystack/posthog:master-20261022-b904ac8-CE-ubuntu24.04-r2.
• Attestations — An SPDX SBOM and SLSA v1 build provenance are attached to this digest.
• Runs as a non-root user (posthog).
• Built from source by ReadyStack.

⁠Which tag should I pull?

This image follows the ReadyStack release-tag convention:

• The current release is master-20261022-b904ac8-CE-ubuntu24.04-r2 — the release listed at readystack.dev. Release tags use the pattern <upstream-version>-CE-<base-os>-r<N>; the current one is signed, attested (SBOM + provenance), and is provided under the ReadyStack Agreement⁠.

• Earlier release tags (an older version or revision in the same pattern) are superseded. They stay pullable so existing deployments can pin them, but they are no longer re-graded, and fixes appear only in newer releases: move to the current release. For a superseded release's build kit, ask support.

• Release tags never move, so pulling the same tag again never changes the image. To be offered each new release automatically (a new revision r<N+1>, or a new upstream version), use the ReadyStack Renovate preset: https://readystack.dev/updates.html⁠

• Any tag beginning with internal- is an engineering-pipeline artifact published for build observability. It is unsupported, may change or disappear without notice, and must not be used in production.

# ✓ current release
docker pull readystack/posthog:master-20261022-b904ac8-CE-ubuntu24.04-r2

# ✗ unsupported (do not pull)
docker pull readystack/posthog:internal-...

This release is signed; verify it with cosign verify --key https://readystack.dev/keys/cosign.pub readystack/posthog:master-20261022-b904ac8-CE-ubuntu24.04-r2 (the signature is recorded in the public Sigstore transparency log). Support: [email protected]⁠, as set out in the ReadyStack Agreement⁠.

⁠Deployment

One image, one PostHog role per container (the command argument), all as the non-root user posthog (uid 10001): allinone (default) runs every PostHog process in one container for a single host: Caddy on :8000 (the one HTTP port), the Django web app (granian) and Celery worker+scheduler, the Node ingestion server, and the Rust capture, feature-flags, property-defs and personhog services. The roles web, worker, ingestion, plugins, capture, feature-flags, property-defs, personhog-replica, personhog-router, proxy and migrate run the same processes one per container. PostgreSQL, Redis-protocol cache (Valkey), Apache Kafka and ClickHouse are not in the image: you run them (the run command starts all four as containers).

Secrets go in env files that only you can read, not on the command line, and passwords that only set up the first start come out of them after setup. Create each file with install -m 600 /dev/null <file>, then write its lines into it with an editor, with your own values (a value typed into a shell stays in its history). Docker reads each line as written: no quotes around a value, no spaces around =.

posthog-db.env:

# First start only: the postgres image reads POSTGRES_PASSWORD only when it initialises its empty volume. You can remove this line after the first start and recreate the db container; the database keeps the password.
POSTGRES_PASSWORD=YOUR_POSTGRES_PASSWORD

posthog.env:

# The same database password as POSTGRES_PASSWORD; needed at every start.
DATABASE_URL=postgres://posthog:YOUR_POSTGRES_PASSWORD@db:5432/posthog
# Django's signing key; needed at every start. Keep it unchanged: changing it signs everyone out.
SECRET_KEY=YOUR_SECRET_KEY
# Comma-separated keys of exactly 32 characters (for example the output of `openssl rand -hex 16`); needed at every start. Keep them: PostHog encrypts integration secrets with them.
ENCRYPTION_SALT_KEYS=YOUR_32_HEX_KEY

docker network create posthog-net
docker run --rm -v posthog-clickhouse-files:/code/share/clickhouse readystack/posthog:master-20261022-b904ac8-CE-ubuntu24.04-r2 version
docker run -d --name db --network posthog-net --restart unless-stopped -e POSTGRES_USER=posthog -e POSTGRES_DB=posthog --env-file ./posthog-db.env -v posthog-postgres:/var/lib/postgresql/data postgres:16
docker run -d --name redis --network posthog-net --restart unless-stopped -v posthog-redis:/data valkey/valkey:8-alpine
docker run -d --name kafka --network posthog-net --restart unless-stopped -e KAFKA_NODE_ID=1 -e KAFKA_PROCESS_ROLES=broker,controller -e KAFKA_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093 -e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://kafka:9092 -e KAFKA_CONTROLLER_LISTENER_NAMES=CONTROLLER -e KAFKA_LISTENER_SECURITY_PROTOCOL_MAP=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT -e KAFKA_CONTROLLER_QUORUM_VOTERS=1@localhost:9093 -e KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR=1 -e KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR=1 -e KAFKA_TRANSACTION_STATE_LOG_MIN_ISR=1 -e KAFKA_NUM_PARTITIONS=1 -v posthog-kafka:/var/lib/kafka/data apache/kafka:4.1.0
docker run -d --name clickhouse --network posthog-net --restart unless-stopped --ulimit nofile=262144:262144 -e CLICKHOUSE_SKIP_USER_SETUP=1 -e KAFKA_HOSTS=kafka:9092 -v posthog-clickhouse-files:/posthog:ro -v posthog-clickhouse:/var/lib/clickhouse --entrypoint /posthog/start-clickhouse.sh clickhouse/clickhouse-server:26.9.13.15
until docker exec db pg_isready -U posthog -d posthog; do sleep 2; done
docker run -d --name posthog --network posthog-net --restart unless-stopped -p 8000:8000 -p 3000:3000 -e REDIS_URL=redis://redis:6379/ -e KAFKA_HOSTS=kafka:9092 -e CLICKHOUSE_HOST=clickhouse -e SITE_URL=http://localhost:8000 -e IS_BEHIND_PROXY=false -e DISABLE_SECURE_SSL_REDIRECT=true -e SECURE_COOKIES=false -e OBJECT_STORAGE_ENABLED=false --env-file ./posthog.env readystack/posthog:master-20261022-b904ac8-CE-ubuntu24.04-r2

Replace YOUR_POSTGRES_PASSWORD (twice), YOUR_SECRET_KEY (a long random string; keep it) and YOUR_32_HEX_KEY (exactly 32 characters: openssl rand -hex 16; keep it). Set SITE_URL to the URL users open; behind a TLS proxy set IS_BEHIND_PROXY=true and drop DISABLE_SECURE_SSL_REDIRECT and SECURE_COOKIES=false. The image's Caddy keeps the proxy's X-Forwarded-Proto when the proxy connects from a private or loopback address; a proxy on any other address goes in TRUSTED_PROXIES (space-separated addresses or CIDR ranges). The first start migrates the empty databases (see First boot in the handbooks) before :8000 answers. The second command fills the empty posthog-clickhouse-files volume from the image (Docker fills only an empty volume, so running it again changes nothing). After you pull a newer image, refresh the files with docker run --rm -v posthog-clickhouse-files:/out readystack/posthog:master-20261022-b904ac8-CE-ubuntu24.04-r2 clickhouse-config /out and restart the clickhouse container.

⁠The full ReadyStack Hermetic Build Kit

The complete --network=none build kit for this image — plus admin/DB/API handbooks, the build's validation records, and its build provenance records — is a free download for any registered account at readystack.dev/products/posthog⁠. A clean-room rebuild from this release's archive on an egress-blocked host reproduced its linux/amd64 digest sha256:b8976c25ffc5482b07d78aefd5a94abb9b5de80881845c876075c9e118fd1e07 on 2026-10-30.

— ReadyStack · readystack.dev