Self-Hosted Session Replay: Benefits, Costs, and Operational Tradeoffs

Build the complete replay architecture

A production replay service includes:

1. Browser recorder: initial snapshot, incremental changes, selected interactions, masking, blocking, sampling, and batching.
2. Ingestion API: project-scoped credentials, authentication, validation, rate limits, abuse protection, and size limits.
3. Durable delivery: queue or stream, retries, deduplication, backpressure, dead-letter handling, and regional routing.
4. Recording store: compressed chunks in object storage with lifecycle, encryption, versioning, and deletion controls.
5. Metadata and search: Visit, Company, User, route, time, status, chunk references, and safe derived fields in a database or index.
6. Processing: session assembly, ordering, manifests, quality flags, privacy transformations, and derived metadata.
7. Replay player: authorized manifest loading, chunk delivery, seeking, decompression, missing-chunk handling, and compatibility logic.
8. Governance: least privilege, audit logs, retention, deletion, backups, monitoring, administration, incident response, and upgrades.

Do not store every recording payload as one ordinary relational row. Large mutable blobs create pressure on backups, replication, queries, and deletion. A common pattern is immutable compressed chunks in object storage, a small manifest describing order and versions, and relational/search metadata for discovery and authorization.

Own compatibility and reliable ingestion

A replay format is a long-lived contract. Version the recording envelope with recorder version, schema or event version, player compatibility range, plugin versions, compression codec, privacy-policy version, project, Visit, sequence, timestamps, checksum, and finalization state.

{
  "recording_version": 4,
  "recorder_version": "rrweb-x.y.z",
  "player_min_version": 3,
  "privacy_rule_version": 12,
  "project_id": "project_12",
  "visit_id": "visit_220",
  "sequence": 18,
  "started_at": "2026-08-04T10:15:30Z",
  "codec": "gzip",
  "checksum": "sha256:...",
  "final": false
}

Upgrade recorder and player deliberately. Keep compatibility fixtures from old versions, mutation-heavy pages, masked inputs, plugins, partial sessions, long idle periods, and unsupported elements. Decide how old recordings remain playable: retain a compatible player, migrate data, or publish an explicit playback horizon.

Batching improves efficiency but introduces partial-delivery and ordering questions. Give each batch a stable Visit ID and sequence. Treat retries as potentially duplicated after an ambiguous timeout. Preserve client and server timestamps, but never assume device clocks are correct.

• Use idempotency keys or sequence-aware writes.
• Validate size, project, version, and permitted fields.
• Separate accepted, rejected, retried, duplicate, late, and dropped counts.
• Do not rely on page-close delivery as guaranteed.
• Mark a Visit complete, partial, abandoned, expired, or corrupt explicitly.
• Apply backpressure before queues or databases collapse.
• Load-test retry storms and release spikes, not only average traffic.

A playback can look complete while missing early snapshots, intermediate chunks, or final events. Surface quality flags and gaps to reviewers instead of silently presenting reconstructed continuity.

Estimate storage, requests, and total cost

There is no universal megabytes-per-session number. Size depends on duration, page complexity, mutation frequency, scroll/mouse sampling, canvas and iframe handling, optional console/network data, masking, compression, batch size, and plugins. Measure representative production traffic after privacy rules are applied.

Recorded visits/day = eligible visits/day × sampling rate
Average recording size = recorded duration × measured compressed bytes/time
Daily storage = recorded visits/day × average recording size
Primary retained storage = daily storage × retention days
Effective retained storage = primary storage × retained-copy factor
Monthly ingestion = daily storage × billing days
Peak recorded bytes/second = simultaneous recording users × bytes/user/second
Designed peak throughput = peak recorded bytes/second × headroom factor
Chunks/visit = recorded seconds ÷ target chunk seconds (round up)
New objects/day = recorded visits/day × (chunks/visit + manifests/visit)
Requests/day = recorded visits/day × (batch requests/visit + lifecycle requests/visit)
Monthly reads = replay views/month × objects loaded/replay
Monthly delivery = replay views/month × bytes delivered/replay

