Open Source Session Replay in 2026: Four Options, Zero Marketing

Most articles about open source session replay are written by the vendors themselves, and it shows. Every tool is “lightweight,” every install is “one command,” and nobody mentions what happens when you try to upgrade nine months later.

I’ve run three of the four options below in anger, and evaluated the fourth twice before deciding against it both times. This is the comparison I wanted before I burned those weekends.

The four realistic candidates in 2026: OpenReplay, the Highlight.io lineage (which includes LogReplay), PostHog, and raw rrweb. They are much less interchangeable than their landing pages suggest.

What “open source session replay” actually means, per tool

“Open source” is doing a lot of work in this category, and it means something different in each case. Before comparing features, check what you’re actually allowed to do and what the vendor actually supports:

• rrweb is MIT-licensed and is the genuine article: a library you can do anything with. It’s also just a library — a recorder and a player, no backend.
• Highlight.io and its forks ship the whole product under a permissive license (Apache 2.0 for the Highlight monorepo, as of mid-2026 — verify against the repo before you commit). Recorder, ingest, storage, player, the works.
• OpenReplay publishes its stack on GitHub, but parts have carried Elastic-style license terms in the past, so read the LICENSE files in the repo rather than the homepage. Functionally it’s self-hostable; legally, check whether your use case fits.
• PostHog has an MIT-licensed core, but per their public docs they’ve deprecated meaningful support for the full self-hosted product — the “hobby” deploy exists, but they steer everyone with real traffic to their cloud. Replay specifically is a heavy feature to run yourself on the hobby path.

That last point matters more than people expect. An open license with no supported self-host path means you’re maintaining a fork of someone’s cloud product. That’s not self-hosting, that’s adopting a codebase.

The comparison table

Footprint numbers are order-of-magnitude, not benchmarks. Your traffic and retention settings dominate everything.

OpenReplay: capable, and heavy on purpose

OpenReplay is a serious product. It records via its own tracker (rrweb-influenced but not vanilla rrweb), correlates network and console data, and has genuinely good dev tooling in the player.

The catch is operational. It’s built Kubernetes-first, with a service topology that assumes you either have k8s already or are willing to run their single-machine installer and accept a lot of moving parts on one box. If your team has a platform engineer and an existing cluster, this is a reasonable home. If your “infrastructure team” is you, on Tuesdays, it’s a lot.

Upgrades are where k8s-first architecture cuts both ways: Helm makes them scriptable, but when a migration goes sideways you’re debugging someone else’s operators. I’d pick OpenReplay at 20+ engineers with dedicated infra ownership, not below.

The Highlight lineage: one box, full stack

Highlight.io was built as a hosted product first and open-sourced whole — session replay, error monitoring, log ingest, and OpenTelemetry tracing sharing one backend. Forks like LogReplay continue that stack with a single-node Docker Compose deployment as the primary self-host path.

The stack underneath is ClickHouse + Kafka + Postgres + Redis + object storage. That sounds like a lot, and it is — but it’s a lot on one machine, managed by one Compose file, which is a very different ops burden than a lot spread across a cluster. Something like 8GB of RAM and 4 cores runs it for small-team traffic.

The honest tradeoff: Kafka and ClickHouse on a single node means your scaling ceiling is that node. For a team of 1–20 engineers with tens of thousands of sessions a month, you will not hit that ceiling. If you’re expecting millions of sessions, you’re shopping in the wrong aisle anyway.

Upgrade pain is moderate: pull new images, run migrations, and keep an eye on ClickHouse schema changes in the release notes. I’ve had one upgrade require manual intervention; it cost me an evening, not a week.

PostHog: great product, wrong question

PostHog’s replay is good, and if you’re already paying for PostHog cloud, use it and stop reading.

But this article is about self-hosting, and per their public docs as of mid-2026, PostHog explicitly deprioritized the self-hosted product. The hobby deployment is offered without support or scaling guarantees, and replay is one of the more resource-hungry features to run on it. Their position is coherent — supporting self-hosted deployments of a complex analytics suite was clearly eating their team alive — but it means “PostHog, self-hosted, for production replay” is a path the vendor is actively walking away from.

