Open-source alternative to New Relic Browser and Session Replay

Open-source alternative to New Relic Browser and Session Replay: the short answer

If your browser monitoring and session replay sit in a hosted New Relic account and count toward your ingest, self-hosted OpenReplay covers session replay, JavaScript errors and performance metrics inside your own infrastructure. Its monorepo is mostly AGPLv3, some directories are MIT, and everything under the ee/ directory is under a separate commercial license, so confirm which edition and license terms apply to the features you plan to use. OpenReplay does not replace New Relic's broader APM, infrastructure or alerting features, and you should map each New Relic browser dashboard and alert to a named replacement before you decide what to retire.

The backend side of a user's journey stays with OpenTelemetry. Front-end sessions are only useful for triage when a request can be traced from the browser into your services, so plan to propagate trace context from the page to your APIs and confirm that your backend traces still reach your chosen store, such as Jaeger or a Grafana stack. OpenTelemetry instrumentation is the bridge that lets the same backend telemetry feed New Relic and a self-hosted system at once during a migration.

Run both in parallel before you cut over. Deploy OpenReplay on a test environment, add it to a limited set of pages, and compare session counts, error grouping and the masking results with what New Relic records for the same flows. Ask your security team to review capture-time sanitization, including CSS selector masking and input redaction, before any production traffic is recorded. Only switch off New Relic browser agents once the masking, retention and trace links have been verified in your own environment.

Which New Relic browser capabilities OpenReplay covers

This table maps the browser monitoring and session replay capabilities teams typically use in New Relic Browser to what OpenReplay documents as features. Read the coverage note in each row before assuming parity, because custom attributes, NRQL-driven dashboards and alert conditions are configured per account and must be checked against your own usage. The main takeaway is that session replay, errors and performance data map well, while the backend trace link and NRQL-based reporting need a deliberate design.

New Relic Browser capability	OpenReplay equivalent	Coverage note
Page views and virtual page views	Session replay and product analytics with funnels, trends and journeys	Confirm that your SPA route names and custom page attributes can be sent and queried the same way in OpenReplay.
AJAX and single-page app timing	More than 40 performance metrics captured in the browser SDK	Confirm each timing you rely on in NRQL is among the documented metrics, and plan a replacement for any that are not.
JavaScript errors	JavaScript errors captured alongside session replay	Check how stack traces are grouped and whether source maps are needed for minified production code in your build.
Session traces and replay	Session replay with DevTools, network activity and console logs	Replay is the closest match. Verify retention limits and sampling in your self-hosted configuration before cutover.
Custom attributes and events	Custom event tracking through the OpenReplay tracker API	Confirm the event names and payload fields used by your dashboards and alerts, since these must be rebuilt by hand.
Masking of sensitive fields	Capture-time masking by CSS selector, input redaction and a private mode	Test masking on your real forms and pages before enabling recording, and document the rules for your privacy review.
Browser to backend trace correlation	Requires your own OpenTelemetry instrumentation and a tracing backend such as Jaeger	Confirm how trace IDs are passed from the front end to APIs in your stack, because this link is not a one-click feature.
Mobile and cross-platform replay	Native mobile replay for iOS, Android and React Native	Only relevant if you monitor mobile apps. Confirm the SDK version and platform support for your app.

Self-hosted options for browser monitoring and session replay

New Relic Browser and its session data count toward ingest, so teams weighing a move usually compare three things: self-hosted OpenReplay, a managed OpenReplay variant, and an OpenTelemetry browser pipeline with Grafana. Each option trades session replay depth, operating effort and enterprise controls differently, so the choice depends on what you must keep in-house.

OpenReplay self-hosted

The open-source edition runs in your own cloud account or data center, with its core under AGPLv3 and the ee/ directory under a separate commercial license. It covers session replay, DevTools with network activity, console logs, JavaScript errors and more than 40 performance metrics. Session data stays in your infrastructure, and first-party tracking from your domain is not blocked by ad blockers. Check that your team can operate it, including upgrades, backups and retention, since community support is the only support included.

OpenReplay Enterprise edition

The self-hosted Enterprise edition is sold on custom pricing under multi-year contracts and adds SSO and SAML, SCIM provisioning, roles and permissions, an audit trail, a custom SLA and dedicated support. These are the controls that often decide audit readiness for identity and access, so they are paid features rather than defaults. Ask the vendor which Enterprise features require the ee/ code and confirm the license terms before you build on them.

OpenReplay Dedicated

