Best Self-Hosted Sentry Alternatives in 2026: GlitchTip, Bugsink, urgentry, and HyperDX Compared

Four open source or source-available tools now accept Sentry SDK traffic without requiring Sentry’s infrastructure. The right choice depends on one question: what is your actual constraint? Community maturity, operational simplicity, documented throughput, or a full observability stack that goes beyond errors?

Short routing: GlitchTip for the most established Sentry-compatible project with the longest track record. Bugsink for the smallest operational footprint on errors only. urgentry for the highest published throughput at the lowest documented memory. HyperDX for teams who need logs, traces, metrics, and session replays alongside error tracking in a single backend.

The full breakdown is below, with every resource figure traced to a primary source.

Disclosure: we build urgentry, which appears in this comparison. That is a reason to read this skeptically. Every number here traces to a cited source, competitors’ genuine advantages are named plainly, and urgentry is placed where its documented evidence puts it, not ahead of that evidence.

What “self-hosted Sentry alternative” means here

Sentry’s self-hosted offering is a Docker Compose stack that defines approximately 70 services in its current docker-compose.yml (confirmed from github.com/getsentry/self-hosted, accessed 2026-06-26; the count has grown substantially across Sentry releases and is far higher than commonly cited figures). Its documentation sets a 16 GB RAM minimum; operators routinely need 24–32 GB under real ingest workloads. The services include ClickHouse, Kafka, ZooKeeper, Postgres, Redis, Snuba, Symbolicator, and more, each requiring separate memory allocation and operational attention.

Every tool in this roundup is a Sentry-SDK-compatible self-hosted alternative: you point your existing Sentry SDK at a different DSN and your instrumentation keeps working without code changes. That is the defining characteristic of this category. Tools that require re-instrumentation are a different decision entirely, covered in the logs vs traces vs errors guide.

Two tools not included: Highlight.io (stopped accepting new signups; the open source project shifted direction, see the migration path off Highlight.io) and SigNoz (OTel-first APM platform where error tracking is secondary to traces and metrics, and it does not accept Sentry envelopes natively).

How we selected these four tools

Selection criteria:

1. Accepts Sentry SDK envelopes by DSN swap (no re-instrumentation required, or clearly documented OTel bridge)
2. Can be self-hosted, not only offered as managed SaaS
3. Actively maintained as of mid-2026
4. Has published documentation covering its resource requirements or deployment architecture

Resource and feature comparison

This table is the information-gain element of this piece: documented resource figures across all four tools in one place. “Not published” is not an estimate; it means the tool’s own official documentation does not state a figure. Benchmark conditions for urgentry are specified below the table.

urgentry benchmark conditions: 8 vCPU, 30.6 GiB RAM, 226 GB root disk, Ubuntu 24.04, April 13, 2026 (benchmark page last updated June 21, 2026). Source: urgentry.com/docs/benchmarks/. These figures are from urgentry’s own benchmark, not an independent lab: read them as a starting point for sizing, not a guarantee.

One pattern stands out: urgentry is the only tool in this group that publishes throughput and memory figures under a disclosed methodology. GlitchTip, Bugsink, and HyperDX have not released equivalent benchmarks. That does not mean they perform worse. It means the data is not available for comparison, and any figure published for those tools by a third party would be speculation.

GlitchTip

GlitchTip is the most established open source Sentry alternative by release history. It runs on Django, uses PostgreSQL for persistence, and Valkey or Redis for background task queuing via Celery. The architecture mirrors what many Python teams already operate, which lowers the learning curve for teams with existing Django infrastructure.

Resource footprint: GlitchTip’s own installation documentation sets a 256 MB RAM floor for the all-in-one deployment, with 512 MB recommended. A one-million-events-per-month instance is estimated at roughly 30 GB of disk. That floor is dramatically lower than Sentry self-hosted’s 16 GB, but GlitchTip requires four to five separately managed services: a web process, a Celery worker, Postgres, and Redis (plus an optional migration service). Each of those has its own update cycle, backup requirement, and failure mode.

Feature scope: Error tracking and basic performance monitoring. No session replay, no continuous profiling. It covers the core error-tracking use case (grouping, alerting, release tracking, environment filtering) at a resource cost that fits on modest infrastructure.

License: MIT. Confirmed from the GlitchTip backend repository LICENSE file (gitlab.com/glitchtip/glitchtip-backend, accessed 2026-06-26).

Genuine advantages: The longest community history of any tool here, which translates to more solved edge cases in GitHub Issues and more community-written deployment guides. MIT licensing means no usage restrictions for self-hosting teams.

Honest limitation: GlitchTip does not publish throughput or latency benchmarks. There is no public figure for how many events per second it handles on a given host, which makes capacity planning imprecise. Four-service deployments mean more moving parts to coordinate during upgrades than single-binary or single-container alternatives.

More detail at urgentry vs GlitchTip.

Bugsink

Bugsink’s pitch is operational minimalism: a single Docker container pointed at an external database. There is no worker process, no Redis, no message broker. You run docker run bugsink/bugsink, point it at Postgres or MySQL, and it accepts Sentry SDK errors.

Resource footprint: Bugsink’s documentation does not publish a specific RAM figure. Based on the Django and Gunicorn stack, light production workloads run in the low hundreds of MB, but this is an inference from the technology, not a published number from Bugsink itself. No throughput benchmarks exist in Bugsink’s public documentation.

Feature scope: Error tracking with stacktrace analysis, automatic issue grouping, alerting, source map support, and per-release/environment filtering. No distributed traces, no log aggregation, no session replay. The scope is intentionally narrow: Bugsink is an errors-first tool and does not position beyond that boundary.

