Open-source alternative to Sentry Session Replay

Open-source alternative to Sentry Session Replay: the short answer

If your team pays for Sentry to record user sessions, or needs those recordings to stay inside your own network, self-hosted OpenReplay covers session replay, and GlitchTip can keep error tracking in place. The two tools do different jobs, so you do not have to replace both at once. Session replay is a separate capability from error tracking: it records what a user saw and did in the browser, while error tracking groups exceptions and sends alerts. That separation is what makes a split practical, because you can move the replay workload to OpenReplay and keep exception data flowing into GlitchTip through the Sentry SDKs you already run.

Before you plan around OpenReplay, check its licensing. Most of the monorepo is under AGPLv3, some directories are MIT, and everything under the ee/ directory is a separate commercial Enterprise Edition under its own license, defined in ee/LICENSE. Confirm which edition and features your team needs, such as SSO, SCIM or audit trail, and whether any of them sit in the commercial code. The OpenReplay repository is the place to read the license split in full.

This page does not assume anything about your current Sentry plan, replay quota or contract terms. Those details decide how urgent the change is and what you will pay in the transition, so pull them from your own Sentry account and billing records before comparing costs. The sections that follow cover what OpenReplay captures, how it protects personal data at capture time, and how to run it beside GlitchTip during the move.

Which Sentry Session Replay capabilities OpenReplay and GlitchTip cover

This table maps the capabilities people usually rely on in Sentry Session Replay to OpenReplay and GlitchTip. Read it as a split: OpenReplay covers session recording, while GlitchTip covers errors, so most teams run both. Items marked as items to confirm need a check with the vendor or a test in your own environment before you rely on them.

Capability	OpenReplay	GlitchTip
Session replay (video-like playback of user sessions)	Covered: session replay is a core feature of the open-source edition	Not covered: GlitchTip does not record sessions
Console logs alongside replay	Covered: DevTools shows console logs with the session	Not covered as replay; GlitchTip captures log messages as events
Network activity alongside replay	Covered: DevTools includes network activity	Not covered: GlitchTip records performance of slow requests, not session traffic
JavaScript errors linked to a session	Covered: JavaScript errors are shown within the session recording	Covered: exceptions are grouped as issues through Sentry-compatible SDKs
Input masking and private mode	Covered: capture-time masking by CSS selector, input redaction and a private mode that masks text and inputs by default	Not applicable: GlitchTip does not capture page content for replay
Mobile replay	Covered for iOS, Android and React Native according to the README	Not covered: confirm mobile error SDK support in GlitchTip for your stack
Retention of replay data	Self-managed retention in the open-source edition; confirm the setting in your deployment	Confirm event retention settings for error data in your installation
Sentry replay privacy controls and integrations	Confirm with OpenReplay whether each Sentry-specific setting has a direct equivalent	Confirm with GlitchTip which Sentry integrations and features it does not provide

Which self-hosted session replay option fits which team

Session replay is the one part of a Sentry-style stack that GlitchTip does not cover, so the choice is about where replay data lives and which license terms apply. The options below separate teams that need full OpenReplay features, teams that want only the open-source edition, and teams that keep errors in GlitchTip and skip replay for now.

Full OpenReplay with the Enterprise edition

Choose this when identity and audit requirements are part of the purchase decision. The Enterprise edition, licensed separately under the ee/ directory, adds SSO and SAML, SCIM provisioning, roles and permissions, an audit trail, a custom SLA and dedicated support. Ask OpenReplay to confirm exactly which features ship in the self-hosted Enterprise build and whether the custom SLA covers self-hosted installs. Budget for a commercial contract on a multi-year term.

OpenReplay open-source edition only

Choose this when replay is needed for debugging and product review, and identity integration can be handled at the network or reverse proxy layer. The core is AGPLv3, with some directories under MIT. You get session replay, DevTools with network activity, console logs, JavaScript errors and capture-time masking. Retention is self-managed, and support is community-based, so your own platform team owns upgrades and storage growth.

Keep errors in GlitchTip, skip replay

