The one-sentence answer
The open-source session replay landscape splits into three tiers: capture libraries you build on (rrweb), full self-hostable products (OpenReplay, PostHog), and specialised tools (Replay.io for time-travel debugging). Pick by what you actually need to control — and what ops burden you're willing to carry.
When open-source replay actually makes sense
Three legitimate reasons to self-host instead of using a hosted vendor:
- <strong>Strict data residency.</strong> If your data subjects are in regulated jurisdictions (EU, UK, certain Asia-Pacific) and your DPO insists no third-party processor touches the recordings, self-hosting eliminates the question. Hosted vendors offering EU-region storage solve most of this — but not all of it.
- <strong>Customisation.</strong> If you need a non-standard capture pattern (specific Shadow DOM trees, custom canvas sampling, internal-only DOM nodes flagged as PII), an OSS capture library you can fork is more flexible than a hosted vendor's config knobs.
- <strong>Scale economics.</strong> At very high volumes (10M+ sessions/month), self-hosted storage + bandwidth can be cheaper than per-session vendor pricing. Below that, the operational cost dominates.
When self-hosting costs more than it saves
The hidden costs people underestimate:
- <strong>DevOps headcount.</strong> A production OSS replay deployment needs someone on-call for the storage tier, the viewer service, the capture ingestion, and the upgrade cycle. Half an engineer at $150K loaded cost = $75K/year — more than most hosted replay contracts at mid-market scale.
- <strong>AI feature gap.</strong> OSS tools have light AI (PostHog has summaries; OpenReplay has some). Full workflows — AI-drafted bug tickets, auto-generated tests, MCP-native access — are a hosted-vendor differentiation. Re-building these in-house is months of work.
- <strong>Browser support drift.</strong> Chrome/Edge/Firefox/Safari ship breaking changes that affect capture (cross-origin policies, third-party cookie defaults, Manifest V3 for extension-based capture). Hosted vendors absorb this; self-hosted teams have to test + patch.
- <strong>Storage economics at scale.</strong> Raw sessions are small (~30 KB each) but compress poorly under high cardinality; cold-storage tiers (S3 Glacier, GCS Archive) help but you have to design + maintain the lifecycle. Hosted vendors get bulk-rate storage you can't match below a certain volume.
rrweb — the capture library most OSS replay is built on
rrweb (record-and-replay-web) is an MIT-licensed JavaScript library for capturing the DOM + reconstructing it later. It's not a product — it's the capture primitive. Most OSS replay tools (OpenReplay, PostHog) use rrweb under the hood. If you want full control of the capture pipeline (sampling, masking, custom event types) and you're willing to build the viewer + storage + analysis layer yourself, rrweb is the foundation. Caveat: you're committing to a multi-month engineering project just to reach feature parity with a hosted MVP.
OpenReplay — full self-hostable replay product
OpenReplay is the most mature self-hostable replay product. Core repo is AGPL v3 (with MIT for some directories and a proprietary EE tier for `ee/`); Helm chart for Kubernetes deployment; includes the capture SDK + storage + viewer + analytics dashboard. kAI + Summary AI for session insights are bundled. Closest OSS analog to a hosted vendor. Real ops burden: storage scaling, viewer service uptime, OAuth setup, upgrade cycle every 4-6 weeks. Legal note: AGPL v3 carries a network-copyleft obligation — if you modify and offer the modified service externally, source changes must be published. Recommended path if you're committed to self-hosting and have at least one engineer who can own the deployment.
PostHog — replay inside a broader analytics platform
PostHog is an open-source product analytics + feature flags + replay platform (MIT license headline; parts of the repo may have additional licensing). Replay is one capability inside a larger product, not the focus. PostHog AI (a copilot called Max) ships across the platform. Best fit if you already use PostHog for analytics + experimentation and want replay attached to your existing event streams. Less specialised than OpenReplay on replay-specific features, but the bundled analytics + LLM copilot may justify it.
Replay.io — time-travel debugging, not general replay
Replay.io captures full execution traces (every variable, every function call) for time-travel debugging — closer to a recording browser dev tool than a session-replay product. Better fit for debug + bug-repro workflows than for production observability. Their capture engine is open source.
How to evaluate
A 30-day evaluation that protects you from sunk-cost trap:
- <strong>Week 1:</strong> Deploy OpenReplay or PostHog locally (docker-compose), point a test site at it, verify capture works.
- <strong>Week 2:</strong> Estimate production ops effort honestly. Write down: backups, storage scaling, OAuth, monitoring, alerting, upgrade cadence. Multiply by your loaded engineering cost.
- <strong>Week 3:</strong> Get quotes from 2-3 hosted vendors at your expected scale. Compare against the ops-loaded OSS cost.
- <strong>Week 4:</strong> Decide. If OSS is genuinely cheaper AND the AI/test-gen gap is acceptable, commit. If hosted is within 30% of OSS loaded cost, hosted almost always wins on velocity.
Why Relyv vs the OSS options
Relyv is a hosted product — not open source — so the comparison is fair only when you accept the vendor model. What you get: AI-drafted bug tickets, auto-generated Playwright tests, live conditional patches, MCP-native access, 14 KB SDK, on-device PII masking with optional GLiNER LLM. What you give up: source code access (we publish the SDK loader; the backend is proprietary), and the option to self-host the storage layer. Free tier (1,000 sessions/mo) lets you evaluate without committing.