For metadata, model a Visit row plus chunk rows and searchable/derived fields, then measure database index, free-space, log, replica, and backup overhead. Object count matters even when bytes are modest because requests, listing, lifecycle, replication, and deletion have costs.

Total cost combines storage, write/read operations, queue, database/index/cache, compute, delivery, backups, monitoring, security tooling, engineering labor, upgrades, privacy testing, deletion, incidents, and support.

Monthly TCO = storage + copies + writes + reads + queue
            + network delivery + database/index/cache
            + compute + observability/security + labor
            + backup/restore + incidents + support

Secure, minimize, retain, and delete replay data

Protect the entire path: TLS, project-scoped collection credentials, authenticated and authorized ingestion, request and resource limits, centralized secrets, private object storage, server-side authorization for every replay view, employee SSO/MFA, least privilege, environment separation, dependency maintenance, and incident response.

Privacy controls belong before storage. Mask or block sensitive fields and rendered content, exclude high-risk routes, normalize URLs, and treat console/network capture as separate high-risk decisions. Minimize identity to stable pseudonymous User and Company IDs where the purpose requires linkage. Test the stored payload and player—not merely SDK configuration.

Make retention and deletion explicit

Retention should vary by purpose, project, route, or capture class where operationally safe. Deletion must remove or make inaccessible:

• recording chunks and manifests;
• metadata rows and search-index entries;
• cache entries and generated clips;
• exports and temporary processing copies;
• User, Company, Visit, and project lookup references;
• replicas, versions, and backups according to the documented backup policy.

Use tombstones or deny lists when immutable backups cannot be altered immediately, prevent restored data from reappearing, and verify deletion through each lookup key. Handle legal/security holds through a separate authorized process.

Self-hosting can provide a chosen data boundary, but it does not automatically provide minimization, lawful collection, access control, deletion, or compliance. Those are design and operating outcomes.

Make search, playback, and reliability observable

Search is part of the product. Index only the metadata required for the stated workflows: project, Visit, time, normalized Page, pseudonymous User and Company IDs, processing state, quality flags, and approved event markers. Every searchable field expands storage, privacy, and deletion work.

For playback, load a small manifest first, fetch chunks on demand, prefetch conservatively, parse/decompress off the main interaction path where possible, support seeking, show missing chunks, set limits for very long Visits, and define how authorized assets are reconstructed. Archived playback may need an explicit restore state.

Set service-level indicators before the pilot and test dependency outage, queue saturation, corrupt chunk, incomplete Visit, lost index, object-store denial, expired asset, old recorder version, deletion failure, and backup restoration.

Compare managed, self-hosted, and hybrid replay

Self-hosting may fit when a hard data-location boundary, custom retention/deletion, deep integration, unusual scale, or replay-as-core-product strategy justifies ownership—and the team already operates queues, object storage, databases, monitoring, security, backups, and on-call.

Managed replay may fit when rapid deployment, polished search/player workflows, browser compatibility work, mobile support, vendor support, and limited internal operations matter more than full infrastructure control. Verify data flows, contract, regional processing, subprocessors, masking, exports, retention, deletion, access, and pricing.

Use hybrid boundaries deliberately

Hybrid options include self-hosted filtering/ingestion with managed processing, customer-controlled storage with a managed UI, managed replay with regional/private networking, recording only selected high-value Visits, or structured analytics internally with short-retention replay elsewhere. Every boundary needs a data contract and incident owner.

Pilot representative routes and privacy rules. Measure p50/p90/p99 recording size, peak ingestion, requests, objects, index growth, search/playback latency, recorder overhead, incomplete-session rate, masking regressions, deletion, restore, upgrade compatibility, incident procedures, and staff time. Assign long-term ownership before launch.

How Hymetry combines analytics and replay

Hymetry links open-source B2B product analytics with Visits so teams can move from Pages and product areas to Companies, Users, and selected session evidence. Shared stable IDs make the analytical and replay paths inspectable without requiring one undifferentiated storage pipeline.

The current open-source deployment still requires teams to review tracker configuration, masking and filtering, authentication, storage, retention, deletion, backups, upgrades, licensing, and operational ownership. Inspect the repository and current terms before adopting it.

Sources

Provider-specific billing, service behavior, and current project support should be rechecked before implementation.