Choose this when the main gap is error tracking and replay is a nice-to-have. GlitchTip keeps exceptions, performance data and uptime checks running on PostgreSQL with the Sentry SDKs already in your code. Nothing new has to be deployed in the browser, and no replay data is collected. Revisit the decision once you have a clear list of debugging questions that replay would answer.

License review before deployment

Any team running the core and the Enterprise edition side by side must map which directories they touch. The core is AGPLv3, so modifications that users interact with over a network may trigger source disclosure duties. Have counsel confirm how your use fits AGPLv3 and the ee/LICENSE terms before rollout. Confirm this review is complete before replay captures real user sessions.

Support and operating trade-off

Community support suits teams with Kubernetes or Docker experience and a named owner for upgrades. The Enterprise edition moves that risk into a contract with a custom SLA and dedicated support. Ask OpenReplay what release cadence to expect; the latest release listed is v1.28 from September 25, 2025, so confirm the upgrade path before your first install.

How GlitchTip and OpenReplay run side by side

Browser applications are the only environment where both tools usually run together. GlitchTip keeps receiving errors through the Sentry JavaScript SDK pointed at the GlitchTip DSN, so existing alerting, issue grouping and release tags stay as they are. OpenReplay runs its own tracker script in the same page, which records the DOM, console output, network calls and JavaScript errors into a replay session. The two SDKs do not share a session by default, so the link between them is something the team builds.

Keep the Sentry SDK for errors: Point the existing DSN at GlitchTip and leave the SDK version and integrations unchanged during the first phase.
Install the OpenReplay tracker separately: Add it as its own script with the project key from your OpenReplay instance, not as a Sentry integration.
Set a shared identifier: Pass the same user or session value to both tools, for example through setUser in the Sentry SDK and the matching identify call in the OpenReplay tracker.
Tag errors with the replay session URL: Add the OpenReplay session link as a custom tag or context on each error event so responders can jump from issue to replay.
Mask before capture: Configure input masking in the OpenReplay tracker before going live, since masking applies at capture time.

Before release, confirm that a test error in a staging page shows the replay link in GlitchTip and that the replay contains the same user action.

Moving replay data and users off Sentry without losing error history

This sequence moves session replay to self-hosted OpenReplay in your own environment while error tracking stays in GlitchTip, so each tool keeps the job it does best and nothing is switched on before masking is in place.

Inventory Sentry replay settings and sampling rules
Someone on the platform or frontend team exports the current Sentry replay configuration for each project: session sample rates, error-triggered sampling, masking settings (text, media and input), network capture and any allow or deny lists for URLs. Record which Sentry plan features gate replay and who owns each project. The step is done when you have a written table of every project, its replay settings and the pages where replay is active, which becomes the masking checklist for later steps. Confirm with Sentry what export options exist for replay recordings before you plan anything that depends on old data.
Confirm what replay history can move
Sentry replay recordings generally cannot be assumed to transfer to OpenReplay, so treat existing recordings as archive material until proven otherwise. Ask Sentry in writing whether recordings can be downloaded in a usable form, and ask OpenReplay whether it offers an import path for externally captured sessions. Decide with your compliance and legal contacts how long Sentry recordings must be kept and where that archive lives. The step is done when you have written answers from both vendors and an agreed retention position for the old data.
Deploy OpenReplay in your own environment
The platform team deploys OpenReplay in your cloud account, data center or Kubernetes cluster, following the vendor's deployment documentation. The 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 size with the vendor for your traffic. Configure storage, backups and TLS on a domain you control so tracking is first-party. The step is done when the OpenReplay web app loads, accepts a test session from a staging site, and the stored data stays in your infrastructure.
Configure masking and private mode before capture
Before any production page sends replay data, the frontend team sets masking in the OpenReplay tracker: CSS selectors for sensitive elements, input redaction for forms such as payment, identity and health fields, and private mode where a page should mask all text and inputs by default. Masking runs at capture time, so it must be in place before the tracker goes live. Review each page from your Step 1 table with security and privacy staff, and test with sample data that masked values never reach the server. The step is done when a signed-off masking matrix exists and test recordings show no unmasked sensitive values.
Run both tools in parallel on a traffic subset
Keep Sentry replay active on most traffic while enabling OpenReplay on a limited subset, such as one application, one region or a set of internal test users. Keep error tracking in GlitchTip throughout, with its Sentry-compatible SDK DSNs unchanged. Compare recordings, console logs, network activity and JavaScript error capture for the same user journeys, and check that OpenReplay's linked errors match what GlitchTip records. The step is done when the team has a written comparison for the pilot paths and has logged any gaps, such as missing events or slower playback.
Switch the replay tracker and verify
Once the parallel run is accepted, the frontend team changes the replay tracker from Sentry to OpenReplay on each application, in staged releases, and removes the Sentry replay integration from the browser bundle. Keep GlitchTip's error SDK configuration intact so exceptions continue to arrive. Check tracker load, cross-browser behavior and privacy headers after each release, and monitor OpenReplay storage growth against the retention you configured. The step is done when every in-scope application sends replay to OpenReplay and no new Sentry replay data is created.
Retire Sentry replay and archive
After the switch, disable replay in Sentry project settings, then remove the replay configuration from your code and infrastructure definitions. Archive the Step 2 recordings and configuration records according to the retention position you agreed. Update runbooks so support staff look in OpenReplay for session playback and in GlitchTip for error grouping. Review your subscription with Sentry against the replay features you no longer use. The step is done when Sentry shows no active replay, the archive is verified readable, and the runbooks name the owner of each tool.

