Bugsink

Last reviewed Sep 13, 2026 · 779 words

Self-hosted Sentry asks for 16 GB of RAM, a couple of dozen containers, Kafka, ClickHouse and an upgrade process that people write blog posts about surviving. Bugsink accepts the same SDKs and the same DSN format and runs as one container on SQLite in 256 MB. For a solo developer or a small team whose question is "what is crashing and how often", that is the whole comparison, and the rest of this guide is the detail.

Sentry-compatible means the SDK never knows

Your application keeps sentry-sdk, @sentry/node, sentry-go or whichever client it already uses. You create a project in Bugsink, it hands you a DSN, and you swap that in. Exceptions arrive with stack traces, breadcrumbs, tags, release and environment fields, and Bugsink groups them into issues the way Sentry does, with counts, first-seen and last-seen, and resolve or mute per issue. Source maps for minified JavaScript work when you upload them. Alerts go out by email on new issues and on regressions, and there are webhook options for chat tools.

What does not arrive is anything that is not an error. Performance transactions, session replays, profiling and cron monitoring are outside the project's stated scope, and the SDK's calls for them are accepted and dropped rather than rejected. If you send transactions at a high sample rate, turn that down; it is bandwidth for nothing.

The whole deployment is one service

services:
  bugsink:
    image: bugsink/bugsink:latest
    ports:
      - "8000:8000"
    environment:
      - SECRET_KEY=generate-50-random-characters-here
      - [email protected]:change-me
      - BASE_URL=https://bugs.example.com
      - EMAIL_HOST=smtp.example.com
      - [email protected]
      - EMAIL_HOST_PASSWORD=change-me
      - [email protected]
    volumes:
      - ./data:/data
    restart: unless-stopped

SECRET_KEY signs sessions and must stay stable across restarts. CREATE_SUPERUSER is read once, on first start; remove it afterwards so the password is not sitting in the compose file. BASE_URL has to match what the browser and the SDKs use, otherwise DSNs are generated with the wrong host. The SQLite database lives under /data; back it up with sqlite3 data/db.sqlite3 ".backup ..." rather than copying the file while events are being written. Put Caddy or another reverse proxy in front for TLS and you are done.

SQLite holds more than you expect

Bugsink's authors are explicit that SQLite is the intended production database, not a development shortcut, and in practice a single-writer error tracker is a good fit for it. A few hundred events a minute is fine; the ingest path is a Django app with a background process that handles digestion, so a burst during an outage queues rather than falls over. Retention is per project: set a maximum number of stored events and Bugsink evicts the oldest, so the database size is bounded by a number you chose rather than by whatever happened last month. If you outgrow that, DATABASE_URL pointing at PostgreSQL or MySQL is supported, and the migration is a Django dump and load.

Where the 2,000-star number is a warning

The project first shipped in 2024. That means the interface is still adding things Sentry users take for granted: saved searches, more alert conditions, richer team permissions, integrations beyond email and webhooks. It also means the codebase is small enough to read in an afternoon, which is a real advantage when you are the person who has to keep it running. The licence is MIT and there is no seat count; the company behind it sells hosting, not features, which is the funding model I trust most for a tool like this.

GlitchTip is the middle option

GlitchTip is the other Sentry-compatible self-hosted tracker, older, with performance monitoring and uptime checks, and it wants PostgreSQL, Redis and a worker container, which puts it at 1 GB of RAM and 4 services. If you want transactions and a proper team structure without running full Sentry, it is the pick. If you want errors only and one container, Bugsink is smaller, simpler and faster to understand when something goes wrong.

What I'd do

Bugsink behind Caddy, SMTP configured on day one so new-issue alerts reach you, a retention cap of a few thousand events per project, and a nightly SQLite backup. Point every side project and internal tool at it; the cost of another project is zero. Move to GlitchTip only when someone asks for transaction traces, and to Sentry only when a team is large enough to have a person who owns the monitoring stack. Most self-hosters never reach either threshold, which is the argument for starting here.