urgentry vs Bugsink: two takes on lean Sentry-compatible self-host.

Why this comparison is awkward in the best way

Most comparison articles have a clean asymmetry. One product is bigger, one is smaller. One is hosted, one is self-hosted. One does X, the other does Y.

Bugsink and urgentry are not like that. They are aimed at the same kind of operator, with the same kind of complaint, on the same kind of hardware. Pretending there is a clean winner is dishonest. The actual question is which trade-offs match your situation.

This is an urgentry-published comparison and the bias is what you would expect. The honest correction for that bias is the section on where Bugsink is ahead, which is not pro forma.

The shared starting point

Both projects accept events from the official Sentry SDKs. The contract is the DSN; everything else — envelopes, retries, breadcrumbs, releases — is handled by the SDK code your team already wrote.

Both projects target the same hardware budget. Both projects’ documentation has a sentence that says, roughly, “you do not need 16 GB to run an error tracker.” Both are correct.

And both projects exist because the wider self-host conversation has moved past Sentry’s reference distribution for small teams. That shift is the reason there are multiple lean alternatives now, not just one.

The capability matrix

Honest where it can be, blank where neither project has a credible number to offer.

Where Bugsink is ahead

The cases where Bugsink is the better pick, said plainly.

The lean-self-host conversation is its conversation

Bugsink was the project that gave the “Sentry self-host is too much” argument a clean public form. The HN thread, the blog posts, the cost-of-RAM framing — Bugsink owns that ground. If you are reading about lean error trackers because Klaas van Schelven’s posts brought you here, you already trust the project, and that trust is hard to displace.

Python operational comfort

If your team operates Python services daily, Bugsink fits the toolkit your team already has. Logs read the way you expect. Failure modes are the ones you have already debugged in other Django apps. Deployment uses gunicorn or uvicorn, which your CI already knows how to spin up.

MIT license

Bugsink is MIT, and that is the most permissive widely-used open-source license. For legal reviews that require “OSI-approved licenses only,” Bugsink clears the gate without footnotes. urgentry’s FSL-1.1 is permissive for almost every internal use, but it does carry a two-year transition window before it converts to Apache-2.0, and that detail matters to some organizations.

Longer public track record

Bugsink has been shipping publicly since 2024. That is real production-hours that any newer project, including urgentry, simply does not have yet. If “has been someone’s primary error tracker for a year” is a hard requirement, this is the row that decides.

Where urgentry is ahead

The compensating rows are narrower than the marketing instinct would phrase them.

One Go binary, no Python runtime

urgentry deploys as a single static Go binary. There is no Python interpreter to align with the host, no virtualenv to manage, and no requirements.txt drift between environments. For teams that already run Go services, urgentry slots in without expanding the toolkit. For teams that do not, the binary still installs from a curl-piped script with no language dependencies.

SQLite as the default database

urgentry runs against SQLite out of the box, and against Postgres if you ask for it. Bugsink supports Postgres and MySQL but does not lead with SQLite. For a single-host deployment with modest volume, “one binary and a file on disk” is a real simplification, and it changes what the operations runbook looks like.

Native OTLP for traces and logs

urgentry accepts OpenTelemetry traces and logs over OTLP/HTTP in the same binary that handles errors. Bugsink is errors-first and does not advertise OTLP ingest. If your services already export OTLP, this is the row that probably decides the comparison for you.

Wider symbol artifact coverage

Both projects handle JavaScript source maps. urgentry also handles ProGuard mappings for Android, native debug files, and minidumps for native crash ingest. If your stack includes mobile or native code, that broader artifact support shows up in the day-to-day experience.

The deployment shape, side by side

A small concrete comparison helps more than a paragraph of adjectives.

Bugsink, in its most-recommended setup:

docker run -d \
  -e SECRET_KEY=... \
  -e DATABASE_URL=postgres://... \
  -e BUGSINK_DOMAIN=https://bugsink.example.com \
  -p 8000:8000 \
  bugsink/bugsink

urgentry, in its smallest setup:

curl -fsSL https://urgentry.io/install.sh | sh
urgentry --config /etc/urgentry/config.yaml
# SQLite database file on disk; no external DB process

Both are minimal. The visible difference is the Postgres dependency on the Bugsink side and the absence of one on the urgentry side. Whether that matters depends on whether you already run Postgres for something else.

License: the section worth its own pass

Bugsink is MIT. urgentry is FSL-1.1-Apache-2.0. Both let you run, modify, and deploy the software inside your organization. The difference shows up in two narrow cases.

First, if your legal review requires “OSI-approved licenses only,” Bugsink is approved and FSL-1.1 is not yet. That is a procedural fact, not a value judgment.

Second, if you intend to take the software and offer it as a competing hosted service, MIT permits that immediately while FSL-1.1 does not until the two-year transition expires. Most teams have no such intent and this difference does not affect them.

For the median reader of this article, the license rows are a tie. For the readers for whom they are not a tie, they tend to decide cleanly.

When to pick Bugsink

The cases where Bugsink is the right answer, named directly:

• Your stack is Python and your team already runs Django comfortably.
• Your legal team has a flat MIT-or-Apache-2.0 rule with no carve-outs.
• You want a tracker that has been in production for a year and a public roadmap to match.
• You do not need OTLP traces or logs; you have a separate observability stack for those signals.
• You read the original HN thread and Bugsink’s posts are why you started looking.

When to pick urgentry

The cases where urgentry is the better fit:

• You want one Go binary, with SQLite as the default database, on a small VPS.
• You already export OTLP from your services and want errors, traces, and logs in the same process.
• Your stack includes mobile or native code and you need ProGuard, debug files, or minidumps.
• Your team operates Go services daily and adding a Python runtime adds operational surface you would rather avoid.
• You are starting from scratch and the toolkit is not yet committed.

What this comparison is not

This is not a quality verdict on Bugsink. The project is well-built, well-documented, and well-led. Half the energy in the lean-self-host conversation exists because Bugsink put it there, and the existence of urgentry is partly a response to that conversation.

It is also not a migration prompt. If Bugsink is working for your team, the deployment-shape differences here are not a reason to switch. Migrating between tools that solve the same problem is rarely worth the cost unless one of the constraint rows has changed for you.