How input masking and private mode protect user data

The most important protection in a self-hosted replay tool happens before data leaves the browser. OpenReplay's README describes capture-time sanitization, which masks or skips sensitive data before it reaches the server. Two controls do most of the work: masking by CSS selector, which hides any element you target, and input redaction, which keeps typed values out of recordings. Private mode goes further by masking all text and inputs by default, so a page is blocked until someone decides what may be shown. Before rollout, decide which mode fits each product area. Checkout, account settings, support forms and health or benefits pages usually need the strictest setting, while marketing pages may not. Your team should also decide which pages are excluded from recording altogether.

Several decisions sit with your organization, not with the tool. You must choose which fields and pages are masked or excluded, set how long recordings are kept (OpenReplay's self-managed retention is configured by the operator), and define who can view, export or share replays. Role-based access and audit trail features are listed in the Enterprise edition, so confirm whether your deployment needs them before you choose a tier. Document these decisions in a written masking standard that names the owner of each rule and the review date. Masking rules also change as front ends change, so a selector that hides a field today may miss the same field after a redesign.

Treat masking as a control to test, not a setting to switch on. Build a test page or staging environment with realistic but synthetic data, record sessions, and check the replays for leaked values in text, input fields, dynamic content and network-related views. Repeat the test after each release that touches a masked page. Have a privacy or legal reviewer sign off on the rule set and the retention period, and keep that sign-off with the configuration. This work prepares evidence for your privacy and security reviews, but it does not by itself establish that any regulation or standard is met. Ask an independent assessor to confirm the outcome where your obligations require it.

What buyers ask before replacing Sentry Session Replay

What drives the total cost of self-hosting OpenReplay instead of keeping Sentry Session Replay?

The cost is the hosting, the storage and retention you choose, and the staff time to run it, and none of these is a fixed number until you size them. OpenReplay's pricing page lists the open-source edition as free to self-host with community support and self-managed retention, so the software license itself is not the expense. The README says a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start, but session volume, retention length and replay size will push that up over time. Recurring costs include cloud compute, disk growth, upgrades and masking reviews. Ask Sentry for your current Session Replay plan price and quota, then compare it with your own infrastructure estimate for the same volume and retention.

How long does a migration off Sentry Session Replay take?

The timeline depends on how many applications send replays, how much masking policy work is needed, and how much retention history you want to keep. Deployment itself is documented as a fairly contained task: OpenReplay's deployment docs cover Docker, Kubernetes with Helm and several cloud targets. The longer parts are agreeing which fields are masked, adding the tracker to each frontend, and running both tools side by side until replays look right. DeployOpen agrees timelines in a written, fixed scope before work starts, so the realistic duration comes from that scope rather than from a general figure.

What does the work need from our team?

Expect to need frontend access, DNS control for a first-party tracking domain, infrastructure accounts for the chosen cloud or cluster, and a privacy sign-off on what gets recorded. OpenReplay's README notes that first-party tracking from your own domain is not blocked by ad blockers, which means the team must control the subdomain that serves the tracker. The privacy review matters because capture-time masking by CSS selector and input redaction decides what leaves the browser, and that policy belongs to your data owner, not only to engineering.

Can our own engineers run OpenReplay without outside help?

Yes, if your team has the skills to operate a containerized or Kubernetes application, keep it patched and own the masking policy. OpenReplay publishes self-hosting documentation and a community edition, so an internal team can deploy it. The harder ongoing work is upgrades, backups, storage capacity planning and reviewing masking rules whenever pages change. Many organizations choose a fixed-scope engagement for the first deployment and hardening, then keep operations in-house or move to a retainer for upgrades and testing.

Do we need OpenReplay Enterprise features such as SSO or audit trails?

Only if your governance requires them. OpenReplay's pricing page lists a self-hosted Enterprise edition at custom pricing on multi-year contracts, adding SSO and SAML, SCIM provisioning, roles and permissions, audit trail, a custom SLA and dedicated support. The open-source edition covers replay, console logs, network activity and JavaScript errors. Note that OpenReplay's README says everything under the ee/ directory is under a separate commercial license, so confirm the license terms before relying on those features. Ask OpenReplay for current Enterprise pricing, since none is published as a fixed figure.

Can we export existing Session Replay recordings from Sentry?

Confirm this with Sentry before planning, because recordings are not the same kind of data as error events. The safest assumption is that you can export issues, events and project settings through Sentry's web API, but replay recordings may need their own export path or may not be exportable in a form OpenReplay can import. Plan for a cutover where new sessions go to OpenReplay while old recordings stay available in Sentry until their retention ends. Keep errors in GlitchTip running separately, since that work is covered by the GlitchTip migration pages.

Will replay and error tracking need to run in separate tools?

Yes, in the planned setup. OpenReplay handles session replay with console logs, network activity and JavaScript errors, while GlitchTip keeps error tracking and remains compatible with Sentry client SDKs. Running two tools means two sets of hosts, two sets of upgrades and two retention policies, but it lets you replace only the replay product now. Check whether the errors you need to correlate with recordings are captured in both places, and decide which tool is the source of truth for each incident workflow before cutover.

What privacy risks should we check before recording sessions?

The main risks are recording personal data that masking misses, retaining recordings longer than your policy allows, and giving too many staff access to raw sessions. OpenReplay's README describes capture-time sanitization that masks or skips data before it reaches the server, and a private mode that masks all text and inputs by default. Test those settings on your real forms and flows, and document the decision. Self-hosting keeps session data in your own infrastructure, which helps with residency questions, but it does not remove the need for a documented retention and access policy.

What a self-hosted replay stack costs to run

The main cost of a self-hosted replay stack is not the license, because the OpenReplay open-source edition is free to run. The recurring costs are the compute that hosts OpenReplay, the storage that grows with recording volume and retention, the PostgreSQL and worker resources that GlitchTip needs for error events, and the people who patch, back up and watch both. OpenReplay's README describes a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage as enough to start, but that is a starting point, not a sizing estimate. Storage is the component most likely to surprise you, because replay size scales with session volume and with how many days you keep recordings. Before you ask for a quote, decide your retention target and your expected session count per month, and ask the implementer to size the VM, object storage and disk from those two numbers. GlitchTip's own minimums (256 MB RAM for the all-in-one setup, 512 MB recommended, per its installation documentation) are small, but a production error pipeline with an external PostgreSQL 14 or later database and separate worker services is a different sizing exercise.

Recurring effort is where most of the total cost sits. Each OpenReplay release needs a planned upgrade and a test run against your masking rules, since a change in capture behavior can silently expose data you intended to hide. The latest release listed on OpenReplay's GitHub releases page is v1.28, published on September 25, 2025, after v1.27.0 in May 2025, so ask how the implementer tracks new releases and how long an upgrade window takes in your environment. Backups must cover both the OpenReplay data store and the GlitchTip PostgreSQL database, and a restore test should be part of the routine, not a one-time exercise. Monitoring the replay stack itself, and rotating credentials and certificates, also falls to someone on your team. Price this as on-call time, not as a line item in a cloud bill.

One-time costs are the setup of hosting, the integration of the OpenReplay tracker into your front end, and above all the masking design: which CSS selectors to mask, which inputs to redact, and whether private mode should be the default for sensitive pages. Re-doing masking after launch means re-reviewing past recordings, so treat it as a design task with sign-off from security and privacy. When you request a quote, specify the scope (which applications, mobile apps or not, and whether GlitchTip is migrated or only set up), the environment (your cloud account, a data center or an air-gapped network), the retention target in days, the expected session volume, and the support expectations, including response times, upgrade cadence and whether you need a retainer for ongoing support. Ask for each cost component as a separate line so you can see which items recur. If you want the Enterprise features such as SSO, SCIM or audit trail, confirm with OpenReplay how those are priced, since its pricing page lists them at custom pricing.

How DeployOpen delivers session replay replacement

DeployOpen works from a written scope that separates replay requirements from error tracking requirements, so OpenReplay and GlitchTip each get a clear job. The cards below follow the engagement from scoping through masking, testing, documentation and ongoing support, all inside your own cloud account, data center or air-gapped network.

Written scope for replay and errors

Before any work starts, DeployOpen records which pages and user flows need replay, which exceptions must stay in GlitchTip, how long each data type must be kept and which teams can view recordings. Most engagements are fixed-scope, so deliverables and timelines are agreed in writing first. This prevents the common gap where replay is switched on everywhere without a legal or privacy review of what it captures.

OpenReplay deployed in your environment

DeployOpen installs the self-hosted OpenReplay open-source edition in the AWS, Google Cloud, Azure, Kubernetes or Docker environment you already run, or on bare Ubuntu where that is your standard. Session data then stays in your infrastructure, and the OpenReplay README notes that first-party tracking from your own domain is not blocked by ad blockers. Sizing should be confirmed against current guidance, since the README only gives a starting footprint.

Masking and private mode configuration

DeployOpen configures capture-time sanitization, including masking by CSS selector and input redaction, so sensitive fields are masked before data reaches the server. Private mode can be set to mask all text and inputs by default, and each rule is reviewed with the client's privacy team against real page templates. Each masking rule should be tested on forms that handle identifiers, account numbers and health or payment details.

GlitchTip for errors alongside replay

DeployOpen keeps the existing Sentry client SDKs and points error reporting at a self-hosted GlitchTip instance, so exception grouping and alerts stay in one place while replay runs as a separate tool. The team then correlates a GlitchTip issue with an OpenReplay session by timestamp and user context. GlitchTip requires PostgreSQL 14 or later, and DeployOpen confirms that database sizing and backups are in place before cutover.

Capture testing before rollout

Before any production traffic is recorded, DeployOpen tests capture on staging builds with scripted sessions. The test confirms that masked fields stay masked, that console logs, network activity and JavaScript errors appear in the session timeline, and that GlitchTip receives events from the SDK. Results are recorded so the client can compare them against the written scope before approving rollout.

Documentation, upgrades and retainers

DeployOpen documents the deployment, masking rules, retention settings and runbooks so your engineers can operate the stack after handover. Upgrades follow OpenReplay releases, such as v1.28 published on September 25, 2025, and GlitchTip releases, and ongoing testing is available under a retainer. Ask any provider to confirm how privacy rule changes are reviewed after each upgrade.

Open-source alternative to Sentry Session Replay