Choosing infrastructure the vendor is deprecating is how you end up owning an unplanned migration. I’ve done that migration. Don’t.

Raw rrweb: the library-shaped trap

Every product above owes something to rrweb, and the temptation is obvious: it’s MIT, it’s excellent, and record({ emit }) plus a <Replayer> component looks like a weekend project.

The recording is the weekend project. The product is the year:

• An ingest endpoint with auth, batching, and compression
• Storage and chunking for event streams that can hit megabytes per session
• A session list with search, which means indexing metadata
• Console, network, and error capture wired into the same timeline (rrweb doesn’t do this for you)
• Privacy masking policy, retention jobs, deletion for GDPR requests
• Access control, because replays are sensitive by nature

I built roughly 60% of this list at a previous job before admitting the remaining 40% was the hard part. Build on rrweb directly if replay is your product. If replay is a tool you use to debug your actual product, buy or deploy someone’s finished version.

The upgrade-pain tax, quantified badly

Nobody budgets for upgrades, so let me at least frame the shape of the cost. Across the options, my rough experience for a routine minor-version upgrade versus a bad one:

A routine upgrade on the Highlight lineage is fifteen minutes: pull, migrate, smoke-test a replay. A bad one — schema change in ClickHouse, or a Kafka topic format shift — is an evening with the release notes. On OpenReplay under k8s, routine is similar if your Helm values are clean, but a bad upgrade can cascade into debugging operator state, which is a different tier of evening. PostHog hobby upgrades are officially unsupported at scale, which means every upgrade is a coin flip you can’t complain about. And rrweb “upgrades” are just dependency bumps — until a major version changes the event schema and your stored recordings need a migration path you have to design yourself. That last one is the sleeper: rrweb has changed its event format across major versions before, and if you built your own storage, old sessions don’t play back for free.

The pattern worth internalizing: managed complexity (Compose, Helm) makes routine upgrades cheap but concentrates risk into rare, opaque failures. Hand-rolled simplicity makes every upgrade legible but puts you on the hook for problems the products solved years ago. Pick which failure mode suits your team’s patience.

Storage: the cost nobody puts in the table

One more line item before the recommendations, because it dominates long-run cost more than CPU or RAM: recordings are big and they accumulate. A DOM-event session runs from tens of kilobytes to a few megabytes depending on page complexity and session length. At ten thousand sessions a month with 90-day retention, you’re carrying tens of gigabytes of hot-ish data — trivial on S3-compatible storage, noticeable on a VPS disk, and a real reason all four options either require or strongly prefer external object storage.

Retention is also your cheapest tuning knob. Halving retention halves storage and, in my experience, costs you almost nothing — the debugging value of a replay decays fast after the first couple of weeks. Set 30 days, extend only if a compliance or support workflow proves it needs more.

How I’d actually choose

Team of 1–5, no dedicated infra person: Highlight lineage on a single VPS, or skip self-hosting entirely and pay someone’s $19–79/month hosted tier until a compliance requirement forces the issue. The math on your own time is brutal at this size — a self-hosted deployment on a VPS only pays off if you’d otherwise be paying for volume, or if data residency is non-negotiable.

Team of 5–20 with existing Docker infrastructure: Highlight lineage still wins on ops-per-feature, and you get error monitoring and OTLP tracing out of the same deployment, which may let you cancel something else.

Team of 20+ with Kubernetes and a platform owner: OpenReplay becomes competitive, especially if you want its analytics features.

Already on PostHog cloud: stay there. Just don’t self-host it for replay.

Building a replay product: rrweb, and my sympathies.

The meta-advice: weight upgrade pain over install ease. Every tool demos well on day one. The difference between these options shows up at month nine, when there’s a CVE in a dependency and you need to move three major versions without losing your recordings.