Dedicated is a fully managed OpenReplay instance run by the vendor, starting at $199 per month on AWS, GCP or Azure with a 7-day trial, according to OpenReplay's pricing page. It fits teams that want replay data off their own operations queue but still need a single-tenant instance. Data still leaves your direct control, so confirm region, retention settings and where session data is stored before signing.

OpenReplay Bring-Your-Own-Cloud

Bring-Your-Own-Cloud runs OpenReplay managed by the vendor inside your AWS, GCP or Azure account. Infrastructure bills to your cloud subscription while the vendor operates the software, which suits teams that want residency inside their own tenancy without running upgrades themselves. Ask who holds administrative access to the cloud account, how keys are managed and what happens to the data after termination.

OpenTelemetry browser stack with Grafana

OpenTelemetry browser instrumentation sends JavaScript errors, page load timings and request traces to a Collector, then to Prometheus for metrics and Jaeger or another trace backend. This path links front-end traces to backend spans through shared trace context, which helps when debugging slow transactions. It does not record user sessions, so teams that rely on replay for support or UX investigation will need a separate tool alongside it.

Choosing between the paths

Self-hosted OpenReplay suits teams that need replay and keep all data in their own infrastructure, while Dedicated and Bring-Your-Own-Cloud shift operations to the vendor. The OpenTelemetry and Grafana path suits teams that need errors and metrics but not replay. Run a short proof of concept with real traffic volume, masking rules and the Enterprise controls your auditors expect, then compare the recurring cost of each option.

Running OpenReplay beside New Relic APM and backend traces

This split moves only browser data. New Relic continues to receive backend traces, metrics and logs through its existing agents or OTLP exporters, while OpenReplay captures session replay, JavaScript errors and front-end performance from the browser. It is the smallest change and suits teams whose main pressure is the browser data volume or session replay retention, not APM.

Scope of change: only the front-end snippet and its data path change, so backend instrumentation is not reopened.
Ingest effect: browser telemetry no longer counts toward New Relic ingest, but backend data still does, so ask New Relic which data types on your current plan are billed.
Correlation gap: without a shared identifier, a replay cannot be matched to a New Relic trace, so plan a header propagation step before relying on it.
Two consoles: engineers will switch between OpenReplay and New Relic during incidents, so document which tool answers which question.

Before committing, confirm with your New Relic account team which of your current data types are billed and whether any browser agent features you use depend on the agent.

How front-end sessions link back to backend traces

The link between a browser session and a backend trace depends on the browser SDK attaching trace context to outgoing requests, so the backend can record its spans under the same trace. In OpenTelemetry terms, the browser instrumentation creates a span for each page action or request and writes a traceparent header (W3C Trace Context) onto calls to your APIs. Your backend services must then accept that header, continue the trace, and export spans to the same Collector. Without both halves, you get session replays and JavaScript errors on one side and service traces on the other, with no reliable key between them. Confirm the exact propagation method, header names and any CORS allow-list settings against the OpenReplay and OpenTelemetry versions you deploy, because browser SDK behavior changes between releases.

The first-party domain matters for two reasons. First, the browser sends telemetry and trace headers to the same origin as the application, so requests to a collector or ingest endpoint are not blocked as third-party tracking. OpenReplay's README notes that first-party tracking from the operator's domain is not blocked by ad blockers, which is a reason to route ingest through a subdomain you control. Second, cross-origin requests to your APIs need CORS rules that permit the trace headers, or the browser will drop them. Decide early which hostnames serve the OpenReplay ingest, which serve the application, and which services receive the propagated headers, then test each one with a real browser session before rollout. On the backend, the team must configure the OpenTelemetry Collector to receive browser and server telemetry on the same pipeline and to export it to your trace store, such as Jaeger. Collector authenticator extensions can authenticate incoming connections on receivers, for example with OIDC, and add credentials to outgoing exporter requests, for example with the oauth2client extension. Apply these to the telemetry path so that only known front ends and services can write trace data. Review the Collector configuration best practices and confirm which authenticator fits your identity setup and Collector release.

Moving browser monitoring and replay to OpenReplay

This sequence moves browser error tracking, performance metrics and session replay from New Relic Browser to a self-hosted OpenReplay instance, with masking verified before any real user data is captured and a clear cutover point.

