What happened when we ran it
Our Node 22 sandbox installed 3,633 pnpm packages in 261 seconds. They occupied 3,615 MB on disk, while commit 477457f itself was a 628.3 MB checkout with 45,322 files and about 8,372,779 source lines. Those figures put the self-hosting decision in the right frame: PostHog is a product platform, not a small analytics service.
The monorepo exposed no build script or target and no test script or target to our generic runner, so both stages were skipped. It has 128 CI workflow files and a Dockerfile, but no top-level tests directory. Our run confirms a large dependency installation; it provides no passing build or test evidence for this commit.
One data model connects analytics, replay, flags, and errors
PostHog records events, page traffic, sessions, exceptions, logs, surveys, warehouse data, and language-model traces. It adds funnels, retention analysis, replay, feature flags, experiments, workflows, and pipelines. Slack, web, desktop, and an MCP connection give people and agents access to the same product context.
That consolidation is useful when a team can inspect a failed conversion, watch the session, correlate an error, release a fix behind a flag, and measure the result in one system. It also expands governance work. A small site that wants visitor counts will find far more product, data, and cost surface than it needs.
Cloud avoids owning an 8.3-million-line platform
The README is unusually direct about deployment. PostHog Cloud is the recommended path and offers separate US and EU signups. Its listed monthly free allowances cover one million events, 5,000 recordings, one million flag requests, 100,000 exceptions, and 1,500 survey responses. Those figures are allowances, not a promise that every product will remain free, because usage above them is billed per tool. Still, they make a real evaluation possible without operating the backend first.
Once an account exists, collection starts through a web snippet, one of the documented frontend, mobile, or backend SDKs, or the API. The README names JavaScript, React, Next.js, Vue, React Native, Android, iOS, Flutter, Python, Node, PHP, and Ruby, with additional guides for other frameworks. That coverage matters more than a clever dashboard because incomplete or inconsistent collection ruins every analysis downstream.
Self-hosting deserves a colder reading. The advertised one-line installer deploys a hobby instance on Linux with Docker and recommends 4GB of memory. The project says an open-source deployment should scale to about 100,000 events per month, then recommends moving to PostHog Cloud. It also states that open-source deployments receive no customer support or guarantees. That is honest, but it means the shell command is a trial path, not evidence of an easy production service.
The useful parts come with governance work
Product analytics and web analytics cover the common questions: acquisition, conversion, activation, retention, revenue, and behavior across cohorts. Session replay adds the missing visual explanation when a chart only shows that users failed. Feature flags and experiments then connect diagnosis to delivery. Error tracking and logs can keep technical failures next to the user journey rather than in a disconnected observability product.
This shared context is valuable only when its collection is trustworthy. Teams need an event dictionary, stable properties, identity rules, and a process for deleting or renaming bad events. Replays, surveys, warehouse sources, and external destinations widen the privacy boundary. Consent, masking, access controls, regional requirements, and retention must be decided before broad collection. PostHog supplies tools and documentation, but the operator remains responsible for what enters the system.
The licensing boundary also needs attention. The README says the repository uses the MIT expat license except for the ee directory, which has its own license. Organizations requiring a purely FOSS codebase are directed to the separate posthog-foss repository. That distinction is clear enough to evaluate, yet procurement teams should review it before treating every directory in this monorepo as identically licensed.
Too much product for a simple website
PostHog is a poor trade for someone who wants only daily visitors, referrers, and popular pages. Plausible is narrower and easier to reason about for that job. Matomo suits teams that want a mature, self-hosted web analytics application. GrowthBook is the sharper option when flags and experiments matter but an existing warehouse already holds the analytical truth.
PostHog makes more sense when several capabilities will actually share context. Its data warehouse connections can bring outside business data beside product events. Pipelines can transform incoming data or send it to more than 25 tools and webhooks. AI observability can capture model traces, generations, latency, and cost. Workflows can act on user or product signals. The MCP connection can expose PostHog to Claude Code, Cursor, and other compatible agents.
A very active project with a very large queue
The repository was pushed on August 26, 2026, and desktop-v0.61.35 was released the same day. That tag is specifically a PostHog Desktop build, not a version of the whole platform. GitHub listed 5,150 open issues and pull requests, while current work included warehouse parsing fixes, task sandbox routing, log filters, and transport retry behavior.
Those figures describe a fast-moving monorepo rather than a finished appliance. The same-day push, release, fixes, and reports show current activity. They also imply frequent change and a large triage surface. Cloud customers can let PostHog absorb much of that motion. Self-hosters must choose updates carefully and accept the README's support disclaimer.
PostHog is easy to recommend for a serious product organization willing to adopt several of its connected tools. Start in Cloud, instrument one important journey, and prove that replay, errors, flags, and experiments improve decisions before expanding collection. Self-host only when control is worth the operating burden and the stated hobby limits fit. The project is powerful because it connects product work end to end, not because every team needs everything it contains.