Open-source alternative to Datadog RUM and Session Replay

Open-source alternative to Datadog RUM and Session Replay: OpenReplay or PostHog

Self-hosted OpenReplay or PostHog can cover session replay and front-end analytics, with masking applied in the browser before data leaves the user's device. Datadog RUM Measure is listed at $0.15 per 1,000 sessions per month, RUM Investigate at $3 per 1,000 filtered sessions billed annually, and Session Replay as an add-on at $2.50 per 1,000 sessions billed annually, according to Datadog's pricing list. If your bill grows with session volume, or your policy requires recordings to stay in your own infrastructure, both tools are worth a pilot. Each has licensing and support limits you must check before you commit, so treat this section as a shortlist, not a verdict.

The decision starts with licensing. OpenReplay's README says most of its monorepo is AGPLv3, some directories are MIT, and everything under ee/ is under a separate commercial license. PostHog is MIT except for its ee/ directory, and its README says premium features there need a PostHog license on a self-hosted instance. Confirm which features your team needs fall inside the free code paths. On support, PostHog states that self-hosted deployments are officially unsupported, so any production run needs your own operations capacity or a partner. OpenReplay offers a paid Enterprise edition with a custom SLA and dedicated support, and its pricing page lists the terms, so ask for them in writing.

Datadog remains the backend for APM and logs unless you replace those too, so session data and backend traces will sit in two places. Plan how the session ID and trace context will be correlated across both tools, and confirm that your masking rules cover every field that carries personal data. Keep the scope of this section to replay and front-end analytics, and treat APM and log replacement as separate work.

How Datadog RUM and Session Replay capabilities map to open-source options

This table maps each Datadog RUM and Session Replay capability to OpenReplay and PostHog, with notes on where support is documented, partial or needs confirmation in your environment. Read the coverage notes before assuming a one-to-one replacement, because the two platforms differ on mobile replay, cobrowsing and retention. The main takeaway is that both open-source options cover core session replay and product analytics, but several enterprise controls need testing before you retire Datadog.

Datadog capability	OpenReplay	PostHog
RUM Measure (session volume and performance telemetry)	Documented: session replay with DevTools, network activity, console logs, JavaScript errors and more than 40 performance metrics	Partial: product analytics and web analytics are documented, but browser performance coverage must be confirmed against your required metrics
RUM Investigate (filtered session analysis)	Documented: session search and filtering through the replay and DevTools views, confirm filter depth for your attributes	Documented: product analytics with funnels, trends and session-level investigation, confirm query needs for your team
Session Replay	Documented: web session replay with capture-time masking by CSS selector, input redaction and a private mode that masks all text and inputs by default	Documented: session replay is a listed product, confirm masking rules and sampling settings in your own deployment
Mobile replay	Documented: native replay for iOS, Android and React Native, confirm SDK coverage for your app framework and OS versions	Confirm: mobile capabilities are not described in the supplied material, test with your own mobile app before committing
Cobrowsing and live assistance	Documented: cobrowsing with WebRTC calls, confirm network and TURN requirements for your users	Confirm: no cobrowsing capability is documented in the supplied material
JavaScript error tracking	Documented: JavaScript errors are captured alongside session replay, confirm alerting and grouping against your Datadog error workflow	Partial: error tracking is listed as a product, confirm grouping, source map handling and alerting in your environment
Retention and data residency	Documented: self-hosting keeps session data in your infrastructure with self-managed retention in the community edition, confirm retention settings and backup	Partial: self-hosted retention depends on your configuration, cloud plans list 1-year and 7-year retention, confirm how your self-hosted storage is sized and purged
Support and operations	Confirm: community support in the open-source edition, SLA and dedicated support sit in the paid Enterprise edition, confirm which support model fits your risk	Confirm: PostHog states self-hosted deployments are officially unsupported, so plan internal or partner support before production use

Open-source session replay options: OpenReplay and PostHog compared

Both OpenReplay and PostHog can record sessions on infrastructure you control, but they differ in licensing, self-hosting support and scope. The cards below set out the fit, licensing split, footprint and main trade-off of each, plus the free PostHog hobby deployment and its limits.

OpenReplay for session replay

