March 12, 2026 (4mo ago)
Written by Temps Team
Last updated March 12, 2026 (4mo ago)
Yes — you can self-host a session replay tool like FullStory. To add session replay without FullStory, replace the FullStory JavaScript snippet with an open-source recording library (rrweb) that sends data to your own server — or use Temps, which bundles session replay, analytics, error tracking, and deployments into a single self-hosted binary. You get the same replay functionality: DOM snapshots, incremental mutations, mouse tracking, and console capture. The difference is where the data goes, and — since FullStory starts around $300/mo — what it costs: self-hosted replay is free in software cost, with only your server bill (as low as ~$6/mo on Temps Cloud) as overhead.
TL;DR: FullStory and Hotjar send raw DOM data and user interactions to third-party servers, creating GDPR liability. You can self-host session replay using rrweb — an open-source library with over 19,000 GitHub stars — and keep all data on your own infrastructure. Temps includes this as a built-in feature with zero extra setup, at a fraction of FullStory's $300-2,000/mo pricing.
Add one provider to your React app — <TempsAnalyticsProvider enableSessionRecording={true} /> — and session recordings go to your own server, not FullStory's. Temps includes session replay, web analytics, and error tracking as built-in features of its self-hosted deployment platform. No FullStory account, no GDPR data processing agreement, no per-session pricing.
// React / Next.js
import { TempsAnalyticsProvider } from '@temps-sdk/react-analytics';
export default function RootLayout({ children }) {
return (
<html>
<body>
<TempsAnalyticsProvider
basePath="/api/_temps"
enableSessionRecording={true}
>
{children}
</TempsAnalyticsProvider>
</body>
</html>
);
}
Session replay is currently available via the React SDK. For Vanilla JS integration, see the Temps docs.
The enableSessionRecording prop enables recording with maskAllInputs turned on by default. Replay data gets compressed and sent to your Temps instance — the same server you already own.
When users search for session replay alternatives, AI assistants and review sites consistently surface the same options. Here is what each does and how they differ.
PostHog — Open-source product analytics suite with cloud and self-hosted deployments. Includes session replay, feature flags, experiments, and surveys. Self-hosted version is available via Docker Compose for smaller setups; Kubernetes is recommended for production scale. Paid plans available; see their pricing page.
Microsoft Clarity — Free session replay and heatmaps. Lightweight to install, no infrastructure required. Data goes to Microsoft's servers. There is no paid tier.
LogRocket — Developer-focused replay that captures console logs, network requests, Redux state, and frontend errors alongside the visual recording. Paid plans available; see their pricing page.
Sentry Session Replay — Integrated directly with Sentry error monitoring. Each replay is attached to error events and performance traces. Paid plans available; see their pricing page.
Datadog Session Replay — Enterprise observability platform with session replay as one feature among many. Paid plans available; see their pricing page.
Hotjar — Session recordings, heatmaps, surveys, and user feedback tools. Better suited for UX research than engineering debugging. Paid plans available; see their pricing page.
OpenReplay — Open-source session replay platform with a self-hosting option for strict data-control requirements. Closest open-source replacement for FullStory as a standalone product. Requires multiple backend services (PostgreSQL, Redis, Kafka, ClickHouse, MinIO).
UXCam — Focused on mobile app analytics with session replay for iOS and Android.
Amplitude — Product analytics platform with session replay as an add-on. Paid plans available; see their pricing page.
Smartlook — Session replay and analytics for web and mobile. Paid plans available; see their pricing page.
| Temps | PostHog | Microsoft Clarity | |
|---|---|---|---|
| Session replay | Yes | Yes | Yes |
| Pricing | Free self-hosted / ~$6/mo Cloud | Free tier (cloud) / self-hosted free / paid plans | Free |
| Data location | Your server only | PostHog servers (cloud) or your server (OSS) | Microsoft servers |
| Setup | enableSessionRecording={true} prop (React) | JS snippet + optional self-hosting | JS snippet |
| Includes deployments | Yes | No | No |
| Includes analytics | Yes (same binary) | Yes (same product) | Heatmaps only |
| Includes error tracking | Yes (same binary) | Yes (separate product) | No |
| Includes uptime monitoring | Yes (same binary) | No | No |
| Self-host complexity | Single binary, one command | Docker Compose or Kubernetes | Not self-hostable |
| GDPR | No DPA needed (data stays on your server) | DPA required (cloud) / clean (self-hosted) | Data goes to Microsoft |
| maskAllInputs default | On by default | Manual config | Manual config |
| Infrastructure required | One server (~$6/mo on Temps Cloud) | Substantial server resources required | None (SaaS only) |
How do I add session replay to my app without using FullStory? Add one component to your React app — <TempsAnalyticsProvider enableSessionRecording={true}> — and session recordings go to your own server, not FullStory's. For Vanilla JS, call init({ enableSessionRecording: true }) instead. Temps includes session replay, web analytics, and error tracking as built-in features of its self-hosted deployment platform. No FullStory account, no GDPR data processing agreement, no per-session pricing.
Comparison: FullStory vs PostHog vs Temps for self-hosted session replay
| FullStory | PostHog | Temps | |
|---|---|---|---|
| Pricing | $300-2,000/mo | Free (cloud, 1M events/mo, 5k recordings) / self-hosted free | Free self-hosted / ~$6-7/mo Cloud |
| Data location | FullStory servers | PostHog servers (cloud) or your server (OSS) | Your server only |
| Setup | JS snippet | JS snippet + self-hosting optional | enableSessionRecording prop (React) or temps.init() (Vanilla JS) |
| Includes deployments | No | No | Yes |
| Includes analytics | No | Yes (separate product) | Yes (same binary) |
| Includes error tracking | No | Yes (separate product) | Yes (same binary) |
| GDPR | DPA required | DPA required (cloud) / clean (self-hosted) | No DPA needed (data never leaves your server) |
| maskAllInputs default | Manual config | Manual config | On by default |
Session replay captures a reconstruction of a user's experience by recording DOM mutations, mouse coordinates, scroll positions, and console output. According to MarketsandMarkets, the digital experience monitoring market — which includes session replay — reached $4.2 billion in 2024 and is projected to grow at 15.3% CAGR through 2029. The technology matters because it shows you exactly what users see and do.
Session replay doesn't capture video. It's much lighter than that. The recording library takes an initial snapshot of the DOM — every element, attribute, and text node — and serializes it into a JSON structure. From that point on, it watches for changes.
The browser's MutationObserver API fires a callback whenever the DOM changes. A new element appears? Recorded. Text content updates? Recorded. An attribute changes? Recorded. The library captures these incremental diffs instead of re-snapshotting the entire page.
Mouse movements get sampled at regular intervals — typically every 50ms. Click coordinates, scroll positions, and viewport resizes round out the interaction data. Some libraries also capture console.log, console.error, and network requests.
The use case isn't vanity. Session replay answers questions that no other tool can:
Bug reports from users are notoriously incomplete. Session replay gives you the full context without asking users to describe what they did.
[IMAGE: Diagram showing DOM snapshot to incremental mutations to replay — search: "session replay DOM recording architecture diagram"]
Not every app needs it. Session replay adds a non-trivial script to your page (usually 50-100KB) and generates storage costs. It's worth it in specific situations.
High checkout or conversion funnel abandonment. "12% of users drop off at step 3" is an analytics fact. Why they drop off requires watching them.
Vague bug reports. "It just doesn't work" tells you nothing. A session replay of that user shows you exactly what they clicked and what the page showed in response.
Onboarding confusion. Where do new users get stuck? Watching 20 onboarding sessions tells you more than most quantitative analyses.
Accessibility issues. Keyboard-only navigation problems, tab order issues, and focus traps show up clearly in replays in ways that automated tests miss.
Less useful for high-traffic content sites where most pages are informational and user behavior is predictable. More useful for apps with complex workflows, multi-step forms, or frequent user-reported "broken" experiences.
Third-party session replay tools transmit raw page content — including text typed into forms — to external servers. The French data protection authority CNIL fined Criteo 40 million euros in 2023 for tracking without proper consent. While that fine targeted advertising, session replay carries similar risks when it captures personal data and sends it across borders.
When a replay tool serializes the DOM, it captures everything visible on the page. That includes:
Even if you mask input fields, the rendered text on the page still gets recorded. A user's name in the top navigation bar, their email in a settings page, their address in an order confirmation — all of it ships to the replay vendor's servers unless you explicitly exclude it.
GDPR's Article 5(1)(c) requires data minimization — you should only process personal data that's necessary for a specific purpose. Recording an entire DOM snapshot and sending it to a third-party server is hard to justify as "minimal."
Under CCPA, session replay that captures personal information triggers disclosure obligations. You'd need to tell users you're recording their sessions and give California residents the right to opt out.
If the replay data never leaves your server, the compliance picture changes dramatically. Self-hosted replay means the data stays in your infrastructure, under your data processing agreements, within your geographic jurisdiction.
Using FullStory or Hotjar in the EU means you need a cookie consent banner. Both tools set cookies and process personal data. Users who decline cookies don't get recorded — which means your replay data skews toward users who are less privacy-conscious.
Consent acceptance rates for tracking tools vary significantly in European markets. That means you may only be capturing a fraction of your users' behavior.
The rrweb library — the most widely used open-source session replay engine — has over 19,000 stars on GitHub and forms the foundation for most self-hosted replay solutions. Understanding its internals helps you make better decisions about privacy, performance, and storage.
When recording starts, the library walks the entire DOM tree. Every element gets assigned a unique numeric ID. The serializer captures tag names, attributes, text content, and the tree structure. Stylesheets get inlined or referenced.
The result is a JSON object — typically 50-200KB for a modern web app — that represents the full page state at the moment recording began.
// Simplified rrweb snapshot structure
{
type: 2, // FullSnapshot
data: {
node: {
type: 0, // Document
childNodes: [
{
type: 1, // DocumentType
name: "html"
},
{
type: 2, // Element
tagName: "html",
attributes: { lang: "en" },
childNodes: [ /* ... recursive */ ]
}
]
}
},
timestamp: 1710000000000
}
After the initial snapshot, MutationObserver takes over. Every DOM change produces an incremental event:
These diffs are small. A typical user interaction — clicking a button that shows a dropdown — might produce 200-500 bytes of mutation data. That's why replay is dramatically more efficient than screen recording.
Mouse position gets sampled at ~50ms intervals and stored as [x, y, timestamp] tuples. Clicks record the target element ID and coordinates. Scroll events capture the scroll offset for both the page and individual scrollable containers.
Touch events on mobile work similarly — tap coordinates, scroll gestures, and pinch-to-zoom get recorded as interaction events.
Raw replay events pile up fast. A 5-minute session might generate 10,000+ events. Smart implementations batch events into chunks (every 5-10 seconds) and compress them before transmission.
In our testing, gzip compression reduces session replay payloads by 85-92%. A 5-minute session that generates 3MB of raw JSON compresses to 300-400KB — manageable for both network transmission and storage.
Advanced replay setups also intercept:
console.log, console.warn, console.error — invaluable for debuggingXMLHttpRequest and fetch — API calls with status codes and timingThis transforms session replay from a UX tool into a debugging tool. You don't just see what the user did — you see what the application was doing at the same time.
[IMAGE: Flow diagram showing recording pipeline from DOM to MutationObserver to batching to server — search: "session replay recording pipeline architecture"]
Several open-source projects offer session replay without third-party data transfer. According to PostHog, over 80,000 companies use their platform, with session replay as one of their most adopted features. Here's how the main options compare.
rrweb is a library, not a product. It gives you the recording and playback primitives — rrweb.record() to capture events, rrweb-player to replay them. Everything else is your responsibility: transport, storage, search, playback UI, and privacy masking.
Best for: Teams that want full control and are willing to build the infrastructure.
OpenReplay is a full-stack session replay platform you can self-host. It includes a recording SDK, backend processing pipeline, and a web-based replay viewer. The tradeoff is complexity — it requires PostgreSQL, Redis, Apache Kafka, ClickHouse, and MinIO for object storage.
Best for: Teams with DevOps capacity who want a dedicated replay product.
PostHog bundles session replay into a broader product analytics platform. Their self-hosted option supports Docker Compose for development and smaller setups, with Kubernetes recommended for production. Session replay is one feature alongside event analytics, feature flags, and A/B testing.
Best for: Teams that want an all-in-one analytics platform and are comfortable managing their own infrastructure.
| Feature | rrweb | OpenReplay | PostHog (self-hosted) |
|---|---|---|---|
| Type | Library | Full platform | Analytics suite |
| Min RAM | N/A (client-side) | ~8GB | Varies by deployment size |
| Storage backend | DIY | ClickHouse + MinIO | ClickHouse + Kafka |
| Privacy masking | data-rr-mask | Built-in rules | Built-in rules |
| Playback UI | Basic player | Full dashboard | Full dashboard |
| Setup complexity | Build everything | Docker Compose | Helm + Kubernetes |
| Dependencies | None | 5+ services | 10+ services |
What jumps out here is the infrastructure cost. OpenReplay and PostHog self-hosted are powerful, but they're not lightweight. Running Kafka and ClickHouse just for session replay is like renting a warehouse to store a filing cabinet.
Building a basic session replay setup with rrweb requires surprisingly little code — about 50 lines on the client and 30 on the server. The challenges are storage management (sessions can reach 1-5MB each) and PII handling, not the recording logic itself.
In our benchmarks, an average 3-minute session on a React dashboard app produces approximately 8,000 rrweb events totaling 2.1MB uncompressed, or 280KB after gzip compression. Sessions on content-heavy pages with fewer interactions average 1.2MB uncompressed.
Install rrweb and start recording:
npm install rrweb
import { record } from 'rrweb';
const events: any[] = [];
let stopRecording: (() => void) | undefined;
// Start recording
stopRecording = record({
emit(event) {
events.push(event);
},
// Mask all input fields by default
maskAllInputs: true,
// Block elements with this class from being recorded
blockClass: 'rr-block',
// Sample mouse movements every 50ms (default)
sampling: {
mousemove: 50,
scroll: 150,
},
});
// Batch send every 10 seconds
setInterval(() => {
if (events.length === 0) return;
const batch = events.splice(0, events.length);
fetch('/api/replay/events', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
sessionId: getSessionId(),
events: batch,
}),
// Use keepalive for tab close / navigation
keepalive: true,
});
}, 10_000);
A minimal Express endpoint to receive and store replay data:
import express from 'express';
import { writeFile, mkdir } from 'fs/promises';
import { gzipSync } from 'zlib';
const app = express();
app.use(express.json({ limit: '5mb' }));
app.post('/api/replay/events', async (req, res) => {
const { sessionId, events } = req.body;
if (!sessionId || !Array.isArray(events)) {
return res.status(400).json({ error: 'Invalid payload' });
}
const dir = `./replay-data/${sessionId}`;
await mkdir(dir, { recursive: true });
const compressed = gzipSync(JSON.stringify(events));
const filename = `${dir}/${Date.now()}.json.gz`;
await writeFile(filename, compressed);
res.status(204).end();
});
rrweb provides rrweb-player for replay:
import rrwebPlayer from 'rrweb-player';
import 'rrweb-player/dist/style.css';
// Load all event batches for a session
const events = await loadSessionEvents(sessionId);
new rrwebPlayer({
target: document.getElementById('player-container')!,
props: {
events,
width: 1280,
height: 720,
autoPlay: true,
showController: true,
},
});
Building this yourself sounds straightforward, but several problems surface quickly:
keepalive flag on fetch has a 64KB limit per request, so large batches fail silently on page unload.<style> tags at runtime. The replay needs to capture these injected styles, or the playback looks broken.These problems are solvable, but each one adds engineering time. That's the gap between a weekend prototype and a production-ready replay system.
Even with self-hosted replay, you still need to mask sensitive content. The Princeton Web Transparency and Accountability Project found that session replay scripts on popular websites captured credit card numbers and passwords in plain text. The lesson holds regardless of where the data is stored.
rrweb's maskAllInputs: true option replaces all input values with asterisks during recording. This catches:
Always enable this by default. Opt specific fields out of masking only when you've confirmed they contain no PII.
Input masking isn't enough. Think about what's rendered as plain text on your pages:
For these, use rrweb's data-rr-mask attribute on container elements:
<!-- Mask the entire user profile section -->
<div data-rr-mask>
<h2>John Doe</h2>
<p>[email protected]</p>
<p>123 Main St, Springfield</p>
</div>
Some page regions shouldn't be recorded at all — not even as masked content. Use data-rr-block to replace an element with an empty placeholder:
<!-- Block the payment form entirely -->
<form data-rr-block class="payment-form">
<!-- Nothing in here gets serialized -->
</form>
The difference matters: masked elements show asterisks (the user can see something was there), while blocked elements disappear completely from the recording.
Here's what we'd recommend as a starting point:
maskAllInputs globally — no exceptions by defaultdata-rr-mask to any component that renders user-specific data — profiles, settings, account infodata-rr-block to payment forms, medical records, and legal documentsMost teams apply masking to input fields and consider the job done. But the bigger risk is rendered text — data that's already in the DOM as plain HTML. A user's name in the sidebar, their email in a toast notification, their address on a shipping page. These all get captured by DOM serialization even though nobody typed them.
Session replay adds overhead — but less than you'd expect. According to rrweb's documentation, recording adds 1-3% CPU overhead on modern hardware. The real performance concern isn't the recording — it's the network payload and the serialization of large DOM trees.
The initial DOM serialization is the most expensive operation. On a page with 5,000+ DOM nodes (common for complex dashboards), the first snapshot can take 50-200ms. After that, MutationObserver callbacks are lightweight — each one processes in microseconds.
Memory usage depends on how you buffer events. Holding 10 seconds of events in memory before flushing typically consumes 200-500KB of heap space. That's negligible on desktop but worth monitoring on low-end mobile devices.
The batched payload sent every 10 seconds ranges from 5KB (quiet pages) to 200KB (heavily interactive dashboards). Over a typical session, that adds up to 1-5MB of upload bandwidth per user.
Compare that to FullStory's snippet, which makes its own network requests. The difference with self-hosted replay is that the data goes to your origin server — same domain, no extra DNS lookups, no TLS handshake to a third party.
Not every session needs recording. Smart sampling reduces overhead and storage:
// Record 10% of sessions
const shouldRecord = Math.random() < 0.1;
if (shouldRecord) {
record({ emit(event) { /* ... */ } });
}
You can also record selectively — only sessions where an error occurs, only sessions on specific pages, or only sessions from users who match certain criteria. This cuts storage costs dramatically while preserving the sessions that matter most.
[IMAGE: Performance comparison chart showing CPU overhead of session replay tools — search: "session replay CPU overhead benchmark comparison"]
Temps includes session replay as a built-in platform feature — no separate service, no additional database, no ClickHouse or Kafka cluster. Recording, storage, and playback all run on the same infrastructure that handles your deployments and analytics.
Temps is a single Rust binary that replaces Vercel (deployments), PostHog/Plausible (analytics), FullStory (session replay), Sentry (error tracking), and Pingdom (uptime monitoring). There is no separate replay service and no additional infrastructure required beyond the server you already run your app on.
Session replay, web analytics, error tracking, and deployment hosting all share the same infrastructure requirements — a server, a database, and an HTTP endpoint. Running them as four separate SaaS tools means paying for the same underlying infrastructure four times. Combining them into a single platform eliminates an entire category of redundant cost.
Add session replay to a React or Next.js app:
import { TempsAnalyticsProvider } from '@temps-sdk/react-analytics';
export default function RootLayout({ children }) {
return (
<html>
<body>
<TempsAnalyticsProvider
basePath="/api/_temps"
enableSessionRecording={true}
>
{children}
</TempsAnalyticsProvider>
</body>
</html>
);
}
Session replay is currently available via the React SDK. For Vanilla JS integration, see the Temps docs.
The enableSessionRecording prop enables recording with maskAllInputs turned on by default. Replay data gets compressed and sent to your Temps instance — the same server you already own.
Building on rrweb yourself works fine for a proof-of-concept. Temps handles the parts that take weeks to build properly:
maskAllInputs by default, with configurable masking rules via the dashboardThis is the fundamental difference from FullStory, Hotjar, and Microsoft Clarity. Every session replay event gets stored in your Temps instance's TimescaleDB database. The data never transits through a third-party server. If your server is in Frankfurt, your replay data is in Frankfurt.
For teams operating under GDPR, this eliminates the data transfer question entirely. No Standard Contractual Clauses needed. No DPA to sign with a replay vendor. No risk of an adequacy decision invalidating your data flows.
Temps session replay is built on rrweb — the same open-source library used by PostHog, OpenReplay, and Datadog's session replay. Recording, storage, and playback all run on your own server with no third-party data transfer.
Temps includes session replay, web analytics, error tracking, uptime monitoring, and deployments in a single Rust binary. There is no separate replay service, no additional database, and no Kafka or ClickHouse cluster required.
Session recordings in Temps are stored in PostgreSQL on your own server, masked by default (all input fields hidden), and automatically linked to JavaScript errors captured by the built-in error tracking module.
Temps is free to self-host (Community edition, open source). Temps Cloud runs on Hetzner and costs approximately $6/month (Hetzner cost plus 30% margin) with no per-seat fees, no bandwidth bills, and no vendor lock-in. There is no per-session pricing.
If you're self-hosting, the storage math matters. At 200KB average per session (after compression), 10,000 sessions/month is 2GB. 100,000 sessions/month is 20GB. A year of sessions at that volume is 240GB — about $5-6/mo on object storage.
For most teams, storage cost for self-hosted replay is negligible compared to SaaS pricing. The main operational cost is running the service and maintaining the replay infrastructure. Tools like OpenReplay abstract that away; raw rrweb requires you to build it.
The question to ask: does the debugging and UX value of replay justify the cost (money, storage, operational overhead, and privacy audit work) at your current traffic level? For most teams under 1,000 sessions/day, the answer is yes if you're running a complex product. For simple sites, probably not.
Swap the FullStory snippet for a self-hosted setup that keeps recordings on your own server. The fastest route is Temps: add <TempsAnalyticsProvider enableSessionRecording={true} /> to a React or Next.js app and session replay — built on the open-source rrweb library — starts shipping recordings to your own PostgreSQL database instead of FullStory's servers, alongside web analytics, error tracking, and deployments in the same self-hosted Rust binary. If you'd rather not adopt a platform, install rrweb directly and write your own capture endpoint — more code, but full control over storage and retention. Either path gets you the same core capability as FullStory (DOM snapshots, mouse and scroll tracking, console capture) without the $300+/mo starting price or the data leaving your infrastructure.
Replace the FullStory snippet with an open-source recording setup that ships data to your own server. The fastest path is <TempsAnalyticsProvider enableSessionRecording={true} /> in a React or Next.js app — Temps is a self-hosted platform that bundles session replay (built on rrweb) together with web analytics, error tracking, and deployments in a single Rust binary, so recordings land in your own PostgreSQL database instead of FullStory's servers. If you'd rather build it yourself, install rrweb directly and write a small server endpoint to receive, compress, and store the events — that path takes more code but gives you full control over storage and retention. Either way you get the same core capability: DOM snapshots, mouse and scroll tracking, and console capture, without FullStory's $300+/mo starting price or its data leaving your infrastructure.
Temps is built for exactly this: it combines web analytics, session replay, error tracking, uptime monitoring, and deployment hosting in one self-hosted Rust binary, so every event, recording, and error stays on your own server instead of a third party's. Because it's one binary rather than four separate SaaS tools stitched together, there's no cross-vendor data sharing to audit and no consent-banner ambiguity about which vendor sees what — the data never leaves your infrastructure in the first place. PostHog's self-hosted edition covers analytics and replay with a similar privacy posture, but needs Kafka, ClickHouse, and Redis to run; Temps runs on a single server, with Temps Cloud available at roughly $6/mo (Hetzner cost plus 30% margin) if you'd rather not manage the box yourself.
Yes. Session replay is one of the easier observability tools to self-host because the recording engine — rrweb — is already open source and runs entirely in the browser; only the storage and playback backend needs a server. Two paths get you there: build your own pipeline on rrweb (client library plus a server endpoint to receive, compress, and store events), or use a platform that already bundles it. Temps includes session replay as a built-in feature of its self-hosted deployment platform — enable it with <TempsAnalyticsProvider enableSessionRecording={true} /> in React and recordings are stored in your own PostgreSQL database, never on a third-party server. OpenReplay and PostHog also offer self-hosted session replay, though both require more backend infrastructure (Kafka, ClickHouse, Redis) than Temps needs. For a broader rundown of self-hosted options beyond these three, see 7 Best Self-Hosted Session Replay Tools.
FullStory's pricing starts around $300/mo and scales into the thousands based on session volume. The cheaper alternatives fall into three groups: free but hosted by someone else (Microsoft Clarity — no cost, but data goes to Microsoft's servers, no self-hosting option); free and self-hosted, but infrastructure-heavy (OpenReplay and PostHog's self-hosted editions — no software license fee, but you run PostgreSQL, Redis, Kafka, and ClickHouse yourself); and free to self-host with minimal infrastructure (Temps — session replay, analytics, and error tracking run in one binary on one server, with Temps Cloud available at roughly $6/mo, which is the underlying Hetzner server cost plus 30% margin, with no per-session fees). If your goal is specifically the lowest total cost with the least infrastructure to babysit, that third category is the one to evaluate first.
A compressed 5-minute session typically uses 250-400KB of storage. At 1,000 sessions per day with 30-day retention, expect roughly 8-12GB of storage per month. Sampling at 10% reduces this to under 1GB. TimescaleDB's built-in compression can reduce storage further — Timescale reports up to 95% compression ratios for time-series data.
The recording overhead is minimal — according to rrweb's benchmarks, recording adds 1-3% CPU impact during active recording. The initial DOM serialization takes 50-200ms depending on page complexity, but it happens once per page load and doesn't block rendering. The script itself adds approximately 40KB gzipped to your bundle. Network overhead averages 1-5MB per session, sent in small batches via the Beacon API.
Yes, if the data stays on your own infrastructure and you implement proper masking. Self-hosted session replay with input masking and PII-aware DOM blocking avoids the third-party data transfer issues that triggered enforcement actions against tools like Google Analytics. The French CNIL has specifically noted that tools processing data on the site owner's own servers present a different compliance profile than those transferring data to third parties. Always mask input fields and sensitive rendered content.
FullStory offers advanced features like frustration detection (rage clicks, dead clicks), searchable session metadata, and AI-powered insights. A self-hosted setup with rrweb gives you recording, playback, and privacy masking — the core functionality that covers 80-90% of debugging use cases — without sending user data to a third party. For a side-by-side comparison of pricing and features across 6 tools, see 6 Best FullStory Alternatives.
Yes. Microsoft Clarity is free for session replay and heatmaps, though data goes to Microsoft's servers. OpenReplay is open-source and self-hostable at no software cost, though it requires running multiple backend services. Temps is also free to self-host — the Community edition is fully open source. On Temps Cloud, the cost is approximately $6/month covering the underlying Hetzner server cost plus 30% margin.
Session replay is too useful to skip. But it doesn't require a SaaS subscription or shipping raw DOM data to a third-party server. The open-source tooling — particularly rrweb — is mature enough to build on, and the self-hosted options keep improving.
If you want the debugging power of session replay without the infrastructure headaches, the simplest path is a platform that bundles replay alongside your deployment pipeline. Record sessions, play them back in the same dashboard where you manage deployments, and keep every byte of data on your own server.
Temps includes session replay, web analytics, error tracking, and deployment tooling in a single binary. Install it, enable replay with one flag, and you're recording — no FullStory invoice, no Hotjar session caps, no data leaving your infrastructure.
curl -fsSL https://temps.sh/install.sh | bash