Bugsink: self-hosted error tracking that accepts Sentry SDK events

Sentry SDK compatibility lets you swap the DSN without changing application code

Bugsink accepts events in the Sentry wire protocol. An application already instrumented with a Sentry SDK can redirect its error reports to a Bugsink instance by changing the DSN in its configuration, with no changes to the application code itself. The project presents itself as Sentry-SDK compatible, built to self-host, and scalable and reliable, all three named as top-level properties in the README.

The target users are teams that need error data on infrastructure they control, organizations under data-residency obligations, and developers who want error tracking without a SaaS subscription. Those are the cases the project presents itself for.

The alternative path is Sentry's own cloud service. With Sentry cloud, SDK events go to Sentry's servers. With Bugsink, they go to your own server. The SDK code in your application stays identical in both cases because both services speak the same wire protocol. That symmetry is the main selling point, and it is also the main constraint: Bugsink is only as useful as its compatibility with the Sentry SDK version your application uses.

Inside the repository, separate directories cover ingest/, issues/, projects/, tags/, events/ and alerts/. That layout gives a working outline of the data model: incoming SDK events arrive at the ingest layer, get processed into issues, and surface in the UI grouped by project and tag. The sentry/ and sentry_sdk_extensions/ directories suggest the compatibility layer is implemented internally.

The Docker quick-start requires SECRET_KEY, CREATE_SUPERUSER, and PORT

A two-command Docker sequence is the fastest path to a running instance. The first command pulls the official image:

docker pull bugsink/bugsink:latest

The second command starts the container with three environment variables:

docker run \
  -e SECRET_KEY=PUT_AN_ACTUAL_RANDOM_SECRET_HERE_OF_AT_LEAST_50_CHARS \
  -e [email protected]:admin \
  -e PORT=8000 \
  -p 8000:8000 \
  bugsink/bugsink

SECRET_KEY must be at least 50 characters; anything shorter fails Django's signing validation. CREATE_SUPERUSER takes an email and password separated by a colon and creates an admin account on the first start. The README states that the default username and password are admin. PORT controls which port the server binds inside the container, and its value must match the host port mapping in the -p flag.

After the container is running, visiting http://localhost:8000/ shows a login screen. From there, the Bugsink documentation at https://www.bugsink.com/docs/quickstart/ covers creating a first project and generating a DSN. For anything beyond a throw-away evaluation, the repository includes a docker-compose-sample.yaml. The README points to https://www.bugsink.com/docs/installation/ for production installation details without describing the compose file further.

Snappea runs background jobs and must be started alongside the web server

The pyproject.toml file defines five command-line entry points: bugsink-show-version, bugsink-manage, bugsink-util, bugsink-create-conf and bugsink-runsnappea. The last is the background task worker; a snappea/ directory at the repository root holds its code.

Running Bugsink in production means operating two processes: the Gunicorn web server, pinned at gunicorn==26.2.* in requirements.txt, and the Snappea worker. A deployment that starts only the web process leaves background tasks unprocessed. Neither the README nor the repository-level documentation describes which tasks run through Snappea, how to check the queue depth, or what happens to events when the worker is down during an ingestion spike.

The requirements also include inotify_simple==2.0.*, a library for inotify-based file monitoring. inotify is a Linux kernel interface, so this dependency ties the Snappea worker to Linux hosts. Teams deploying on macOS or Windows for local development should verify whether inotify_simple degrades gracefully or produces an import error on those platforms before they rely on background processing in non-Linux environments.

symbolic is pinned at 8.7.2 because newer releases dropped ProcessState

Every line in requirements.txt uses a wildcard minor-version pin except one: symbolic==8.7.2. The inline comment in the file explains why: it is the last version to support ProcessState, which is the interface the project uses for minidump parsing. Minidump files are crash reports produced by native applications, primarily on Windows.

This pin is deliberate, not an oversight. Wildcard pins like Django==5.2.* allow patch-level updates to flow in automatically; symbolic==8.7.2 does not. Automated dependency tools configured to upgrade pinned packages will break minidump parsing if they touch this line.

The symbolic library comes from the Sentry ecosystem and is maintained by Getsentry. Because Bugsink B.V. does not maintain symbolic, any decision to upgrade sits outside the project's own release schedule. If Getsentry restores the ProcessState interface in a later release, Bugsink would need to update the pin before operators could benefit. Until that happens, symbolic must be excluded from any auto-upgrade policy.

