GlitchTip vs Sentry

Most "GlitchTip vs Sentry" searches are not really about GlitchTip against Sentry's hosted service. They are about a narrower question: Sentry's own server can be self-hosted, so why would anyone run a different one? The answer is the size of the box. Self-hosted Sentry is nearly the full Sentry platform on one machine, and its documented floor is 16 GB of RAM plus 16 GB of swap. GlitchTip accepts events from the same open-source Sentry SDKs and recommends 512 MB. Everything else in this comparison follows from that gap.

Three ways to get Sentry-style error tracking

Sentry (hosted) is the SaaS at sentry.io. You install an SDK, point it at a DSN, and exceptions, stack traces, releases, and alerts show up in Sentry's cloud. The product has grown well past error tracking: its pricing page lists error monitoring, tracing, session replay, profiling, logs, metrics, cron monitoring, and uptime monitoring, plus an AI debugging tool called Seer. There is a free single-user Developer plan. Paid plans include a monthly quota of errors, spans, and replays, and you pay more as you send more.

Sentry (self-hosted) is the same codebase packaged by the getsentry/self-hosted repository. You clone it and run its bash install.sh, which sets up a Docker Compose stack of Sentry's services, including Kafka, ClickHouse, Redis, PostgreSQL, and Snuba. Sentry's own docs ask for 4 CPU cores, 16 GB of RAM plus 16 GB of swap, and 20 GB of free disk, and recommend 32 GB of RAM. They are also candid about who it is for. They call it "a minimal setup that works out-of-the-box for simple use cases" with "no guarantees or dedicated support", and a blueprint for "folks willing to maintain larger installations."

GlitchTip is a separate open-source project that speaks the Sentry event protocol. Its docs tell you to "install the sentry SDK for your platform" and paste GlitchTip's DSN, so application code doesn't change. The server is a Django app that needs PostgreSQL 14 or newer and one service. That service can run web and worker roles together (all_in_one), or you can split them to scale. Valkey or Redis is optional but recommended. GlitchTip recommends 512 MB of RAM and lists 256 MB as the minimum for the all-in-one setup.

Licensing: open source vs. Fair Source

GlitchTip is MIT licensed.

Sentry's server and the self-hosted repository are both under the Functional Source License 1.1 with an Apache 2.0 future license (FSL-1.1-Apache-2.0). Sentry calls this "Fair Source". Running it for your own company's internal use is permitted. What the license forbids is a "Competing Use": offering the software to others as a commercial product or service that substitutes for Sentry. Each release becomes Apache 2.0 two years after it is published. For a team self-hosting error tracking for its own apps, that restriction is unlikely to matter. It does mean self-hosted Sentry is not open source in the OSI sense today, and GlitchTip is.

Footprint: 512 MB against 16 GB plus swap

This is the reason the comparison exists. Self-hosted Sentry runs the pipeline that powers sentry.io — Kafka for ingestion, ClickHouse and Snuba for queries, and the processing services around them — on one host. Sentry offers an errors-only Compose profile (from version 24.8.0), set with COMPOSE_PROFILES=errors-only in .env. It keeps issues, alerts, integrations, dashboards, and releases, and drops traces, profiles, replays, crons, user feedback, and application metrics. Its docs describe it as a lightweight option "with an emphasis on minimizing system resources" but do not publish a separate hardware floor for it. Plan for the documented 16 GB.

GlitchTip's official Compose file has three services: PostgreSQL, Valkey, and one GlitchTip container in all_in_one mode. The file's own comments say that to target 256–512 MB you can drop Valkey (PostgreSQL then handles the task queue and cache) and switch off log ingestion and uptime monitoring. That fits on the smallest VPS tiers. Self-hosted Sentry needs a much larger server.

Features: where Sentry is ahead

GlitchTip's own feature list covers error tracking, performance monitoring, uptime monitoring, and logs. Its SDK docs support traces for performance data, source maps and debug symbols through the CLI, and log ingestion over OpenTelemetry. They also state that "GlitchTip does not support session tracking", and tell you to set auto_session_tracking to false. Session replay, profiling and Sentry-style cron check-ins are not on GlitchTip's feature list (its uptime monitoring does accept scheduled heartbeat pings); if your team relies on them, Sentry provides them hosted or self-hosted. Seer, Sentry's AI debugger, is hosted-only — Sentry's docs list it as unavailable on self-hosted.

The Sentry SDKs are the part both sides share, so trying GlitchTip costs little: change the DSN, and your existing instrumentation reports to the new server. The reverse works too: moving back to Sentry is also a DSN change for your applications.

Ops burden

Hosted Sentry has nothing to operate. Self-hosted Sentry has the most to operate of the three: Sentry says upgrades go through the same install script, and you keep Kafka, ClickHouse, and PostgreSQL healthy on one large host yourself. GlitchTip is in between. It is a PostgreSQL-backed Django app you back up like any other PostgreSQL database, with a standard Compose file and a Helm chart for Kubernetes. GlitchTip also runs its own hosted service if you want its feature set without running a server.

Which to choose

Choose hosted Sentry if you want the full product (replay, profiling, Seer, crons) and don't want to run anything. Accept that the bill grows with event volume.

Choose self-hosted Sentry if you need Sentry's feature set (no Seer) on your own infrastructure, for data-residency or policy reasons. You also need a 16–32 GB server and someone willing to maintain a multi-service stack that Sentry itself says comes with no guarantees.

Choose GlitchTip if what you actually use is errors, stack traces, releases, and alerts, maybe with basic performance and uptime checks. It keeps your existing Sentry SDKs and runs on a small VPS, under an MIT license.

Running GlitchTip on a VPS

The GlitchTip page has the official Compose install, which we have verified on Ubuntu 26.04. Set GLITCHTIP_DOMAIN and EMAIL_URL before real use, and put a reverse proxy in front for TLS. If GlitchTip still feels like more than you need, Bugsink vs. GlitchTip compares it with an even smaller single-container tracker. For every self-hosted option we list against Sentry, see Sentry alternatives.