OpenReplay

Last reviewed Aug 26, 2026 · 824 words

The listed minimum of 4 GB is the floor, and the project's own installer wants more: OpenReplay's recommended self-hosted install is a single VM running k3s, and at last check the docs asked for roughly 2 vCPUs, 8 GB of RAM and 50 GB of disk before calling the box adequate. That is the price of a full session-replay suite (recordings, network and console capture, error tracking, performance metrics, live co-browsing) with the data on your own server instead of FullStory's. It is worth paying for a product team; it is not worth paying for a blog, and no other tool in the analytics category is as easy to over-install.

What replay gives you that pageview analytics cannot

Plausible tells you 40 percent of visitors left the checkout page. OpenReplay shows you the 12 seconds where one of them clicked the disabled button 5 times, the console error that fired, the 504 from your API in the network tab, and the rage-click heatmap across every session that hit the same bug. It is a debugging tool wearing an analytics badge: sessions are searchable by user ID, error, URL, country, device and custom events, and each replay reproduces DOM changes from a recording rather than video, so a 10-minute session is a few hundred KB. The Assist feature lets a support agent watch a live session and, with consent, take control, which for a small SaaS replaces a screen-sharing tool.

On the client side it is a snippet from the dashboard or the @openreplay/tracker npm package with a project key, and one call to identify users after login so sessions carry a name rather than an anonymous ID.

The install is Kubernetes in a trench coat

The supported path is a shell script that installs k3s on a clean Ubuntu VM and deploys OpenReplay's chart into it: Postgres, ClickHouse, Redis, MinIO for recordings, and a dozen services in front. It works and it is genuinely one command, but you now operate a Kubernetes node, and the upgrade path, log locations and resource tuning are all Kubernetes-shaped. There is a Docker Compose variant in the repository that the project treats as second-tier, and I have run it for a low-traffic app without incident; if you already have a cluster, the Helm chart is the natural fit. Either way "Hard" is the right difficulty label, and it is hard in the operational sense rather than the setup sense. Resizing the box after the fact is painful, so start at 8 GB.

Recording people carries legal weight, so mask first

A session recording is personal data under the GDPR and similar laws, and it can accidentally include passwords, card numbers and health details typed into your forms. OpenReplay's tracker obscures input values by default and lets you raise the sanitisation level up to hiding all text; add its data attributes to sensitive elements so they are masked or dropped at capture time, on the visitor's machine, before anything is sent. Do that on day one and put replay in your privacy notice. Self-hosting solves the "who else sees this" problem, not the "should we have this" one, and consent rules for replay are stricter than for cookieless counters.

Storage grows with sessions, not visitors

Recordings live in MinIO (or S3 if you point it there) and retention is the main cost lever: as a rough estimate, 90 days of a 20,000-session-a-month app is tens of GB, and 2 years is a disk you need to plan for. ClickHouse holds the events and needs the memory. Set retention in the admin settings before the first week ends, and put the recordings bucket on storage you can grow, not the root disk.

When a lighter tool is enough

If the question is "how many people, from where, which pages", Umami answers it on a fraction of the resources. If you want product analytics with funnels and journeys but no DOM recordings, Rybbit or PostHog sit in the middle, and PostHog also does replay if you eventually want it in the same tool. OpenReplay wins on the depth of the replay itself (DevTools-grade network and console data) and on being Apache-2.0 with the full feature set self-hosted, roughly 12,600 stars' worth of trust.

What I'd do

For an app with paying users and a support inbox: OpenReplay on its own 8 GB VM via the k3s installer, recordings on S3-compatible storage with 90-day retention, masking configured before the tracker goes live, identify calls after login, and Assist turned on for support. For anything without a support inbox, do not install it; pair Umami with an error tracker like GlitchTip and you have 80 percent of the value for 10 percent of the RAM.