OpenReplay is the option built around session replay first, with DevTools-style capture, console logs, JavaScript errors and performance metrics alongside recordings. Its core is AGPLv3, while everything under the ee/ directory is a separate commercial license, so check which features you need against that boundary. Confirm whether your required features sit in the open core or in the Enterprise Edition before you plan the deployment.

PostHog as a broader product suite

PostHog combines session replay with product analytics, feature flags, surveys and error tracking in one product. Its core is MIT, but the ee/ directory is covered by a separate license, and premium features there need a PostHog license on a self-hosted instance. If you want fully free code, confirm whether the posthog-foss repository covers the features you rely on.

OpenReplay self-hosting footprint

OpenReplay's documentation states that a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start self-hosting, with Docker, Kubernetes with Helm and several major clouds as targets. Recordings grow with traffic, so size storage and retention against your session volume before committing. Ask whether your team will run upgrades and backups in-house, since community support is the default.

PostHog hobby deployment and scale limits

PostHog provides a free Docker Compose hobby deployment under MIT, installed with a deploy-hobby script. It recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. The README says open-source deployments should scale to approximately 100k events per month, and recommends PostHog Cloud above that, so plan for a managed move as traffic grows.

PostHog self-hosting is unsupported

PostHog states that self-hosted deployments are officially unsupported, and it does not offer customer support for product, infrastructure or other questions on self-hosted instances. Kubernetes deployments of its paid self-hosted product are no longer supported for new installs. Budget for internal or partner support for upgrades, incidents and security patching, and confirm the current support position with PostHog before you rely on it.

Keeping session data in your infrastructure

Both products can keep recordings inside your own network, which matters when session data includes personal information. OpenReplay's documentation notes that first-party tracking from your own domain is not blocked by ad blockers, and its capture-time masking, CSS selector masking and private mode run in the browser before data reaches the server. Test masking on your real forms and pages before enabling broad recording.

How to mask personal data before session data leaves the browser

Masking has to happen at capture time, inside the browser, before any session data is sent to a server. Once a keystroke, form value or network payload has left the page, no later redaction setting on the backend can recover it from the storage tier, so the control belongs in the recorder configuration itself. OpenReplay's documented sanitization works this way: it masks or skips data before it reaches the server, and it offers three levers you can combine. Masking by CSS selector hides the elements you name, input redaction covers form fields, and a private mode masks all text and inputs by default, which is the safer starting point if you cannot yet list every sensitive element. Confirm the exact configuration keys and default behavior for your OpenReplay version in the OpenReplay documentation before you rely on them.

Test the configuration on the pages where personal data is most likely to appear: registration, checkout, payment, password reset and sign-in flows. Replay a sample session of each, then check what the recorder actually stored. Review the captured network requests for request and response bodies containing names, addresses, account identifiers or tokens, and review console logs for values printed by application code. Session data often leaks through these channels even when the visible page is masked, so treat them as separate test cases. Repeat the check after every release of your front end, because a new form field or debug log line can bypass a selector that worked last month. Record each test, its date, the build tested and the result.

Document the masking configuration as control evidence for your privacy team: the selectors and input rules in use, the private mode setting, the sanitization tests and their results, who approves changes, and how changes are reviewed. Keep this record alongside your data inventory for session replay. Masking reduces the risk of exposing personal data, but it does not replace a data protection assessment, and it does not decide whether recording a given flow is lawful or proportionate. Ask your privacy and legal teams to assess the purposes, retention period and access rights for session data, and to confirm whether consent or notice is needed in each market where you operate.

Running self-hosted session replay alongside Datadog APM and logs

Many teams move only session replay and leave Datadog APM and log management untouched for the first phase. In this setup, the browser keeps its existing Datadog RUM or tracing configuration for backend correlation, while OpenReplay or PostHog records sessions in your own infrastructure. The two systems run side by side and do not exchange data unless you add a shared key, so the main task is deciding which identifiers the replay tool needs to carry.

