Highlight.io
Open-source session replay and product monitoring
Highlight.io is an open-source observability platform combining session replay, error monitoring, and logging for web applications. It can be self-hosted to keep user analytics and debugging data in-house.
Key features
- Session replay
- Error monitoring
- Log management
- Distributed tracing
Pros & cons
Strengths
- Unified front-end observability
- Self-hostable
Trade-offs
- Heavy infrastructure
- Complex setup
Highlight.io replaces
Last reviewed Aug 26, 2026 · 820 words
Highlight.io's self-hosted "hobby" deployment starts around 8 containers, of which ClickHouse, PostgreSQL, Kafka and Redis are the ones you will end up babysitting, and 4 GB of RAM is the floor before a single session is recorded. That is the review in one line: the product is genuinely good, the infrastructure is the cost, and whether the first justifies the second is the whole question for a self-hoster.
What "unified" buys you that lighter tools do not
Highlight records browser sessions (a DOM replay, not video), captures front-end and back-end errors, ingests logs, and accepts traces over OpenTelemetry. The value is the links between them: click an error and you land in the replay at the moment it fired, with the network waterfall alongside and the backend logs and spans for that request one tab over. Sentry does errors with a replay bolted on; PostHog does replay with product analytics; SigNoz does logs and traces with no replay. Highlight is the one where a support ticket saying "the checkout button did nothing" turns into a 30-second investigation instead of a 30-minute one.
The hobby deploy, container by container
git clone --recurse-submodules https://github.com/highlight/highlight
cd highlight/docker
./run-hobby.sh
That script brings up PostgreSQL for metadata, ClickHouse for the big tables (sessions, logs, traces), Kafka as the ingest buffer, Redis, an OpenTelemetry collector on port 4318, the Go backend on 8082 and the React front end on 3000. Expect 10 to 20 minutes for the first run while images pull and ClickHouse migrates. On a 4 GB box it starts; on 8 GB it stays up under a real trickle of traffic. Disk grows with replay volume, and ClickHouse retention is the setting to find before, not after, the volume fills. The Hard rating is earned by the number of moving parts, not by any one of them.
Wiring an app is 5 lines; the privacy setting is the sixth
The browser SDK is one call:
import { H } from 'highlight.run';
H.init('your-project-id', {
backendUrl: 'https://highlight.example.com:8082/public',
privacySetting: 'strict',
});
backendUrl is the part self-hosters forget; without it the SDK reports to Highlight's cloud. privacySetting has 3 values: none records everything, default masks inputs, strict masks all text and images on the page. Start with strict and relax it per element. Server-side, the Node, Python, Go and other SDKs attach errors and logs to the same session, and anything that already emits OpenTelemetry can point at the collector on 4318 with no Highlight-specific code at all.
Recording what users do in your app is the reason to self-host this rather than send it to a vendor, and it is also the reason to be careful. Masking in strict mode keeps typed text out of the recording, but URLs, click targets and timing remain. Decide the retention period (30 days is the common answer), tell users in the privacy policy that sessions are recorded, and do not enable replay on pages with health, financial or legal content unless masking has been checked by a human. A self-hosted Highlight lets you make those calls; it does not make them for you.
Check the project's pulse before you commit
Highlight the company was acquired by LaunchDarkly, at last check, and the open-source repository has continued under Apache-2.0. Before building an on-call process around any self-hosted observability tool, look at the commit frequency over the last 90 days and whether the hobby deploy has a release from this year. That is 5 minutes and it is the difference between adopting a maintained project and inheriting one.
Compared with the neighbours
| Replay | Errors | Logs and traces | RAM floor | Setup | |
|---|---|---|---|---|---|
| Highlight.io | Yes, linked | Yes | Yes, OpenTelemetry | 4 GB | Hard |
| Sentry | Yes | Best in class | Traces, some logs | 16 GB | Hard |
| GlitchTip | No | Yes, Sentry SDKs | No | 1 GB | Easy |
| PostHog | Yes | Basic | No | 4 GB plus | Hard |
| SigNoz | No | Through traces | Yes, native | 4 GB | Medium |
If errors are the only need, GlitchTip on 1 GB is the honest answer. If product analytics matters more than debugging, PostHog. If you have no browser front end, SigNoz. Highlight wins only when replay plus backend correlation is the daily workflow.
What I'd do
For a small team shipping a web app with real users and a support inbox: run the hobby deploy on an 8 GB VM, set privacySetting to strict, set ClickHouse retention to 30 days, and point every service's OpenTelemetry exporter at the collector. For a homelab, a side project, or anything with under 1,000 daily users, skip it and run GlitchTip, because 8 containers of observability for an app that 10 people use is a hobby in its own right.
Compare Highlight.io
1 head-to-head comparisons.
Similar web analytics apps
Superset
Web AnalyticsModern data exploration and visualization platform
Replaces Tableau, Power BI
Metabase
Web AnalyticsOpen-source business intelligence and dashboards
Replaces Tableau, Looker
PostHog
Web AnalyticsOpen-source product analytics platform
Replaces Google Analytics, Mixpanel
Umami
Web AnalyticsSimple, fast, privacy-focused web analytics
Replaces Google Analytics
Postiz
Web AnalyticsSchedule posts, track the performance of your content, and manage all
Replaces Buffer, Hootsuite
Netron
Web AnalyticsVisualizer for neural network and machine learning models