Tip: select any text on this page to bring up the Ask tooltip and question the Synedrix OS assistant about it.
What PostHog is
PostHog describes itself as the open source platform for building self-driving products, providing the tools to build a product and capturing the context needed to diagnose problems and uncover opportunities.
Everything is built on one data model. Product analytics, feature flags, experiments, session replay, and surveys are all views over the same events, persons, and properties, which is why a flag can be targeted on the same cohorts an insight is built from.
For Synedrix OS the relevant surfaces are the first three: analytics over workflow usage, flags as a runtime control, and experiments over agent and prompt variants.
What it is normally used for
How PostHog is used generally, before Synedrix OS enters the picture.
- Product analytics: what people actually do in a product, by visualisation or SQL
- Feature flags: rolling features out to selected users or cohorts
- Experiments: testing changes and measuring statistical impact on goal metrics
- Session replay: replaying real user sessions with synced console and network context
- Surveys: targeted on the same events, cohorts, and flags as everything else
What it owns, and what it does not
Every platform in the stack has a non-overlapping responsibility. The boundary is as much a part of the design as the capability.
Owns
- Workflow analytics
- Feature flags
- A/B experiments
- Business decision analytics
Does not own
- LLM trace spans, prompt versions, model-output evaluation
- → Langfuse (Layer 10)
- Infrastructure health, dashboards, SLO alerting
- → Grafana LGTM Stack (Layer 10)
- Raw time-series and rolling temporal aggregates
- → QuestDB (Layer 7)
- Audit-grade invocation and review records
- → Supabase PG17 (Layer 7)
- Whether a specific action is permitted
- → Policy Guard (os-agt-002)
- Immutable lineage and audit reconstruction
- → Audit and Lineage Agent (os-agt-008), read-only
Why PostHog
Analytics, flags, and experiments share one data model
Is a feature being used? Should it be turned on? Did turning it on actually help? Those are really the same underlying question, asked three different ways, and PostHog answers all three from one shared set of data.
Features can be rolled out gradually, without a deployment
A business instance sometimes needs to turn on a capability for some users before everyone, without shipping new code. PostHog's feature flags do that, and because they're built on the same data as its analytics, the rollout can be measured as it happens.
"Is this working for people?" is a different question from "is it up?"
Judging whether autonomous behaviour is working well means looking at how much people actually use it and how often they override it, not just whether the model is accurate or the system is running. Neither the LLM-focused platform nor the infrastructure-monitoring platform answers that question.
The raw data is always reachable, not locked behind dashboards
Built-in dashboards aren't the only way to get answers out of PostHog. Direct SQL access to the underlying data means a report can be produced without exporting everything into a separate analytics tool.
Licence position
PostHog questions, answered
Short, citable answers drawn from this page.
What role does PostHog play in Synedrix OS?
PostHog (Product analytics) is mapped to Layer 10: Observability in Synedrix OS. Is the product working for the people using it? A different question from system health.
What does PostHog own in Synedrix OS?
PostHog owns: Workflow analytics; Feature flags; A/B experiments; Business decision analytics.
What does PostHog not own in Synedrix OS?
PostHog does not own: LLM trace spans, prompt versions, model-output evaluation (owned by Langfuse (Layer 10)); Infrastructure health, dashboards, SLO alerting (owned by Grafana LGTM Stack (Layer 10)); Raw time-series and rolling temporal aggregates (owned by QuestDB (Layer 7)); Audit-grade invocation and review records (owned by Supabase PG17 (Layer 7)); Whether a specific action is permitted (owned by Policy Guard (os-agt-002)); Immutable lineage and audit reconstruction (owned by Audit and Lineage Agent (os-agt-008), read-only).
What licence is PostHog under?
PostHog is released under MIT Expat outside ee/; ee/ under the PostHog Enterprise License. The self-hosting position is the material issue rather than the licence. PostHog states that open source deployments should scale to approximately 100k events per month before migrating to cloud, that it does not provide support or guarantees for open source deployments, and that self-hosted is intended for hobbyists. Kubernetes is no longer supported for new deployments, leaving a single-machine Docker Compose install. Role-based access control, audit logs, and custom data retention are cloud-only.
The full reference page, with the operating model, deployment detail, and links to every canonical specification this platform touches, lives in the documentation repository, which is private while the platform is being built.