Bugsink vs GlitchTip vs Self-Hosted Sentry: VPS Error Tracking in 2026

Self-hosting your error tracker used to mean one of two things: pay Sentry's SaaS bill every month, or surrender a chunk of your VPS to run Sentry's full open-source stack. In 2026 that binary has cracked open. Two lighter contenders — GlitchTip and Bugsink — now let you run real error tracking on the same cheap box that already serves your app, and the resource gap between them and self-hosted Sentry is enormous.

I run seven aggregator sites on Hostinger shared hosting plus a VPS, and across the 50+ projects we've shipped at Warung Digital Teknologi — Laravel APIs, Vue dashboards, Flutter apps — error tracking is the one piece of observability I refuse to skip. A 500 you never see is a customer you've already lost. This is a hands-on comparison of Bugsink vs GlitchTip vs self-hosted Sentry from the angle that actually matters when you're paying for the server: how much RAM each one eats, how painful the install is, and which one belongs on your VPS in 2026.

The short version: pick by your RAM budget, not your feature wishlist

Before the deep dive, here's the decision in one breath. If you have a $5 VPS and just want stack traces with alerts, run Bugsink. If you want a near drop-in Sentry replacement that your existing SDKs already speak to, run GlitchTip. If you genuinely need tracing waterfalls, session replay, and native mobile crash symbolication and you have a 16 GB box to spare, run self-hosted Sentry. Most small teams and solo developers fall into the first two buckets, and the third is where I see people over-provision and regret it.

Resource footprint: the number that decides everything

This is the single most important table in this article, because on a VPS your RAM ceiling is your wallet. Here is how the three stacks actually compare on minimum and recommended memory:

Read that Sentry row again. The minimum is 8 GB and the project itself recommends 16 GB plus 4 CPU cores for production. On Hetzner or Contabo that's a €15–€30/month dedicated box doing nothing but watching for your errors. By contrast, Bugsink's own benchmark claims it can chew through 1.5 million events per day on a €5 VPS with 2 vCPUs and 4 GB of RAM — and it does that with no Redis and no background queue at all.

In my experience the "single container, no queue" design is the part people underestimate. Every extra moving part — Redis, a Celery worker, a Kafka broker — is another process that can OOM-kill itself on a small box at 3 a.m. and silently stop ingesting events. When I provisioned monitoring for one of our client Laravel projects on a 2 GB VPS that was already running the app, the difference between "one Python process" and "four cooperating services fighting over the page cache" was the difference between something I could forget about and something I had to babysit.

Bugsink: the lean newcomer built for cheap boxes

Bugsink is a fresh implementation, not a Sentry fork, and it's deliberately narrow. It does one job: tell you when something broke and why, with a real stack trace and an alert. No dashboards full of vanity charts, no tracing, no uptime checks. It's a single Django app you can run as one container backed by SQLite for a hobby project, or MySQL/PostgreSQL for production. The simplest install is a single docker run command that finishes in under a minute.

The standout engineering decision is smart retention. Instead of forcing you to run manual cleanup cron jobs (a chore anyone who has self-hosted Sentry knows well), Bugsink automatically keeps a representative sample of events when volume spikes, so your disk doesn't balloon and your database doesn't grind. For someone like me running daily import scripts across 7 sites that occasionally throw the same exception 10,000 times in a burst, that automatic sampling is genuinely useful — I don't want 10,000 identical rows, I want to know it happened and see one clean trace.

License note: Bugsink is source-available under the PolyForm Shield License. You can run it in production, modify it, and contribute — the only restriction is you can't turn around and offer it as a competing hosted service. For 99% of self-hosters that restriction never matters.

Who it's for: solo developers, small teams, anyone running error tracking as a side process on a box that's already busy. If your honest answer to "do I need distributed tracing?" is no, Bugsink is the one I'd reach for first in 2026.

GlitchTip: the closest thing to a drop-in Sentry replacement

GlitchTip's superpower is protocol compatibility. It implements the Sentry SDK protocol, which means migrating an existing app is usually a one-line change: point your DSN at your GlitchTip instance and ship. No SDK swap, no code rewrite. If you already have sentry-sdk wired into a Django, Laravel, Node, or Vue app, GlitchTip will accept those same events. That's a huge deal — it's the difference between a migration that takes an afternoon and one that takes a sprint.

