A drop-in, self-hosted replacement for Sentry's event ingestion and browsing. Single binary, single SQLite file, no external dependencies.

I got tired of paying for Sentry on smaller projects and self-hosting the official thing is... a lot. The thing is, most of what I need is ingestion, grouping, and a way to browse errors. So I built this — point your existing Sentry SDKs at it, browse errors in the web UI, or query via the JSON API.

• Drop-in Sentry protocol — envelope and legacy store endpoints, all auth methods. Any Sentry SDK works, no code changes.
• Single binary, no dependencies — one process, one SQLite file. PostgreSQL optional.
• Issue grouping — fingerprint-based grouping with regressions and resolution tracking.
• Server-rendered web UI — browse issues, events, transactions, logs, traces, replays, monitors, and more.
• Performance & tracing — transaction percentiles, throughput, and failure rates, span waterfalls across traces, Web Vitals, and release-health crash-free rates.
• JSON API — query everything the UI shows.
• Notifications & alerts — email (Lettermint, Postmark, or SendGrid), Slack, and webhooks, with digests and threshold rules.
• Source maps — upload via sentry-cli so minified traces resolve to original source.
• Monitors — cron check-in tracking via Sentry's protocol.
• Auth your way — a shared admin token for solo use, or OAuth/OIDC SSO for teams.
• Organizations & roles. Every user gets a personal org and can create more, invite others as owners or members, and manage membership and org slugs from the UI; data is scoped per org, mutations are owner-gated, and if your IdP emits org claims (Forseti-style), those orgs and roles map straight in.
• Migrate in — pull historical events, issues, and releases from an existing Sentry instance.

Stackpit covers the everyday error-tracking workflow and a useful slice of performance monitoring, then deliberately stops short of Sentry's heavier features. It's a drop-in for the common case, not a full reimplementation. Here's roughly how they line up:

Do take this with a grain of salt: the "basic" rows are genuinely basic, and the gaps are intentional. If deep APM, full-fidelity replay, or profiling are load-bearing for you, run the real thing.

Pre-built binaries for Linux (x86_64) and macOS (Apple Silicon, Intel) on GitHub Releases.

stackpit init            # writes stackpit.toml with a fresh admin_token
stackpit serve           # start both ingestion + admin UI
stackpit serve --ingest-only  # ingestion only, no admin UI/API

stackpit init generates a random 32-byte admin token and writes it into the config, so the admin UI is usable on first boot without any extra steps.

Images are published to the GitHub Container Registry on every release — a default SQLite image and a PostgreSQL variant (same tags, -postgres suffix):

docker pull ghcr.io/franzos/stackpit:latest            # SQLite
docker pull ghcr.io/franzos/stackpit:latest-postgres   # PostgreSQL

# first run: generate stackpit.toml (with an admin token) into the volume
docker run --rm -v stackpit-data:/app ghcr.io/franzos/stackpit:latest ./stackpit init

# then serve
docker run -d --name stackpit \
  -p 3000:3000 -p 3001:3001 \
  -v stackpit-data:/app \
  ghcr.io/franzos/stackpit:latest

The SQLite file and stackpit.toml live in the working directory (/app) — mount a volume there to persist them. Note the admin listener binds to 127.0.0.1 by default, so set bind = "0.0.0.0:3000" in stackpit.toml for the mapped 3000 port to be reachable from outside the container.

stackpit runs two listeners:

The admin port serves the browsing UI and API. The ingestion port is where your SDKs send events — it's the address you put in your DSN. I've found that keeping these separate makes deployment quite a bit more flexible.

--ingest-only skips the admin listener entirely, useful if you want dedicated ingestion nodes.

Everything past first boot — the full stackpit.toml reference, PostgreSQL, authentication and OIDC/SSO setup, connecting SDKs, notifications, source maps, monitors, syncing from Sentry, and the CLI — lives in the Operator Guide:

• Configuration — the full config reference, filter modes, PostgreSQL
• Authentication — admin token, OAuth/SSO (OIDC), secret encryption
• Connecting SDKs — supported SDKs and DSN format
• Notifications & Alerts, Source Maps, Monitors, Web UI
• Syncing from Sentry, CLI tools

This project wouldn't be possible without Sentry and is not meant to be a replacement, but rather a lightweight drop-in with limited features. If you need the full power of Sentry — profiling, full-fidelity session replay, advanced performance monitoring, and so on — use the real thing.

Requires Rust 1.88+.

cargo build --release