Bugsink

Bugsink is a self-hosted error tracking platform built as a drop-in replacement for Sentry’s hosted service. It accepts events from any Sentry-compatible SDK — covering Python, JavaScript, Node.js, Ruby, Java, and more — so teams can migrate by updating a single DSN value without touching their application code. Captured errors include full stack traces, local variable snapshots at the time of the exception, and automatic issue grouping that deduplicates similar events before they hit your inbox.

Deploying Bugsink takes minutes via Docker or Docker Compose, and it is equally at home on bare metal or Kubernetes. The default configuration uses SQLite for both the application database and the background task queue, eliminating Redis and Celery as runtime dependencies. For higher-traffic environments, PostgreSQL and MySQL are supported alongside the built-in snappea task runner, which uses file-based wakeup signals instead of a message broker.

Beyond basic capture, Bugsink covers the workflow around errors: per-project retention limits with automatic eviction, release tracking to surface regressions, tag-based search and filtering, and alerting integrations with Slack, Discord, and Mattermost. A REST API with OpenAPI documentation means third-party tooling and custom dashboards can be built without reverse-engineering the interface.

The project is actively maintained by Bugsink B.V. with multiple releases per month and a clear roadmap. For organizations that cannot send exception data to a third-party SaaS — due to compliance requirements, cost constraints, or air-gapped environments — Bugsink offers a pragmatic and operationally straightforward path to production-grade error observability.

What You Get

• Sentry SDK Compatibility - Accepts events from any Sentry-compatible SDK by simply pointing your DSN at your Bugsink instance, with no changes to application instrumentation code required.
• Stack Traces with Local Variables - Captures the full call stack and the values of local variables at the point of each exception, enabling deep debugging without additional log statements.
• Automatic Issue Grouping - Groups similar errors into tracked issues using configurable fingerprinting, reducing noise and helping teams prioritize fixes rather than sift through duplicate events.
• Source Map Support - Maps minified or transpiled JavaScript back to original source files, so production stack traces show readable code even after bundling.
• Regression Detection - Tracks when a previously resolved issue reappears after a release, surfacing regressions automatically so fixes do not silently rot.
• Release Tracking - Associates events with specific release versions so you can correlate error spikes with deploys and filter issues by affected release.
• Alerting via Slack, Discord, and Mattermost - Sends notifications to messaging platforms when new issues are opened or resolved issues regress, without requiring external monitoring services.
• Tag-Based Search and Filtering - Indexes arbitrary key-value tags from SDK events and synthesizes additional tags from event attributes, enabling powerful cross-issue filtering and counting.
• REST API with OpenAPI Docs - Exposes a documented REST API for projects, issues, events, teams, and releases, allowing integration with external dashboards and automation workflows.
• Per-Project Retention Controls - Enforces configurable maximum event counts per project with automatic eviction, preventing unbounded storage growth on constrained infrastructure.

Common Use Cases

• Replacing Sentry to eliminate per-event billing - A growing SaaS product generating millions of exceptions per month deploys Bugsink on a single VPS, keeping the existing Sentry SDK instrumentation and cutting error tracking costs to a flat hosting fee.
• Compliance-driven on-premises monitoring - A financial services team subject to data residency requirements routes application exceptions to a self-hosted Bugsink instance, ensuring sensitive stack traces and user context never leave the corporate network.
• Air-gapped or private cloud deployments - A government contractor running workloads in an isolated environment with no public internet access installs Bugsink inside the perimeter, gaining error observability without requiring outbound connectivity.
• Small team with minimal DevOps overhead - A two-person startup spins up Bugsink with a single Docker command using the default SQLite backend, getting full error tracking without provisioning Redis, Celery, or a separate database server.
• ARM-based infrastructure - A team running services on AWS Graviton or Raspberry Pi hardware chooses Bugsink because it ships multi-arch Docker images with native ARM64 support, unlike some alternatives that require cross-compilation workarounds.
• Regression monitoring after deploys - A CI/CD pipeline tags each release in Bugsink, allowing the on-call engineer to immediately see which previously resolved errors have reappeared following a new deployment.

Under The Hood

Architecture Bugsink is a Django-based modular monolith where each domain — event ingestion, issue grouping and state management, background task execution, release tracking, alerting, and tagging — lives in its own app with clearly bounded models and views. The ingest path handles envelope parsing, schema validation against a vendored Sentry event schema, quota enforcement at both the installation and project level, denormalized field computation, and async dispatch to a digestion task, all within a single request handler that uses Django’s delay_on_commit hook to prevent background tasks from executing before the triggering transaction commits. A custom dual-database architecture separates the application database from snappea’s task queue database, routing writes through a custom DB router to avoid contention between web traffic and background processing.

