highlight.io: self-hosting a full-stack monitoring platform without the per-seat invoice
highlight.io: The open source, full-stack monitoring platform. Error monitoring, session replay, logging, distributed tracing, and more.
At a glance
- What is it?
- Highlight bundles session replay, error monitoring, logs and traces into one TypeScript and Go codebase that you can run yourself. The hobby Docker path is the interesting part, and its stated ingestion ceilings are the part to read before you commit.
- Who is it for?
- Adopt highlight if you want session replay correlated with errors and server logs in one place and you are willing to run it yourself. Do not adopt it if you need a formally reviewed licence or a deployment that scales past the documented hobby ceilings without a support contract.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 26 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap highlight is trying to close: replay, errors and logs in one query
Most teams assemble observability from parts. A replay tool records the browser. An error tracker groups exceptions. A log pipeline stores server output. Each has its own SDK, its own dashboard and its own way of naming a user. When something breaks, you copy an identifier from one tool into another and hope the timestamps line up.
Highlight's pitch is that these are one product. The README describes session replay, error monitoring, logging and distributed tracing as a single feature set, and the selling point it repeats is embedding: errors shown next to the session that produced them, logs linked back to sessions and errors, traces searchable the same way as logs. That correlation is the actual product. It is also why the project is TypeScript and Go rather than a thin wrapper around someone else's backend.
The audience is a small engineering team that already knows it wants replay, that has been quoted per-seat or per-session pricing it does not like, and that has someone comfortable running Docker Compose and reading a .env file. It is not aimed at a platform team that wants a managed control plane.
What the hobby deployment actually asks of your machine
The README gives a three-line path. Clone with submodules, change into docker, run the script:
git clone --recurse-submodules https://github.com/highlight/highlight cd docker && ./run-hobby.sh
The submodule flag matters. On git older than 2.13 the README points you at git submodule update --init --recursive instead. If you clone without it, the compose stack will be missing pieces and the failure will not be obvious.
The stated resource floor is at least 8GB of RAM, 4 CPUs and 64GB of disk. That is the number to weigh first, because it is a fixed cost regardless of traffic. A single 8GB VM is a real monthly bill, and 64GB of disk fills faster than people expect when you are storing replay payloads.
Access is at https://localhost after the frontend loads. Login uses any valid email address plus the password set in the docker/.env variable ADMIN_PASSWORD. There is no user database to seed by hand and no default credential printed to the console. If you lose that value you are editing the file and restarting.
The README also points at a separate enterprise self-hosted path described as scalable and production-ready with vendor support. That is the honest split: the hobby script is a single-node evaluation, and the documentation for anything larger lives behind the enterprise page.
The ingestion ceilings are the real specification
The README states the hobby instance is good for fewer than 10k sessions and fewer than 50k errors ingested monthly. This is the most useful sentence in the whole document, and it is also the one most likely to be skimmed past.
Those numbers describe a small application, a staging environment, or a pilot on one product surface. A consumer web app with a few thousand daily active users will cross 10k sessions in days, not months. When you cross it, the README does not promise graceful degradation, backpressure, or a warning banner. It points to a docs page on self-host-hobby limitations, which is where the actual failure behaviour would be documented. Treat the ceiling as a boundary you plan around rather than a threshold you discover in production.
The error figure is the tighter constraint in practice for a backend service. Fifty thousand errors a month sounds generous until a retry loop or a bad deploy produces thousands per hour. Highlight's own grouping and alerting features exist precisely because error volume is bursty, and a burst is exactly the scenario a fixed monthly ceiling handles worst.
Session replay is rrweb under the hood, and that shapes the payload
The README credits rrweb for the DOM-based replay. That is a concrete architectural fact with consequences. Replay is captured as DOM mutations and interaction events reconstructed in the browser, not as video. It gives you fidelity on layout and input without the bandwidth of a screen recording, and it is why the replay view can show console output and outgoing network requests alongside the visual timeline.
The same design means replay payloads scale with how much your DOM changes, not with how long a session lasts. A dashboard that re-renders constantly produces far more data than a mostly static page. On a 64GB disk with a 10k session ceiling, that variance is the thing that decides whether you hit the disk limit or the session limit first.
It also means replay is a browser-side feature. The README frames session replay around frontend sessions, with errors and logs embedded into them. If your problem is a batch job or a queue consumer with no browser in the picture, replay contributes nothing and you are carrying its storage cost for the other features.
Where a self-hosted instance stops being the right answer
The clearest limitation is the one the README states about itself. There are two self-hosted tiers, and the free one has published ceilings. Anything past those ceilings routes through the enterprise path, which means contacting the vendor. If your requirement is a fully self-supported deployment at production scale, the open repository does not describe how to get there.
The second is the licence. The repository metadata reports NOASSERTION, which means GitHub could not match the licence file to a known identifier. That is not a statement that the licence is restrictive or permissive. It is a statement that you cannot tell from the metadata, and anyone who needs a reviewed licence before adoption has to open the licence file and read it, or ask the vendor. Do not infer terms from the word open source in the README.
The third is operational surface. A stack that covers replay, errors, logs and traces is not one process. Running it means owning upgrades, storage growth and whatever the submodules bring in. The release cadence visible in the material is telling: the docker-tagged releases listed are docker-v0.5.6 in August 2025, docker-v0.5.5 in June 2025, and docker-v0.5.4 in February 2025. Three releases across roughly six months. That is not a project shipping weekly, and it is not abandoned either. Plan upgrades as occasional, deliberate events rather than a continuous stream.
How this differs from assembling Sentry, OpenTelemetry and a replay tool
The obvious alternative is the combination most teams already run: an error tracker such as Sentry for exceptions, OpenTelemetry for traces and logs, and a separate replay product. The difference is not feature coverage. It is where the join happens.
With separate tools, correlation is something you build. You attach a session identifier to your error events, propagate a trace ID into your logs, and configure each backend to accept and index those fields. The data model is yours to design and yours to keep consistent across SDK versions.
Highlight's approach is that the join is the schema. Sessions, errors, logs and traces are stored together, and the README's feature descriptions are written in terms of embedding one inside another rather than exporting between systems. You get correlation without building it, and you give up the ability to swap one component. If Highlight's error grouping rules do not fit how you triage, you cannot replace just that piece the way you could replace a standalone tracker while keeping your log pipeline.
That trade is worth naming plainly. A single-vendor stack is cheaper to operate and harder to partially exit.
Upgrading and the cost of staying current
The material supports a limited but useful statement here. Docker-tagged releases are the versioned artifacts, and the gap between docker-v0.5.4 in February 2025 and docker-v0.5.6 in August 2025 suggests a maintenance rhythm measured in months, not weeks. A self-hosted operator should expect to schedule upgrades rather than pull continuously.
Because the hobby deployment is a compose stack driven by docker/.env, the upgrade path in practice involves pulling new images and reconciling that file against whatever keys the new version expects. The README does not document a migration procedure or a schema versioning scheme, and I cannot confirm from this material whether one exists. That is a real gap for anyone planning a long-lived instance.
The licence question sits alongside it. NOASSERTION means the terms are not machine-identifiable, so the cost of adoption includes reading the licence file and deciding whether it fits your distribution model. That is not legal advice and it is not a red flag. It is simply an unresolved item that a procurement process will surface, and it is better to surface it before the deployment than after.
Editorial conclusion
Adopt highlight if you want session replay correlated with errors and server logs in one place and you are willing to run it yourself. Do not adopt it if you need a formally reviewed licence or a deployment that scales past the documented hobby ceilings without a support contract. Before you clone, check the docker/.env file for ADMIN_PASSWORD, confirm whether the submodules pulled cleanly with git submodule status, and read the self-host-hobby docs page for the stated session and error limits.
Community notes