Inventory browser apps and replay usage
The product owner and the front-end leads list every New Relic Browser application, its agent or snippet version, the pages and funnels it covers, the alert conditions and dashboards built on it, and which teams actually watch session replays. Count monthly browser and replay data where New Relic shows it, so you know which signals are worth keeping. The step is done when each application has an owner, a list of dependent dashboards and alerts, and a note on whether replay is used for support, debugging or product analysis.
Deploy OpenReplay in your infrastructure
Platform engineering deploys the open-source edition in your own cloud account, data center or Kubernetes cluster, using the deployment path that matches your environment. OpenReplay's README describes a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage as enough to start, but production sizing depends on session volume and retention, so confirm it against your own traffic. The step is done when the ingest and web interfaces respond on a domain you control, TLS is valid, and backups of the storage layer are scheduled.
Add the tracker to a staging site
A front-end engineer installs the OpenReplay tracker in a staging build of one application, served from your own domain so first-party requests are not blocked by ad blockers. The tracker runs alongside the New Relic Browser agent during testing, so both sets of data can be compared on the same sessions. The step is done when a test session appears in OpenReplay with the expected page views, console logs and network activity, and the team confirms the agent does not break existing page behavior.
Configure masking before production capture
Security and privacy staff define masking rules before the tracker reaches real users. Use CSS selector masking and input redaction for personal and financial fields, and evaluate the private mode that masks all text and inputs by default for sensitive flows. Because sanitization happens at capture time, a rule missed here cannot be fixed later on stored replays. The step is done when a staging test with deliberately sensitive test data shows that masked values never appear in the replay, and the rule set is stored in version control.
Link front-end sessions to backend traces
Platform engineers connect browser sessions to backend telemetry so a JavaScript error can be followed into the API call that caused it. Confirm how OpenReplay correlates sessions with your OpenTelemetry trace IDs in your version, and align the propagation headers that your services already read. The step is done when one test request can be followed from a replayed session into the matching backend trace in your tracing backend.
Run New Relic and OpenReplay in parallel
Enable the OpenReplay tracker on a percentage of production traffic while the New Relic Browser agent stays active. Compare JavaScript error counts, page load metrics and session counts between the two tools, and document where they differ, since the tools measure sessions and timing differently. Keep the parallel run long enough to cover your normal release cycle and traffic peaks. The step is done when the team has signed off that error volumes and key performance views match within an agreed tolerance.
Rebuild dashboards and alert conditions
Dashboards and alert conditions are rebuilt by hand because no automated converter is supplied for New Relic Browser content. Recreate the important error and performance views in Grafana, where they sit alongside your Prometheus and tracing data, or in OpenReplay where session-level views are needed. Route alerts to the same on-call channels used today. Historical replay data does not carry over, so keep the New Relic account readable for the period your audit or support process needs. The step is done when each retired New Relic alert has a tested replacement and an owner.
Cut over and retire the New Relic agent
Remove the New Relic Browser snippet from production builds in a planned release, after the parallel run and dashboard rebuild are complete. Confirm with New Relic billing how browser data counts toward ingest before the cutover date, and export any records you must keep while access remains. Record the decision, the rollback path and the date the agent was removed. The step is done when production pages load without the New Relic agent, the OpenReplay alerts fire in a test, and the decommissioning record is filed.

Questions teams ask before replacing New Relic Browser

What does a self-hosted OpenReplay setup cost to run each year?

The software itself is free under the open-source edition, so the recurring cost is the infrastructure you run it on, the storage that holds replay data, and the staff time to upgrade and monitor it. Infrastructure and storage scale with how many sessions you record and how long you keep them, because self-managed retention is in your hands. Staff time is the largest and least visible item. Ask any implementation partner for a written quote that separates one-time work (setup, masking rules, dashboard rebuilds) from recurring work (upgrades, backups, capacity checks, on-call), and compare it with your current New Relic browser spend, which is driven by data ingested.

How long should a parallel run of New Relic Browser and OpenReplay take?

No duration is fixed by the product, so confirm the length with your team and your implementation partner against your own traffic and release calendar. A parallel run is practical because the JavaScript snippet on your front end can be added alongside the existing New Relic agent, so both collect data while you compare error counts, performance metrics and replay coverage. Plan the run to include at least one full release cycle and a period of peak traffic, and agree in writing what result counts as ready to cut over.

Can our internal team deploy and run OpenReplay without outside help?

Often yes, if you already run Docker, Kubernetes or a Linux VM fleet and have someone who can manage TLS, DNS and backups. The deployment documentation covers several targets, including Docker, Kubernetes with Helm and Ubuntu, so the choice depends on your platform skills. Outside help is most useful for masking policy review, first-party domain setup, integration with your existing tracing, and documented runbooks that auditors will ask for. Decide which of these your team can own before you start.

What does the team need to provide before a self-hosted deployment starts?