Database note: Bugsink’s single-container claim requires qualification. The container itself is one unit, but an external database process (Postgres or MySQL) is required for any persistent deployment. That is still meaningfully simpler than GlitchTip’s four-service minimum, but it is not a zero-external-dependency deployment the way urgentry’s Tiny mode is.

License: PolyForm Shield License 1.0.0. Confirmed from the Bugsink repository LICENSE file (github.com/bugsink/bugsink, accessed 2026-06-26). The repository also includes Sentry-derived code under the BSD 3-Clause License. PolyForm Shield permits self-hosting for internal use but prohibits providing Bugsink as a managed service that competes with the developer. Teams in commercial or compliance contexts should review the current terms directly.

Genuine advantages: Operationally the simplest self-hosted error tracker in this list for teams whose requirements end at errors. A single container is easier to update, back up, and reason about than a multi-service stack. The single binary vs Docker Compose tradeoff covers this class of decision in detail.

Honest limitation: The feature ceiling is the lowest of the four tools. If your roadmap includes distributed traces, log aggregation, or session replay, Bugsink will not grow with it and you will need a second backend. No published benchmark means you cannot estimate headroom before provisioning.

More detail at urgentry vs Bugsink.

urgentry

urgentry is a single Go binary that implements 218 of 218 Sentry API operations (sourced from a scan of Sentry’s public API specifications; not independently audited). The migration path is one environment variable change: point the Sentry SDK’s DSN at your urgentry host. No code changes. No re-instrumentation.

It ships in two modes. Tiny mode uses SQLite and targets a $5–20/month VPS, a deliberate design decision documented in Tiny mode. Self-hosted mode uses Postgres and S3-compatible object storage for larger teams.

Resource footprint (April 13, 2026 benchmark, 8 vCPU / 30.6 GiB RAM / Ubuntu 24.04):

On a smaller box, Tiny mode used 44.8 MB peak RSS. Full methodology and raw numbers are at urgentry.com/docs/benchmarks/. Read how to interpret self-hosted benchmarks before treating these as production guarantees: benchmark conditions never exactly match real deployments.

Feature scope: Errors, distributed traces, session replay, and continuous profiling. The compatibility coverage (218/218 Sentry operations) means urgentry handles what most Sentry SDK configurations actually send, even if it does not implement every edge-case operation at full parity.

License: FSL-1.1-ALv2. Source-available, not OSI-certified open source. Self-hosting is permitted; building a competing SaaS product on top of urgentry is not. Teams with open-source licensing requirements should evaluate this carefully.

Genuine advantages: The only tool in this list with a published, methodology-disclosed throughput and memory benchmark. Runs on the smallest documented hardware footprint of any option here in Tiny mode. DSN-swap migration means zero re-instrumentation cost.

Honest limitation: The benchmark is self-produced by the urgentry team, not an independent third-party test. The project has a smaller community than GlitchTip. FSL-1.1-ALv2 is not an OSI-approved open source license, which matters for some procurement policies and organizations with strict open-source requirements.

HyperDX

HyperDX is not an error tracker that also does other things: it is a full observability backend where errors are one signal among several. Logs, distributed traces, metrics, session replays, and errors all land in ClickHouse and are queryable from a single UI. The project has 9.6k GitHub stars (as of June 2026) and is now part of ClickStack following an acquisition by ClickHouse.

Resource footprint: The HyperDX repository recommends at least 4 GB RAM and 2 CPU cores for testing. The standard Docker Compose deployment includes ClickHouse, the HyperDX application, an OpenTelemetry Collector, and MongoDB: four services with their associated data volumes. For teams who only need error tracking, that is substantial infrastructure to operate something the other three tools accomplish on far less.

Sentry SDK integration: HyperDX accepts Sentry SDK data via an OpenTelemetry Collector bridge, not native Sentry envelope processing. This works, but it adds a translation layer and means the integration path is less direct than tools that implement the Sentry envelope protocol natively.

License: MIT, the most permissive license in this group and the only OSI-certified open source option that matches HyperDX’s full feature scope.

Genuine advantages: If you want logs correlated with traces correlated with errors and session replays in a single query surface, HyperDX is the only tool here that covers the full stack. ClickHouse as the storage backend is a proven choice for high-cardinality time-series data. The MIT license removes any usage restriction concern.

Honest limitation: For teams whose only requirement is error tracking, HyperDX’s architecture adds operational weight without proportional benefit. The ClickHouse acquisition is recent; the effect on long-term project governance and roadmap is still playing out. The 4 GB RAM minimum makes it unsuitable for the $5–20/month VPS tier where urgentry’s Tiny mode and GlitchTip’s all-in-one both operate.

More detail at urgentry vs HyperDX.

How to choose

Pick GlitchTip if you want the most established open source project in this category, need the longest community history for support and edge-case documentation, and are comfortable managing a four-service stack.

Pick Bugsink if error tracking is your entire requirement, you want the lowest-friction self-hosted deployment, and you are not planning to add distributed tracing or log aggregation. A single container connected to an existing Postgres instance is as simple as this category gets.

Pick urgentry if you are migrating off Sentry without re-instrumentation, care about documented resource efficiency with a disclosed methodology, or are deploying on minimal hardware (Tiny mode, $5–20/month VPS). Also the right fit for compliance-driven teams who need all error data on their own infrastructure with a minimal attack surface. See self-hosted Sentry alternative for a deeper look at the migration path.

Pick HyperDX if you want one backend for logs, traces, metrics, session replays, and errors, have at least 4–8 GB of RAM to allocate to observability, and prefer an MIT-licensed project.

None of the above fits if you need managed infrastructure: if operational simplicity means “someone else runs it,” then Sentry cloud or a SaaS alternative is the appropriate answer. Self-hosting any of these tools means owning the ops.

Frequently asked questions