Tech Stack The backend is Python 3.10 or later running on Django 5.2, with Django REST Framework providing the API layer and drf-spectacular generating OpenAPI documentation. SQLite is the default for both the main application database and the snappea task queue, accessed through a custom timed_sqlite_backend that enforces per-query timeouts; PostgreSQL and MySQL are supported for higher-traffic deployments. Gunicorn serves HTTP traffic, and monofy handles pre-start orchestration in Docker to sequence migrations and superuser creation before the web server starts. Background work runs through snappea, a purpose-built lightweight task runner that uses a second SQLite database and file-based wakeup signals instead of Redis or Celery. Static files are served by WhiteNoise, and event payloads are stored compressed using Brotli or gzip via pluggable file storage backends.

Code Quality The test suite spans unit, integration, and API layers across the main app modules, with a custom TransactionTestCase25251 utility that works around SQLite-specific transaction semantics in Django’s test runner. Factory patterns in events and issues modules produce reproducible test fixtures, and REST API tests follow consistent assertion patterns covering authentication, permission checks, and response shape. Error handling is explicit throughout: HTTP status codes are defined as named constants at module level, Django’s validation mechanisms enforce model invariants, and a lightweight assert_() helper in the utility layer acts as a runtime contract mechanism. Ruff is configured for strict PEP-8 enforcement with per-file ignores scoped to migrations, and the vendored event_schema.py and sentry/ directory are explicitly excluded from linting.

What Makes It Unique The most technically distinctive choice is snappea, a dependency-free background task system that replaces Redis and Celery with SQLite and filesystem wakeup files, dramatically reducing the operational footprint for self-hosters who would otherwise need to manage a message broker. The custom timed_sqlite_backend extends Django’s SQLite driver with per-query busy timeouts, preventing deadlocks under concurrent write load without requiring an external connection pooler. Sentry event schema compatibility is maintained through a vendored copy of Sentry’s event.schema.json used under its MIT license, treated as a living contract with explicit documentation of deliberate divergences — a legally and architecturally sound approach to third-party protocol compatibility. The delay_on_commit pattern threads async dispatch through Django’s transaction commit lifecycle, ensuring that background digestion tasks can never observe a partially committed ingest, which prevents a class of consistency bugs common in task-queue-based event pipelines.

Self-Hosting

Bugsink’s core is licensed under the PolyForm Shield License 1.0.0, which is a source-available license rather than an open-source license in the OSI sense. It grants broad rights to use, modify, and distribute the software for any purpose that does not compete with Bugsink itself or products offered by Bugsink B.V. In practical terms this means developers, startups, and enterprises can self-host Bugsink for internal error tracking without restriction, but building a commercial error-tracking product on top of the Bugsink codebase is not permitted. The ee/ directory has its own proprietary license and requires a separate agreement with Bugsink B.V. for access. Portions of the codebase (the sentry/ module) are BSD 3-Clause from the Sentry project, and icons are MIT-licensed.

Running Bugsink in production is genuinely straightforward compared to many self-hosted observability tools. The default single-server setup uses SQLite for both the application and background task databases, Gunicorn for HTTP, and WhiteNoise for static assets — no Redis, no Celery, no separate worker process beyond snappea. Docker images are provided and cover AMD64 and ARM64. You are responsible for backups (the SQLite files and the event file storage directory), OS-level updates, SSL termination via a reverse proxy (nginx or Caddy), and monitoring the application itself. For higher traffic, migrating to PostgreSQL or MySQL is supported but requires reconfiguring the database settings; there is no built-in high-availability clustering.

Compared to Sentry’s hosted SaaS offering, self-hosting Bugsink means you manage your own uptime, data retention, and upgrades. Sentry Cloud provides SLAs, managed HA, automatic backups, and a support team; Bugsink’s commercial support options are not publicly documented, and issue resolution relies primarily on the GitHub issue tracker and community. The paid ee/ tier adds multi-tenant capabilities and potentially other enterprise features, but the exact scope requires contacting Bugsink B.V. directly. For teams comfortable managing a Django application, the operational burden is modest; for teams without Python or server administration experience, the learning curve is real.