# OpenReplay: self-hosted session replay with a developer debugger attached

> OpenReplay records what users do and what the browser was doing underneath. This review covers its tracker, its self-hosted deployment path, and where the monorepo licensing gets awkward.

**openreplay/openreplay** — Session replay, cobrowsing and product analytics you can self-host. Best for reproducing issues and iterating on your product.

- Repository: https://github.com/openreplay/openreplay
- Website: https://openreplay.com
- Stars: 12,910 · Forks: 854
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/openreplay-openreplay

## The problem OpenReplay solves: bugs you cannot reproduce from a stack trace

A JavaScript error report tells you a function threw. It does not tell you that the user had 40 pending network requests, that the Redux store was in a half-hydrated state, and that the CPU was pinned while they clicked. OpenReplay's pitch is that it captures both layers at once. The README describes a session replay that "shows you what went under the hood", listing network activity, console logs, JS errors, store actions and state, page speed metrics, and CPU and memory usage.

The target reader is a frontend or full-stack engineer at a company with a compliance reason to keep user data in its own cloud. The README states the self-hosted angle plainly: no third-party processing of user data, everything stays in your cloud. That is the deciding factor for teams in healthcare, finance, or any organisation whose legal review rejects a SaaS recorder. If you have no such constraint, the operational cost below is hard to justify.

## Tracker, backend, player: what the monorepo actually contains

The repository is a monorepo, and the top-level directories map closely to the runtime data flow. The browser side is snippet/ and tracker/. The README puts the tracker at roughly 26KB in Brotli form and says it sends minimal data asynchronously. Captured events travel to backend/ and api/, with networkProxy/ in the path for proxied traffic. Replay rendering lives in player/, and the live cobrowsing feature is split across assist/, assist-server/ and assist-stats/. Source map handling, which is what turns a minified stack trace back into readable code, is handled by sourcemap-uploader/ and sourcemapreader/. There is also spot/ for the Chrome bug-recording extension, mobs/ and ee/ for other components, and mcp_app/ for the MCP topic that appears in search data.

The interesting design choice is that replay is not a video. The tracker ships a stream of events and state, and the player reconstructs the session. That is why the DevTools view can show store actions and network activity alongside the visual replay rather than as a separate tab. It also means replay fidelity depends on what the tracker could observe, not on a pixel-perfect recording. The README does not document how the player handles DOM mutations it did not capture, and that gap is worth knowing about before you promise a designer frame-accurate playback.

## Installing OpenReplay: cloud deployment guides, not a single container

The README does not give a one-line install. It points at step-by-step deployment guides for AWS, Google Cloud, Azure, DigitalOcean, Scaleway, OVHcloud and Kubernetes, all under docs.openreplay.com. That is the honest shape of this project: you are deploying a set of services, not running a binary. The docker-related searches around this project reflect that people look for a container path, and the deployment guides are where the README sends them.

The self-hosted route therefore starts with a cloud account and a supported target, not with a package manager. If you are evaluating quickly, the README's other option is the hosted service at app.openreplay.com, which the project offers as a free account. That is the fastest way to see the player and DevTools before you commit engineering time to a self-hosted install.

On the application side, the integration is a snippet. The repository's snippet/ directory holds it, and the tracker package is what the search data refers to as Openreplay/tracker. The README does not print the snippet inline, so treat the documentation site as the source of truth for the exact embed code and for the framework-specific packages covering React, Vue, Angular, Svelte, Next.js, React Native and iOS, which appear in the repository topics.

## Privacy controls are the strongest argument, and the least specified

The README's privacy section is short and confident: fine-grained controls let you choose what to capture, what to obscure, and what to ignore, so that user data "doesn't even reach your servers". That last clause is the meaningful one. Client-side scrubbing before transmission is a stronger guarantee than server-side redaction after the fact, and it is the feature that makes a self-hosted replay tool defensible in a security review.

What the README does not do is enumerate the controls. It does not list the configuration keys, the default capture behaviour, or whether masking is opt-in or opt-out per element. Those details live in the documentation, not in this repository's front page. Before you rely on the privacy story, read the docs for the specific capture and masking options and confirm the defaults match your policy. A tool that captures console logs and network payloads by default has a wider blast radius than one that captures DOM only, and the README does not state which categories are on out of the box.

## Where OpenReplay is the wrong tool

The deployment model is the first limitation. Self-hosting means operating a multi-service stack, and the README offers no sizing guidance, no resource requirements, and no rollback procedure. Teams without someone who owns infrastructure will spend more time on the deployment than on the bugs they wanted to fix.