Architecturally GlitchTip keeps close to the original Sentry model but trims the fat: it runs on roughly four containers (web, a Celery worker, Postgres, and Redis) instead of Sentry's forty. It comfortably fits on a 2 GB VPS for small-to-mid volume, and the docs note it can technically start on as little as 256 MB. You get crash reports with stack traces, release tracking, and basic alerting — enough for teams up to roughly 50 engineers.

The current line as of this writing is the GlitchTip 6.x series (6.1 shipped in March 2026), and the project uses the permissive, OSI-approved MIT license — the most liberal of the three. If license purity matters to your org's legal team, GlitchTip is the cleanest answer here.

When I weigh GlitchTip against Bugsink, the deciding question is migration cost. If a project already emits Sentry-format events, GlitchTip wins on zero-friction switchover. If I'm starting from a blank slate and optimizing purely for the smallest possible footprint, Bugsink's single container edges ahead. The tradeoff I've seen in production is real but small: GlitchTip's Redis + Celery split gives you better burst handling, at the cost of two more processes to keep alive.

Self-hosted Sentry: powerful, heavy, and usually overkill

Let me be blunt, because good advice means saying the unpopular thing: most people self-hosting full Sentry don't need it. The modern Sentry architecture is 25+ microservices including Kafka, ClickHouse, and Snuba. That stack exists to power tracing waterfalls across services, Session Replay, profiling, native crash symbolication for Android/iOS/C++, and feature-flag integration. Those are real, valuable features — if you actually use them.

If you're a mobile shop shipping native crashes that need symbolication, or a microservices team that lives inside distributed traces, self-hosted Sentry is the right tool and nothing else here replaces it. But if you're running it to get stack traces and email alerts on a web app, you've bought a freight train to deliver a pizza. You're paying for 16 GB of RAM, four CPU cores, and the operational burden of keeping Kafka and ClickHouse healthy — to use maybe 10% of what you provisioned.

License note: since 2023 Sentry ships under the Functional Source License (FSL) — free to run, modify, and redistribute for anything except a competing commercial product, and each release converts to Apache 2.0 after two years. Not OSI-approved, but permissive enough for internal self-hosting.

The cost math: when does self-hosting beat Sentry SaaS?

This is the question that sends most people down the self-hosting road, so let's put real numbers on it. Sentry's hosted pricing in 2026 runs: Developer (free, 5K events/month), Team ($26/month for 50K events), and Business ($80/month for 100K events), with consumption-based overages on top. High-volume enterprises (10M+ events/month) negotiate contracts in the $50,000–$150,000+ range.

The inflection point where self-hosting pays for itself sits around 1–2 million events per month. Below that, the free Developer tier or a cheap Team plan is often less hassle than running your own box. Above it, a single $5–$15/month VPS running GlitchTip or Bugsink — both unlimited and free when self-hosted — pays back the setup time in a matter of weeks.

Here's the practical framing I use. Three real costs decide it:

• SaaS bill — predictable, scales with event volume, zero ops.
• VPS bill — flat $5–$30/month depending on which stack, unlimited events.
• Your time — the cost everyone forgets. Self-hosted Sentry's 25-service stack has real maintenance overhead; Bugsink's single container has almost none.

That third line is why I don't blanket-recommend self-hosting. If you bill $80/hour and self-hosted Sentry costs you four hours a month of upkeep, you've spent $320 to save an $80 SaaS bill. With Bugsink or GlitchTip, that maintenance line drops close to zero, which is what flips the math back in self-hosting's favor for small teams.

Decision matrix: which one for your situation

How I'd actually deploy this on a fresh VPS

Theory is cheap, so here's the concrete path I'd take on a brand-new Ubuntu 24.04 box. For Bugsink, the fastest production-ready start is a single container pointed at a real database rather than the default SQLite — on a 2 GB VPS I'd spin up MySQL or Postgres, then run the Bugsink container with the database URL and a base URL environment variable set. That's genuinely it: one container, one database, a reverse proxy in front for TLS. If you already run Caddy or Nginx (and on a busy box you do), adding a TLS-terminated subdomain like errors.yourdomain.com takes about five minutes.

