A self-hosted Sentry alternative built for React teams
Clone the repo, run make up, point the SDK at your own box. Errors, rrweb session replays, API latency and release regressions stay on infrastructure you control.
Why teams look past Sentry
Sentry is a good product with an enormous surface: dozens of languages, runtimes, frameworks and integrations. That breadth is exactly why the self-hosted install is heavy. It brings up a long list of services, and once they are up they are yours to upgrade, back up, and debug at 3am. A team whose entire product is a React app ends up operating a platform sized for everyone else's stack too.
The second reason is quota shape. Event-priced hosted plans meter the events you least want to drop: the storm after a bad deploy. Sampling down at exactly the moment something is on fire is a bad trade. Self-hosting turns a billing decision back into a disk decision.
Remetry is narrower on purpose. One browser SDK, one compose stack, one dashboard with six screens: Errors, Performance, API, Replays, Releases, Settings. If your backend is Go, Python or Rust, Remetry has nothing for it — that is the trade that keeps self-hosted error tracking a one-engineer job.
Remetry, self-hosted Sentry, and the small alternatives
Publicly documented differences only. Check each project's own docs — all of them move.
| Remetry (self-hosted) | Self-hosted Sentry | GlitchTip / Bugsink | |
|---|---|---|---|
| Session replay | rrweb replay attached to the error it belongs to. On-error mode keeps a ring buffer and ships only the moments around the crash. | Part of the platform, and one more subsystem to run and store. | Error tracking only — no session replay. |
| React symbolication | Source maps uploaded from CI by @remetry/cli; fingerprints computed over the symbolicated stack, so issues survive a rebuild. |
Supported, alongside dozens of other languages and runtimes. | Varies by project and version — check their docs. |
| Release regression detection | Every deploy is diffed against the one before it: error rate by a traffic-normalised two-proportion z-test, LCP p75 by an effect-size threshold, both gated on sample floors. | Release health is part of the product. | Not part of the feature set. |
| API latency monitoring | Opt-in plugin patches fetch and XHR; URLs normalise server-side (/orders/123 → /orders/:id) into per-endpoint P75/P95 and error rate. |
Performance monitoring is part of the platform. | Focused on errors. |
| License | FSL-1.1 with an Apache 2.0 future grant. Source-available, not OSI open source. | Also source-available — read their current LICENSE. | Open-source licensed; terms differ per project. |
| Deploy method | git clone then make up. One compose stack: Go ingestion and worker, ClickHouse, Postgres, Redis, MinIO, dashboard. |
Official self-hosted installer; many services to operate. | Docker images, deliberately small stacks. |
Two ways to run it
Same code either way. Self-host when the data must not leave your network; use the cloud when you would rather not own another database.
Your own box
Docker and Docker Compose are the only requirements. The migration runner applies pending SQL before anything starts, so upgrades are another make up.
Remetry Cloud
Sign up, create a project, take the DSN, ship. We run ingestion, storage and the dashboard.
- No infrastructure to operate
- TLS, backups and upgrades handled
- Project-scoped API keys and team access
FSL-1.1 now, Apache 2.0 in two years
Remetry is source-available error tracking, not open source, and the distinction matters enough to spell out. The Functional Source License 1.1 grants you the source and the right to use, modify and self-host it for almost anything, including commercial use inside your own company. The single carve-out is offering Remetry to others as a competing product or service.
That one restriction is why the OSI definition does not cover it: open source forbids field-of-use limits, and FSL has one. So we say source-available. Two years after a version ships, that version converts to Apache 2.0 — a real OSI license, granted in advance and in writing, not a promise in a blog post.
So if you searched for an open source Sentry alternative in the strict OSI sense, Remetry is not one, and GlitchTip or Bugsink are the honest answer when the license itself is the requirement. If what you need is the source, the right to self-host, and nobody else holding your error data, FSL-1.1 gives you all three today.
rrweb, which does the actual session recording, is open source under MIT and stays that way regardless of what we do.
Questions we get about self-hosting
Is Remetry open source?
No, and we will not call it that. Remetry is source-available under the Functional Source License 1.1. You can read, modify, self-host and run it commercially inside your own company; you cannot resell it as a competing error-tracking service. Each version converts to Apache 2.0 two years after it ships. rrweb, the library behind our session replay, is genuinely open source under MIT.
What do I need to self-host it?
Docker and Docker Compose. Clone the repository, copy .env.example to .env, run make up to build and start the stack, then make smoke to send a test error and confirm it landed in ClickHouse. Go and pnpm are only needed if you build outside containers.
Does Remetry accept events from the Sentry SDK?
No. Remetry has its own browser SDK, @remetry/browser, and its own wire contract. Migrating means swapping the SDK init in your app, not repointing a DSN.
Can I start on the cloud and move to my own infrastructure later?
Yes. Both run the same code. Self-hosting changes the endpoint you pass to init() and puts the ClickHouse, Postgres, Redis and MinIO volumes on your side of the network boundary.
Own the whole data plane
Two commands to a running stack, or one signup if you would rather not.