The second limitation is licensing clarity. The repository's own README says the monorepo "uses several licenses" and defers to the LICENSE file, and the repository metadata reports the licence as NOASSERTION. There is a third-party.md at the top level as well. For a company that needs a clean legal position, that means reading per-directory terms rather than trusting a single SPDX identifier. This is not a reason to avoid the project, but it is a reason not to assume it is uniformly permissive.

The third case is scope. If you only want aggregate product metrics and funnels, a replay suite is a heavy instrument. The README does list analytics for surfacing conversion and revenue problems, but the centre of gravity here is individual session forensics. Teams that never watch a single session are paying the operational cost of a recorder for a dashboard.

## OpenReplay compared with Sentry and PostHog

The comparison that matters most is with Sentry, because the search data shows people asking about it directly. Sentry is an error and performance monitoring platform: it aggregates exceptions, groups them, and tracks regressions. OpenReplay starts from the session. The README's claim is context, not just the exception: network activity, JS errors, store state and 40+ metrics in one DevTools view. Sentry tells you an error happened a thousand times; OpenReplay is built to show you one occurrence in full. The two are complementary, and the README's integrations section supports that reading, listing Sentry alongside Datadog, CloudWatch, Stackdriver and Elastic for syncing backend logs with replays.

The other comparison is PostHog, which also appears in the search data. PostHog is a product analytics platform that added replay; OpenReplay is a replay platform that added analytics. That ordering shows up in the architecture: this repository carries a dedicated player, an assist stack for live cobrowsing over WebRTC, and source map tooling, which is a different investment profile from an analytics-first product. If your primary question is "which funnel step loses users", PostHog's framing fits better. If it is "what exactly happened in this user's browser", OpenReplay's does.

## Maintenance, upgrades and what the release cadence tells you

The repository is not archived, and the last push was on 2026-09-21. The recent release tags are v1.25.0 (2026-01-30), v1.26.0 (2026-02-28) and v1.27.0 (2026-05-05). The README and repository layout give no upgrade procedure, no migration notes between those versions, and no statement about backward compatibility for the tracker or the backend schema. For a self-hosted deployment that stores session data, the absence of documented migration steps is the practical risk: you should check the release notes for each version you cross rather than upgrading in place on faith.

There is a renovate.json at the top level, which indicates dependency updates are automated, and a lefthook.yml plus .pre-commit-config.yaml for local checks. Those are signals about repository hygiene, not about upgrade safety for your deployment. On licensing, the README's pointer to LICENSE and the presence of third-party.md mean the terms are per-component. That is a fact to verify with your own legal review, not something this article can settle.

If you want to contribute, the README points at open issues, preferably those marked as good first issues, and at CONTRIBUTING.md.

## Conclusion

Adopt OpenReplay if you need session replay that never leaves your own cloud and you have someone who can run a multi-service deployment on AWS, GCP, Azure, DigitalOcean, Scaleway, OVHcloud or Kubernetes. Do not adopt it if you want a single binary, a managed free tier with no operational work, or a clearly unified licence. Verify two things before committing: the per-directory licence terms in LICENSE and third-party.md, and whether the deployment guide for your target cloud matches the component list in this monorepo.

## FAQ

### Is OpenReplay free?

The README describes OpenReplay as an open-source suite you can host yourself, and separately offers a free account on the hosted cloud service at app.openreplay.com. The repository does not state pricing for the cloud offering.

### What is the main purpose of session replay?

For OpenReplay, the README frames it as troubleshooting: replaying what users do while also showing what happened underneath, including network activity, console logs, JS errors, store actions and state, and page speed metrics. The README also lists analytics for surfacing conversion and revenue problems.

### How do I use OpenReplay?

The README does not print the embed snippet inline. The repository has a snippet/ directory and a tracker/, and the README sends readers to the documentation site for deployment and setup details.

### What is OpenReplay?

It is an open-source session replay suite you can host yourself, which replays what users do on a web app and also shows what happened underneath: network activity, console logs, JS errors, store actions and state, page speed metrics, and CPU and memory usage.

### Is OpenReplay safe to use with user data?

The README states that fine-grained privacy controls let you choose what to capture, obscure or ignore so user data does not reach your servers, and that self-hosting keeps captured data in your own cloud. The README does not list the individual capture and masking options, so check the documentation for the defaults.

## Sources

- [Issues](https://github.com/openreplay/openreplay/issues)
- [openreplay/openreplay on GitHub](https://github.com/openreplay/openreplay)
- [Project website](https://openreplay.com)
- [README](https://github.com/openreplay/openreplay/blob/main/README.md)
- [Releases](https://github.com/openreplay/openreplay/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openreplay-openreplay