Self-Hosted Session Replay: Architecture, Costs, and When It Makes Sense

Self-hosted session replay means operating the full production pipeline: capture in the browser, durable ingest, storage, indexing, privacy controls, retention and deletion, replay serving, monitoring, and incident response. A proof of concept can demonstrate the data path with a few components. A dependable service adds an operating model around them. This guide separates those scopes so teams can compare self-hosting with rrweb Cloud and other managed options using total ownership.

What does a self-hosted architecture look like?#

The reference data path has four visible components. The recorder runs in your users' browsers (rrweb, configured with masking on). An ingest service authenticates, validates, retries, rate-limits, and durably accepts event batches. Object storage holds each session's event stream, while a metadata index supports listing, search, tenancy, retention, and deletion. A player service authorizes access, loads the right batches, and hands them to rrweb-player.

That architecture demonstrates the data flow. A production product adds idempotency and deduplication, backpressure, multi-tenant authorization, PII controls, retention enforcement, complete deletion across indexes and backups, observability, migrations, fidelity testing, support tooling, and on-call ownership. The open source session replay guide explains the available operating models, while rrweb Cloud provides a path where the rrweb team operates those layers.

What does self-hosting cost?#

Raw object storage is usually inexpensive and represents one part of total cost. A compressed web session can range from tens to hundreds of kilobytes depending on page complexity and length. That estimate helps size a bucket. A complete budget also includes request costs, indexes, backups, data transfer, observability, security tooling, and the people operating the system.

Ingest can scale horizontally and needs the same reliability discipline as other product-critical services. Durable acceptance, retries, and backpressure protect session data during load or service interruptions. Replay serving also needs authorization, predictable latency, and safeguards for unusually large or malformed recordings. These requirements add engineering work even when the underlying compute bill is modest.

Engineering and operations are usually the largest parts of total cost. Initial work includes pipeline design, secure tenancy, consent and masking, indexing, retention, deletion, observability, deployment, and recovery procedures. Ongoing ownership includes dependency and schema migrations, capacity planning, incident response, privacy requests, and replay-fidelity checks after frontend changes. The effort varies by product and compliance posture and should be budgeted as production infrastructure. rrweb Cloud pricing is the direct managed comparison because it converts those responsibilities into a service operated by the rrweb maintainers.

When does self-hosting make sense?#

Three common requirements make self-hosting a strong fit.

Compliance and data control. When data residency requirements or internal policy require recordings to remain in infrastructure your team operates, self-hosting provides direct control. Your compliance program then covers consent, masking, access control, retention, deletion, monitoring, documentation, and incident handling in that environment.

Volume economics. Hosted replay plans scale with usage, while infrastructure scales with storage and compute. The right model depends on your volume and operating preferences; teams recording millions of sessions monthly may find self-hosting especially attractive. Do the math above against your actual requirements and the plans available to you.

Replay as a product feature. If recordings appear inside your product, the open rrweb recorder and player provide an embeddable foundation. You can operate the backend yourself, or use rrweb Cloud's ingest, storage, indexing, APIs, and replay infrastructure while keeping your own product experience. The build vs buy guide compares those ownership models.

When is managed hosting the better fit?#

Managed hosting is a strong fit when a team wants to focus its engineering capacity on the replay experience instead of the data platform. rrweb Cloud keeps the recorder open and portable while the rrweb team operates ingest, storage, indexing, deduplication, PII filtering, APIs, and replay serving. Your engineers can build replay into your own product while our team owns the storage pipeline, privacy operations, monitoring, and on-call response. Compare that managed cost with the loaded engineering and operational cost in the build vs buy framework.

What operational considerations matter?#

Ingest availability matters immediately, so retries, idempotency, backpressure, rate limits, and deduplication need deliberate designs. Checkout configuration affects seeking, storage, and recovery. Authorization must cover tenants and every replay URL. Deletion workflows should cover objects, indexes, caches, derived data, and backup policy while leaving an audit trail. Automated samples and release checks help teams monitor replay fidelity after frontend changes. Every component also needs metrics, alerts, runbooks, migrations, and a clear owner.

Summary#

1. A four-part data path demonstrates replay; production adds reliability, privacy, tenancy, lifecycle controls, and operations around it.
2. Object storage is often inexpensive; engineering and ongoing operations dominate self-hosted total cost.
3. Self-host when operating this infrastructure is a deliberate requirement or strategic capability.
4. rrweb Cloud keeps capture open while the rrweb maintainers operate the production backend.
5. Plan for durable ingest, authorization, retention, complete deletion, observability, migrations, and fidelity testing.

FAQ#

What does it cost to self-host session replay?#

Object storage can be inexpensive and is one part of total cost. Self-hosting also requires durable ingest, indexing, secure tenancy, privacy controls, retention, deletion, observability, migrations, support, and on-call ownership. Engineering and operations normally outweigh the raw storage bill.

When does self-hosting session replay make sense?#

Three cases: compliance requirements around data residency, session volume where infrastructure economics are attractive, and embedding replay into your own product. For other teams, a managed service is an excellent way to preserve engineering time while getting to production quickly.

Do I need Kubernetes to self-host session replay?#

A proof of concept can run without Kubernetes. A production deployment still needs redundancy, durable queues or retry behavior, secure tenancy, monitoring, recovery procedures, and controlled rollouts. Kubernetes is one way to operate those concerns, and teams can meet the same responsibilities with other deployment platforms.

Is self-hosted session replay GDPR compliant by default?#

Compliance depends on how the system is configured and operated. Self-hosting can simplify vendor and transfer analysis while giving your team responsibility for the lawful basis, capture-time masking, retention limits, deletion capability, documentation, and monitoring.