Built to self-host

If you’re reading this, you probably already care about control. Maybe it’s about data privacy, maybe compliance, maybe just knowing exactly what your systems are doing. Whatever your reason, self-hosting makes sense – and Bugsink is built for it.

You can run it locally, on a server you own, or in your preferred cloud setup. Bugsink is designed to be up and running in minutes, with minimal setup and no external dependencies.

Sensitive Data

The data involved in Error Tracking is as sensitive as the data from your application itself — it is your application-data after all.

Error reports often contain more than just stack traces; they can include user identifiers, email addresses, session tokens, and other sensitive information. Since errors can happen anywhere in your code, data from any part of your application can end up in an error report.

Scrubbing: a Problematic Solution

The default solution to this problem is to scrub the data before sending it to a third-party service. This is a complicated and error-prone process: you need to identify all the sensitive data in your application, write code to remove it, and test to make sure you didn’t miss anything.

Worse, you need to keep this code up-to-date as your application changes. Failures to scrub data are undetectable until the data is leaked. How else would you know that you missed data to scrub than by seeing it in a report?

Finally, scrubbing data can make reports less useful. If you scrub too much, you lose context and the ability to understand what happened. Think of a user who reported a bug, but you can’t see their user ID in the report. How do you know what they were doing when the error occurred? How do you track down the issue if the information identifying the user has been removed?

Avoiding the Problem

The best way to protect sensitive information is to avoid sending it to third parties in the first place. With Bugsink, you keep everything in-house:

• Your data stays under your control — nothing leaves your servers.
• No third-party breach can expose your data — because no third party ever had it.
• Compliance is simpler — no external transfers to account for.
• No surprise uses — your data won’t end up training someone’s AI.

Self-hosting Done Right

Some tools are technically self-hostable, but not in any way you’d actually want to use. They require multiple services, external queues, cloud dependencies, or hours of tuning. We’ve been there.

Bugsink is different. It was designed to be self-hosted from the start. You can run it on your laptop, in a container, or on a small VM inside your network. It doesn’t need special infrastructure or cloud features to work. It certainly doesn’t need a team of engineers to keep it running.

We’ve kept the moving parts to a minimum:

• Database: SQLite by default (one less service to manage). Use MySQL or PostgreSQL if that fits your setup better.

• Runtime: A single container is enough.

• Orchestration: Optional: Virualenv/pip, plain Docker, Docker Compose all the way up to Kubernetes.

• Dependencies: No message queue, no external services, and no hidden requirements.

Scalability

Bugsink is fast. Most teams will never need to scale it beyond a single machine. It can handle millions of errors per day on very modest hardware. Your error tracker should be orders of magnitude less complex than your actual application.

See the scalability docs for what that looks like.

Installation

You can get started in under a minute. One command and you’re running.

docker pull bugsink/bugsink:latest

docker run \
  -e SECRET_KEY=LffHqBecB5zbGU7UGaDvs0e5kZ9NU4PTztu87B6SLQT9MxeFT5 \
  -e CREATE_SUPERUSER=admin:admin \
  -e PORT=8000 \
  -p 8000:8000 \
  bugsink/bugsink

Visit http://localhost:8000/, where you’ll see a login screen. The default username and password are admin.

Now, you can set up your first project and start tracking errors. Full instructions are in the installation docs.

×