Scope the change: Limit the new tracker to replay and product events, and confirm that the Datadog SDK still loads and sends its own RUM and trace data on the same pages.
Choose a shared identifier: Generate a session or user identifier in the front end and store it in a first-party cookie or local storage value that both SDKs can read, such as a value named session_ref.
Log the identifier server side: Add that value to backend request logs in Datadog so a support engineer can search from a replay session to the matching log lines.
Note what does not correlate: Replay timelines will not appear inside Datadog traces, and Datadog APM spans will not play back in OpenReplay or PostHog without an export step.
Keep masking consistent: Apply the same selectors for sensitive fields in both trackers so personal data is not captured twice under different rules.

Before cutover, confirm with your own security and privacy owners which fields the replay tool masks at capture and which fields Datadog still receives.

Linking a replay session to a backend trace is the step that gives engineers the most value, and it is also the step with the most configuration. The browser must send a trace context header on API calls, the backend must accept and record it, and the replay tool must store the same identifier with each session. Without these three pieces, support staff can only search by user or time window, which is slower and less precise.

Propagate trace context: Configure the front end to add a W3C traceparent header to API requests, and confirm that the load balancer and gateways forward it unchanged.
Record the trace identifier in replay: Attach the trace ID as a custom property on the session or on error events, so the replay tool can show it on the session page.
Write the trace ID into backend logs: Include the trace ID in structured logs, which lets Datadog log search return the same request that the replay shows.
Expect gaps for third-party calls: Requests to services that do not propagate context, and requests made before the tracker initializes, will not link automatically.
Mind sampling: If Datadog samples traces, a replay session may point to a trace that was never stored, so confirm the sampling policy before relying on the link.

Confirm with your APM owners that trace IDs remain stable through your gateway and that retention periods in each tool cover the investigation window you need.

Moving session replay, consent and users to a self-hosted platform

This sequence moves Datadog RUM and Session Replay to a self-hosted OpenReplay or PostHog deployment in a controlled order, so that masking, retention and data location are verified before production traffic moves. The result is a production SDK pointing at your own infrastructure and a documented record of what history was kept.

Inventory Datadog RUM applications and sampling
The owner of the Datadog RUM setup, usually a frontend platform or product analytics lead, lists every RUM application, its web and mobile properties, environments, session sampling rates, Session Replay settings and any tracked user identifiers. Include the Session Replay add-on and the RUM Measure and RUM Investigate features, since each is billed separately in Datadog's pricing list. Check the inventory against the live SDK configuration in each application, not only against documentation. The step is done when the team has a signed-off table of applications, sampling values and privacy settings that can be reproduced in the new platform.
Decide which session history to keep
The data owner, with legal or privacy input, decides which session recordings, error events, performance metrics and user records must be kept after cutover and for how long. Confirm with Datadog which export options exist for RUM and Session Replay data, because session history may not be fully portable and bulk export may cover only some data types. Record each decision as a retention rule, and mark any history that will be left in Datadog until its own retention expires. The step is done when the retention decision and export confirmation are written down and approved.
Deploy the chosen platform in a test environment
The platform team chooses OpenReplay or PostHog based on the feature need, such as DevTools, cobrowsing or mobile replay on one side and feature flags or product analytics on the other. They deploy it in a non-production environment inside their own infrastructure, using the documented deployment path for their hosting model, and review the sizing guidance in the vendor documentation before choosing a server. Plan for the open-source edition's community-only support and confirm how upgrades and backups will be run. The step is done when the platform loads, accepts test sessions and shows them in the interface.
Configure masking rules on a staging site
The frontend team instruments a staging copy of the site with the new SDK and applies capture-time masking before any data leaves the browser. They mask sensitive fields by CSS selector, redact inputs, and test whether a private or mask-all mode is needed for pages with personal or financial data. They also check that masking runs before the first network request, not after. The step is done when a test session on each sensitive page shows that masked values never appear in the recording, the captured network data or the console logs.
Run both tools in parallel
The team adds the new SDK to the staging site and, for a limited period, keeps the Datadog RUM SDK running so that both tools record the same user journeys. They compare session counts, error events, performance metrics and replay availability, and document any differences that come from sampling or from the SDKs themselves. Because the two products are configured separately, expect some metrics to differ and record the reason for each difference. The step is done when the team can explain every material gap between the two tools.
Validate masking and retention
The privacy and security reviewers test a sample of recordings against the masking rules and check that the retention settings on the self-hosted platform match the decision from step two. They confirm that the platform stores data in the intended storage location, that access is limited to approved users, and that the data is not sent to any third-party domain. Keep the test results as evidence for internal audit or compliance reviews. The step is done when the reviewers sign off on the masking test results, the retention settings and the storage location.
Cut over the production SDK
The frontend team deploys the new SDK to production in a staged rollout, with a rollback plan that restores the Datadog RUM configuration. They serve the SDK from the organization's own domain where possible, so that first-party tracking is not blocked by ad blockers, and confirm the ingestion endpoint is the self-hosted instance. Monitor ingestion and error rates after each stage. The step is done when production sessions appear in the self-hosted platform and no production page loads the Datadog RUM SDK.
Retire the Datadog RUM configuration
After the agreed monitoring period, the team removes the Datadog RUM and Session Replay configuration from every application, revokes the client tokens, and cancels or reduces the related Datadog add-ons once billing confirms no further usage. They archive the inventory, retention decision and validation records, and document which historical data remains in Datadog and when it expires. The step is done when the Datadog RUM configuration is removed from code and the decommissioning record is filed with the owner.

