At some point, every side project grows up. It stops being a script you run locally and starts being something you actually depend on. When that happens, you want to know when it breaks.
The obvious answer is Sentry. Or Datadog. Or any of the dozen other error tracking services that will gladly hold your errors until you hit the free tier limit, at which point they present you with a pricing page designed to make the monthly cost feel reasonable by spreading it across a per-seat, per-event, per-project matrix.
For a small project, that is not reasonable. So I built BugBarn.
What it is
BugBarn is a self-hosted error tracking server. You run it on your own machine. Your errors go there. Nobody else sees them, nobody charges you per event, and it does not require a Kubernetes cluster to operate. It runs fine on a $5 VPS or a Raspberry Pi sitting on a shelf.
The core loop is straightforward. Your application sends errors to BugBarn using a tiny SDK. BugBarn groups them into issues based on fingerprinting, stores them in SQLite, and shows them in a web UI. You can resolve issues, mute noisy ones, and set up alerts for things that actually matter.
The parts worth knowing about
The web UI is a single-page app that runs alongside the server. No separate frontend deploy, no CDN required. You hit the URL and there it is. It has a log stream that updates in real time, an issue list you can filter and search, and an alert editor for setting thresholds on error counts.
SDKs exist for Go, TypeScript, and Python. They follow the same pattern: initialize once with your API key and endpoint, then capture errors as they happen. The Go SDK has a recovery middleware for HTTP handlers. The TypeScript one runs in both Node and the browser. Each is small enough to read in one sitting.
The weekly digest emails a summary of what happened across all your projects over the past seven days. New issues, regressions, resolution rate. The kind of thing that is useful to read over coffee without having to open a dashboard.
Projects are first-class. If you run several apps on the same server, they each get their own project with separate API keys. You can view issues per project or across all of them at once, with a small project tag on each row so you know where things came from.
How the storage works
BugBarn writes to SQLite. This is a deliberate choice. SQLite is reliable, fast for read-heavy workloads, and requires nothing beyond a file on disk. For the volume of errors most small projects produce, it is more than adequate.
Before events reach SQLite they pass through a spool on disk. The ingest endpoint writes to the spool and returns immediately. A background worker reads from the spool, processes the events, and persists them. This means ingest stays fast even when the database is under load, and nothing is lost if the process restarts mid-batch.
Installing it
If you are on Linux, the cleanest option is APT. Add the WebWiebe repository and install the package. It ships with a systemd unit that reads configuration from /etc/bugbarn/bugbarn.conf, creates a dedicated system user, and starts on boot. A sample config file lands at /etc/bugbarn/bugbarn.conf.example with every option documented.
curl -fsSL https://webwiebe.nl/apt/install.sh | sudo bash
sudo apt install bugbarn
On macOS, use the Homebrew tap. The binary works on both Intel and Apple Silicon.
brew tap webwiebe/bugbarn
brew install bugbarn
Docker and a plain binary download are also available on the GitHub releases page.
Configuration
Everything is configured through environment variables with a BUGBARN_ prefix. The config file format is plain KEY=VALUE, which is the same syntax systemd's EnvironmentFile directive expects, so the two work together without any adapter.
The most important variables are the admin credentials, the session secret, and the paths for the database and spool directory. The rest have sensible defaults: port 8080, no CORS restrictions, 12-hour session TTL.
Self-hosting as a constraint
There is a certain discipline that comes with self-hosting. The tool has to be small enough to run on hardware you already have. It has to start fast, use little memory, and not require babysitting. BugBarn tries to hold to those constraints.
It also has to be something you actually trust with production data. That is why the code is open source and the storage is local. You can read every line, and your errors never leave your infrastructure.
The source is on GitHub. Installation details for both Linux and macOS are on the APT and Homebrew pages.