Start with the sizing reference in OpenReplay's README: a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is listed as enough to begin self-hosting. Treat that as a starting point rather than a capacity plan, because storage and memory needs grow with session volume and retention. You will also need a cloud account or data center location, a DNS name on your own domain, certificate management, outbound access for updates if your network allows it, backup storage, and a named owner for the front-end snippet and masking rules.

Which masking settings must we verify before recording any sessions?

Verify masking before the first production session, because the README describes capture-time sanitization that masks or skips data before it reaches the server. Check three things: that CSS selectors covering payment, identity and health fields are masked, that input redaction is active on all forms, and whether private mode, which masks all text and inputs by default, fits your use case. Test with synthetic data in a staging page and record what a reviewer sees in the replay. Your privacy and compliance leads should sign off on the rules in writing.

When is the OpenReplay Enterprise license or Dedicated instance worth pricing?

Price the Enterprise edition when you need SSO and SAML, SCIM provisioning, roles and permissions, audit trail, a custom SLA or dedicated support, since these are listed as Enterprise features. Price a managed Dedicated instance when your team cannot staff upgrades and on-call for the stack. The pricing page lists Dedicated starting at $199 per month on AWS, GCP or Azure, and Enterprise at custom pricing on multi-year contracts. Compare those figures against the internal staff time you would otherwise spend, and confirm current terms directly with OpenReplay before you decide.

How do we link front-end sessions to backend traces after migrating?

Propagate a shared trace identifier from the browser into your backend requests, then carry it through OpenTelemetry instrumentation so that Jaeger or your chosen trace backend receives the same identifier that appears in the session. Confirm that your OpenTelemetry Collector forwards the headers and that the trace context survives your gateways and load balancers. Test one user journey end to end before relying on it, since a missing header breaks the link silently.

What OpenReplay does not replace

OpenReplay covers the browser and mobile user experience layer, not New Relic's wider observability platform. Session replay, DevTools-style network and console data, JavaScript errors and performance metrics map to New Relic Browser and Session Replay. It does not replace New Relic's APM agents for back-end services, its infrastructure and log monitoring, or its NRQL-based alert conditions and dashboards. Before you plan a cutover, list every New Relic feature your teams use, including synthetic monitors and any alert policies that query browser data. Confirm with the OpenReplay documentation and your own environment whether each one has an equivalent. Where it does not, keep New Relic or a separate tool in place for that function.

Synthetic monitoring is a particular gap to check. OpenReplay's documented scope centers on recorded user sessions and front-end metrics, so scripted uptime checks and scheduled transaction tests need their own tool. Plan for that work in your inventory rather than assuming the replay platform absorbs it. Also confirm which alert types you depend on, because moving alerts from NRQL to another query model is a rebuild, not a copy.

The licensing needs a legal review before you deploy. The OpenReplay repository is mostly licensed under AGPLv3, some directories are MIT, and everything under the ee/ directory is covered by a separate commercial license defined in ee/LICENSE. If you use the Enterprise features such as SSO and SAML or SCIM provisioning, you are working under that commercial license. Under AGPLv3, your obligations depend on whether you modify OpenReplay and how users interact with it, and that question belongs with your legal team. DeployOpen does not provide legal advice on license terms, so have counsel review the license files and your intended use before rollout.

How DeployOpen scopes and delivers browser monitoring replacement

DeployOpen plans, implements, hardens and documents a self-hosted browser monitoring stack for Open-source alternative to New Relic Browser and Session Replay inside your own cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory which New Relic Browser agents, session data, dashboards and alert conditions are in use today.
Define the masking rules, retention periods and data residency requirements that the written scope must cover.
Agree which front-end, backend and trace linkage deliverables are in scope, with a fixed-scope written agreement.

How we build

Deploy OpenReplay in your environment, following its deployment documentation for your chosen target platform.
Configure capture-time masking by CSS selector, input redaction and private mode, then test that sensitive fields never reach the server.
Connect front-end sessions to backend OpenTelemetry traces so engineers can follow a user action into the services it calls.

How we hand over

Document the architecture, network paths, masking configuration and access model for your own platform team.
Provide runbooks for upgrades, backups, retention changes and troubleshooting of the browser SDK deployment.
Deliver test evidence and configuration records that your compliance and privacy reviewers can inspect.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Ask any proposal to state who patches OpenReplay, who reviews masking changes and who responds to incidents.
Confirm with the vendor which edition, licensing terms and support tier fit your use before the written scope is signed.

Open-source alternative to New Relic Browser and Session Replay