PostHog: read this before you install it
PostHog is a product analytics platform, not a small dashboard. I would be very careful with self-hosting: the official project itself recommends cloud for most users and labels hobby self-hosting as advanced.
Author / organization: PostHog
This page is a private experience note, not official documentation.
This note treats PostHog as a deployment decision, not just a quick-start command. I focus on fit, architecture boundaries, first verification steps, and failure triage.
- Primary check: prepare the runtime and dependency layer before the first demo.
- Source consulted: official source and project-level setup assumptions.
- Best use: compare this note with nearby tools before committing to production work.
- Last updated: June 2026.
Do not self-host it casually
I would not self-host PostHog casually. The project is powerful, but the stack behind product analytics is heavy: event capture, ingestion, storage, workers, plugins, feature flags, recordings, and UI.
Before installation, I ask one uncomfortable question: do we need self-hosting, or do we just want analytics? If privacy, compliance, or infrastructure control is not a hard requirement, cloud may be the more honest first choice.
When PostHog belongs in the stack
PostHog fits when product behavior matters: events, funnels, retention, feature flags, session replay, experiments, and developer-friendly analytics.
I would not deploy it only to count visits on a small content site. That is too much machine for the question.
Events, ingestion, ClickHouse, workers, plugins
My mental map is event capture to ingestion to queue/workers to ClickHouse/storage to UI queries. Each layer can fail independently.
The UI is the last layer. If the UI is empty, I do not immediately blame charts. I check whether events arrived at all.
The checks before tracking real users
My prep is capacity and decision-making. Self-hosting should have a real reason, known event volume, disk planning, and a person responsible for upgrades.
The first verification is one event from one test page. If that single event cannot be found reliably, no product decision should depend on the instance.
My PostHog command path
Use prep to decide cloud versus self-host and check resources. Use verify for a single event pipeline. Use debug by separating SDK, ingestion, queue, storage, and UI.
Do not debug analytics by changing product code first. Prove the pipeline with one controlled event.
Use the PostHog commands by event pipeline
cloud vs self-host — Before install, decide whether you really need self-hosting. If self-hosting, check memory, disk, Docker, and event volume expectations.
one event — After startup, send one test event, confirm it appears, restart, and check whether historical events remain.
pipeline layer — When events vanish, split capture SDK, ingestion, queue, ClickHouse, workers, and UI time range before changing tracking code.
When events disappear or the stack feels heavy
If no events show up, I check project key, host URL, blockers, CORS, and browser network tab. If events are delayed, I look at workers and storage.
If self-hosting feels heavy, that is not a personal failure. Product analytics stacks are real infrastructure.
The first analytics test I would keep
The first analytics test I would keep is a single static test page that sends one `rfn_test_event` with a known property.
Then I confirm it in the UI, change the time range, restart, and confirm it still exists.
Field commands I would keep beside this note
# PostHog prep docker version free -h df -h # official repo describes hobby self-host as advanced # read the current self-host notes before running the deploy script
# PostHog verify # after the official deploy path finishes docker ps docker compose ps || true # UI checks 1. create project 2. send one test event 3. confirm it appears in live/events view 4. restart stack 5. confirm event history remains
# PostHog debug no events -> SDK key, host URL, ad blocker, CORS events delayed -> worker/queue/ClickHouse health UI empty -> time range or project mismatch stack heavy -> check disk/image size and RAM self-host pain -> reconsider PostHog Cloud for small teams