For GlitchTip, I'd use the project's published docker-compose.yml, which wires up the web service, the Celery worker, Postgres, and Redis together. The one variable people forget to set is the email backend — without it, GlitchTip can't send you alerts, which defeats the entire purpose. Set your SMTP credentials (any transactional provider works) before you consider the install finished, and send yourself a test error from a throwaway script to confirm the full path works end to end.

A migration checklist I follow when moving an app off Sentry SaaS onto self-hosted GlitchTip:

• Stand up the instance first and confirm it accepts a test event before touching production.
• Swap the DSN in one low-traffic service, watch events land, then roll it out app by app.
• Don't dual-write long term — pick a cutover date so you're not paying Sentry and running your own box at once.
• Set retention deliberately; GlitchTip won't auto-sample like Bugsink, so a 30–90 day cleanup policy keeps Postgres lean.
• Back up the database — your error history is only as durable as your Postgres backups, so fold it into whatever backup routine the rest of your VPS already uses.

A note on running any of these on cheap shared/VPS hosting

One thing the comparison charts never mention: shared hosting won't run any of these. Error trackers need a long-running process and a real database, which means a VPS at minimum — Hostinger's VPS tiers, Hetzner Cloud, Contabo, or similar. If you're currently on shared hosting and want self-hosted error tracking, that's your real first step, and it's the same upgrade path I've written about for moving any app off shared hosting onto a VPS.

From running daily import jobs across 7 sites, the gotcha I'll flag: whatever you pick, put it on a separate small VPS from your production app if you possibly can. The whole point of error tracking is that it stays up when your app falls over. If your tracker shares a box with the app and the box runs out of memory, you lose visibility at the exact moment you need it most. A $5 Bugsink box sitting next to your app server is cheap insurance that the app server's death throes still get recorded.

Frequently asked questions

Is GlitchTip really a drop-in Sentry replacement?

For error tracking, effectively yes. Because it implements the Sentry SDK protocol, you change your DSN and existing Sentry SDKs send events to GlitchTip unchanged. What you don't get is Sentry's advanced features — tracing, session replay, profiling — so it's a drop-in for the error-tracking subset, not the full observability suite.

Can Bugsink handle production traffic on a $5 VPS?

Bugsink's published benchmark is 1.5 million events/day on a €5 VPS with 2 vCPUs and 4 GB RAM, using its smart-retention sampling to stay within disk and CPU limits. For most small-to-mid apps that's comfortable headroom. Very high-volume apps should still test against their own event rate.

Why is self-hosted Sentry so much heavier than the alternatives?

Sentry's stack includes Kafka, ClickHouse, and Snuba to power features beyond error tracking — distributed tracing, session replay, high-cardinality analytics. Those components carry the 8 GB minimum / 16 GB recommended footprint. GlitchTip and Bugsink skip that infrastructure entirely, which is exactly why they fit on a 2 GB box.

What about the licenses — can I use these commercially?

All three allow internal commercial self-hosting. GlitchTip is MIT (most permissive, OSI-approved). Bugsink is PolyForm Shield (you can't resell it as a competing hosted service). Sentry is FSL with a 2-year non-compete that converts to Apache 2.0. The only one that restricts is the "don't run a competing SaaS" clause in Bugsink and Sentry — irrelevant if you're just monitoring your own apps.

Should I self-host at all, or just pay Sentry?

If you're under roughly 1–2 million events/month and you value zero ops, Sentry's free or Team tier is often the smarter buy. Above that threshold, or if you have data-residency requirements, a self-hosted GlitchTip or Bugsink instance on a cheap VPS wins on cost — provided you factor in your own maintenance time honestly.

My verdict

After weighing all three against the only constraint that's real on a VPS — RAM you're paying for — my recommendation order for 2026 is straightforward. Start with Bugsink if you want the absolute smallest, lowest-maintenance footprint and you only need error tracking. Move to GlitchTip if you're already on Sentry SDKs and want a frictionless migration, or if your team needs release tracking and MIT licensing. Reach for self-hosted Sentry only when you genuinely need tracing, replay, or native symbolication and you have the 16 GB box and ops capacity to feed it.

The bigger shift worth internalizing: in 2026 you no longer have to choose between "pay the SaaS bill" and "donate half your server to Sentry's stack." Lightweight self-hosted error tracking on a $5 VPS is finally a real, boring, reliable option — and for most of the projects I run, boring and reliable is exactly the point.