For most web deployments, the practical impact is limited: minidump parsing applies only to native crash reports from desktop or embedded applications. A Python or JavaScript web application sending stack traces through a Sentry SDK is not affected by this pin.

The repository Dockerfile is provided as-is and the team does not use it themselves

The Dockerfile at the repository root opens with a direct disclosure: 'It is provided as-is; the Bugsink team does not use this in their own development.' For evaluation and standard production use, the team's own path is the Docker Hub image pulled by docker pull bugsink/bugsink:latest, not a local build from the repository. This is an unusual acknowledgment: most projects present their source Dockerfile as the canonical packaging path.

For operators who want to build from source, the Dockerfile defaults to Python 3.12 as the base image, controlled by the ARG PYTHON_VERSION=3.12 directive. It uses a two-stage build: a non-slim image to compile the mysqlclient wheel from source (because no binary wheel for mysqlclient is available on PyPI), then a slim image for the final runtime. Native extensions are stripped in a single layer to reduce the final image size.

Teams with container-scanning or image-provenance requirements should read the Dockerfile in full before building it, since the comment sets the expectation that the team does not test it as part of their own workflow. The docker-compose-sample.yaml in the repository root covers the production setup path, and the README points to the Bugsink documentation site rather than documenting that file inline.

The licence is not a standard SPDX identifier and contributors must sign a CLA

GitHub classifies Bugsink's licence as Other, meaning it does not match any standard SPDX identifier the platform recognises. The full licence text is in the LICENSE file at the repository root. A custom licence may restrict commercial use, redistribution, or running the software as a hosted service for third parties in ways that standard permissive licences do not, and those restrictions vary entirely by what the file says.

A CLA.md file sits alongside the licence at the repository root. Contributor License Agreements are common in commercially backed projects: they give the company, here Bugsink B.V., the right to use contributions in commercial products and to relicence contributions in the future without seeking each contributor's permission again.

Bugsink B.V. is the author entity in pyproject.toml. There is also an ee/ directory in the repository, which conventionally signals an enterprise edition with features not included in the open tier. Neither the README nor the repository-level documentation describes which features sit in ee/ or under what terms they are available. Anyone evaluating Bugsink for a commercial deployment should read the LICENSE text and clarify the terms with Bugsink B.V. before committing to production.

Release pace, the phonehome/ directory, and the Python version floor

Three releases arrived in six weeks: 2.5.1 on 2026-08-31, 2.6.0 on 2026-09-15 and 2.6.1 on 2026-09-25. The last push to the default branch was on 2026-10-06. CHANGELOG.md at the repository root documents the version history. Bugsink B.V. is the author entity in pyproject.toml, so the project has a commercial backer rather than being maintained by an individual.

The repository includes a phonehome/ directory. The name suggests the server reports usage data back to Bugsink B.V. Nothing in the available documentation describes what is transmitted, on what schedule, or how to disable it. Any deployment in an air-gapped environment or operating under a data-minimization policy should examine the phonehome/ code before going live.

The Python floor is 3.10. The pyproject.toml classifiers list support from 3.10 through 3.14, and the Dockerfile defaults to 3.12. Django is pinned at 5.2.x, the current long-term support series. Other significant dependencies include djangorestframework==3.18.*, jsonschema==4.26.*, and drf-spectacular[sidecar] for the API layer. A future Django major version will require a Bugsink release targeting the new series, and operators on long-running installs should watch CHANGELOG.md for that transition.

Editorial conclusion

Bugsink is a good fit for teams already running Sentry SDK instrumentation who want error data on their own Linux server without changing application code. The DSN swap is the only client-side change needed. Skip it if the custom licence terms do not match your deployment model: read the LICENSE file first, then contact Bugsink B.V. to clarify any commercial use case. The phonehome/ directory needs investigation before any air-gapped or data-minimization deployment. Exclude symbolic==8.7.2 from any automated upgrade policy. Check docker-compose-sample.yaml against your infrastructure before moving past the evaluation run.

Frequently asked questions

Official sources

1. bugsink/bugsink on GitHub
2. Issues
3. Project website
4. README
5. Releases