56,452 files put PostHog in platform territory
PostHog puts product and web analytics beside session replay, feature flags, experiments, error tracking, surveys, data pipelines, and AI observability. The project README also describes workflows and a data warehouse, then exposes the platform through web, desktop, Slack, and MCP clients. That breadth can replace several vendor integrations for a product team. It also means an evaluation should begin with the products you will use, because installing the repository brings far more than an event dashboard.
Our checkout contained 56,452 files, about 10,346,624 source lines, and 733.6 MB before dependencies. The monorepo layout shows why: product folders can own Django backends, React frontends, MCP definitions, agent skills, services, and packages. Separate top-level services include an LLM gateway, MCP server, OAuth proxy, and Stripe app. This organization gives product areas boundaries, but newcomers must learn the repository's routing and developer tools before changing one screen.
What happened when we ran it
Our sandbox installed commit cf416e9 in 304 seconds with pnpm. The install succeeded, pulled 3,638 packages, and occupied 3,679 MB on disk. We ran it in an unprivileged container with 3 CPUs, 8 GB of RAM, Node 22, and no secrets. Those figures cover dependency installation only. We did not run the application, ingest events, measure dashboard response time, or test session replay storage, so they support a setup judgment rather than a performance claim.
The repository exposed no build script or target to our harness, so the build step was skipped. It also exposed no test script or target, so the test step was skipped. There is no passing or failing suite result to report. Our scan found 140 CI workflow files, a Dockerfile, pnpm workspaces, and no tests directory. The automation footprint suggests that checks live behind repository-specific commands and path filters, but our measured result remains narrower: a successful install followed by two unavailable root steps.
The hobby deployment stops at about 100,000 events a month
PostHog recommends its cloud service as the fastest and most reliable route. The README labels self-hosting as an advanced hobby deployment and says open-source instances should scale to approximately 100,000 events per month. Beyond that volume, it recommends migration to PostHog Cloud. That published boundary is more useful than pretending the same deployment fits every company. A small internal product may sit comfortably below it, while a consumer service can cross it before analytics becomes deeply embedded.
The one-line Linux installer uses Docker and recommends 4 GB of memory. PostHog says it provides no customer support or guarantees for open-source deployments, then links to self-hosting and troubleshooting documents. Those terms shift backup, upgrades, queue failures, storage growth, and recovery onto your team. The 3,679 MB dependency footprint from our lab is a developer-environment number, not the full runtime footprint. A production sizing decision needs your event rate, replay volume, retention policy, and enabled products.
The main repository is not entirely MIT licensed
The README says the repository uses the MIT expat license except for the ee directory, which has its own license. GitHub therefore reports no single SPDX license for the repository. If policy requires every checked-out file to share a permissive license, the main tree needs legal review. PostHog points those users to posthog-foss, a read-only mirror that removes proprietary code and tells contributors to file work against the main repository.
That split matters in a 10,346,624-line checkout because licensing is attached to paths, not merely the product name. A team can use the FOSS mirror for a cleaner compliance boundary, but it should confirm that the remaining feature set covers its needs. The main README also distinguishes cloud pricing from open-source availability. Treat edition selection as an architecture decision before instrumentation, since event schemas, flags, replay capture, and operational procedures become harder to move after adoption.
5,803 open issues and PRs accompany daily repository activity
GitHub showed 40,133 stars, 5,803 open issues and pull requests combined, and a last push on October 4, 2026. The latest activity list included work across replay, workflows, data warehouse connectors, product data, and self-driving features on the same date. This is a heavily used and fast-moving repository, not an abandoned dashboard. The combined queue is also large enough that teams should search for their SDK, deployment mode, and feature area before choosing a release or planning an upgrade.
GitHub's latest release endpoint returned desktop-v0.61.621, published October 1, 2026. That tag packages the desktop app for macOS, Windows, and Linux, so it should not be mistaken for a version signal for the whole server. The 140 CI workflow files we found fit a monorepo with several release paths. Pin the component you deploy, read that component's changes, and avoid treating the newest repository-wide tag as a single platform release.
PostHog pays off when it replaces several product-data tools
Our 304-second install succeeded, yet the 3,638 packages and missing root build and test targets show how much project-specific machinery sits behind the interface. PostHog makes sense when one product team will actively use analytics alongside replay, flags, experiments, or error data, and the shared context reduces integration work. For basic traffic counts, a narrower analytics project is easier to own. For supported PostHog at serious volume, the README itself points you toward PostHog Cloud.