What drives the cost of self-hosting session replay

Self-hosting session replay swaps a per-session bill for a set of infrastructure and staff costs, and the Datadog side of the comparison is set by its published list. The Datadog pricing list shows RUM Measure at $0.15 per 1,000 sessions per month, RUM Investigate at $3 per 1,000 filtered sessions billed annually, and Session Replay as an add-on at $2.50 per 1,000 sessions billed annually. Those rates are the only Datadog figures to model against, so build your current bill from your actual session counts and which tiers you use, then compare it with the components below. Confirm current rates on the Datadog pricing list before you rely on them.

The main self-hosted cost is the server. OpenReplay's README says a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start, while PostHog's self-host documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage for its hobby deployment. Storage and retention drive growth fastest: replay data is large, so set a retention period per project and size disks for it. Recurring costs also include backups of the database and object storage, version upgrades, certificate and domain management, and monitoring of the stack itself. Staff time is usually the largest recurring item, so estimate the hours your team will spend on upgrades and incidents, and check which of those tasks you would pay a partner to perform.

Several costs are one-time: initial deployment, sizing tests, masking rules and the browser snippet rollout to your sites, and the dual-running period while Datadog RUM and the new tool both collect sessions. Ask any implementation partner for a written scope covering deployment, masking configuration review, backup and restore testing, upgrade procedures and handover, plus a separate line for ongoing support. Ask whether support is included, what the paid tier adds (OpenReplay's pricing page lists SSO, SCIM and an audit trail under its Enterprise edition at custom pricing, and PostHog says self-hosted deployments are officially unsupported), and what you pay for each option. Confirm the server and storage assumptions against your expected session volume before accepting any quote.

How much effort does replacing Datadog RUM and Session Replay take?

What drives the cost of replacing Datadog RUM and Session Replay?

The main drivers are session volume, how much of the Datadog RUM feature set your teams actually use, how many applications and mobile apps you instrument, and where the platform will run. Datadog bills RUM Measure at $0.15 per 1,000 sessions per month, RUM Investigate at $3 per 1,000 filtered sessions billed annually, and Session Replay as an add-on at $2.50 per 1,000 sessions billed annually, according to Datadog's pricing list, so the replaced cost depends on how many sessions you record and how many you filter for investigation. On the open-source side, the software is free, but you pay for compute, storage, backups, engineering time to instrument and tune, and any support contract you choose. Ask for a quote that separates one-time setup from recurring infrastructure and support.

How long does a Datadog RUM replacement take?

Duration depends on scope: the number of front-end applications, whether native mobile replay is needed, how many custom events and dashboards must be rebuilt, and whether you run a parallel period before cutover. Self-hosting OpenReplay can start from a single virtual machine with 2 vCPUs, 8 GB of RAM and 50 GB of storage, according to OpenReplay's README, but that sizing is a starting point and not a production plan. PostHog's self-host documentation recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage. Agree a timeline in writing against a defined scope rather than relying on a generic estimate.

Can an internal team replace Datadog RUM alone?

A team with frontend, platform and security skills can often do it, provided it has time to deploy, tune and maintain the platform. The work includes standing up the server, configuring storage and retention, adding the tracking snippet or SDK to each application, setting masking rules, and validating that replay and analytics match what teams used in Datadog. Confirm whether your engineers have capacity for ongoing patching and upgrades, because that work recurs after the migration. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure, and can support the work through a fixed-scope engagement or a retainer.

What does the engineering team need to provide?

Expect to provide access to your cloud account or data center, the list of applications and domains to instrument, and named owners who can approve masking rules and retention policy. Frontend engineers need time to add the tracking code and test sessions in staging, and security or privacy staff should review which selectors and inputs are masked before data leaves the browser. OpenReplay describes capture-time sanitization that masks or skips data before it reaches the server, including masking by CSS selector and input redaction, and a private mode that masks all text and inputs by default. Confirm these controls against your own data classification before rollout.

Is self-hosted PostHog supported for session replay?

Self-hosted PostHog is officially unsupported, and PostHog does not offer customer support for product, infrastructure or other questions on self-hosted instances, according to its self-host documentation. The free Docker Compose hobby deployment is MIT licensed and installed with a deploy-hobby script, and PostHog's README says open-source deployments should scale to approximately 100k events per month before moving to PostHog Cloud. New Kubernetes deployments of its paid self-hosted product are no longer supported. If you need supported self-hosting, confirm this with the vendor or consider OpenReplay's self-hosted edition, and ask DeployOpen to scope the operational support you need.

What does the license mean for commercial use of enterprise directories?

The licenses differ by project and by directory, so review each one before you deploy. PostHog's repository is MIT except for the ee/ directory, which is covered by a separate license in ee/LICENSE, and its README says premium features from ee on a self-hosted instance require a PostHog license. For a fully free option, PostHog points teams to the posthog-foss repository, which is purged of proprietary code and features. OpenReplay's monorepo is mostly AGPLv3 with some MIT directories, and everything under ee/ is under a separate commercial license defined in ee/LICENSE. Have your legal team confirm the terms that apply to your intended use, including internal use and any customer-facing use.

How does DeployOpen scope a session replay migration?

DeployOpen scopes the work in writing before it starts. The scope usually covers which applications and mobile apps are in play, the target platform and hosting environment, the masking and retention rules, the integration points with your existing tools, the migration and parallel-run plan, and the documentation and handover. Most engagements are fixed-scope, with deliverables and timelines agreed in advance, and ongoing upgrades or testing can be added as a retainer. DeployOpen does not publish a price list, so ask for a quote that follows from the written scope, and confirm which items are one-time and which recur.

How DeployOpen scopes, delivers and supports session replay replacement

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For session replay, that means turning a per-session billing model into a self-hosted OpenReplay or PostHog deployment where recordings, masking rules and retention stay under your control.

How we scope

Inventory which Datadog RUM, Session Replay and product analytics features your teams actually use before choosing OpenReplay or PostHog.
Agree in writing which pages, applications, mobile apps and masking rules are in the engagement, with deliverables and timelines fixed before work starts.
Confirm the hosting target, retention period and traffic volume with your team, then request a written quote that follows from that scope. Ongoing support is available as a retainer.

How we build

Deploy the chosen platform in your infrastructure, sized against the published minimum requirements and confirmed against your expected session volume.
Configure capture-time masking by CSS selector and input redaction, and test that personal data is removed in the browser before any session reaches the server.
Integrate the tracker into your first-party domain, then test recording, console logs, network activity and error capture across the applications in scope.

How we hand over

Document the deployment, masking configuration, retention settings, backup routines and upgrade steps so your own team can operate the platform.
Provide the evidence and control records your auditors or privacy reviewers will ask for, without issuing any audit report or certification ourselves.
Run a parallel period with Datadog where needed, then agree a written cutover plan and decommission steps for the old RUM and replay configuration.

How we support

Support covers upgrades, security patching, backups and restore testing for the self-hosted platform, scoped in a retainer agreed in writing.
Security testing of the tracker, the ingest endpoint and the stored recordings can be added to a retainer or a separate fixed-scope engagement.
Confirm with the vendor which community or paid support channels apply to your chosen edition, since self-hosted community editions carry no vendor support.

Open-source alternative to Datadog RUM and Session Replay