Self-hosted error tracking that fits in a single binary

Self-hosted error tracking that fits in a single binary

I run my own monitoring stack. I run a Postgres I administer myself. I am, by the standards of most SaaS marketing pages, the wrong customer. Vendors keep telling me I should "let them handle the database." I have a database. I am running their servers on top of my database. We are not the same person.

So when I went looking for an error tracker I could run on the same homelab box that already hosts my agent receiver, my Postgres, and a half-finished Plex install, I expected to find one with a small footprint. I did not. The self-hosted error-tracking landscape in 2026 is dominated by tools that assume you have a Kubernetes cluster, or at least Docker Compose patience, or at least one spare 4 GB host. Here is the honest field guide, with footprints, and at the end the option I ended up building because none of them quite fit.

What "self-hosted error tracking" actually means

Self-hosting is not just a license model. The promise is concrete: my data on my hardware, my failure modes, my upgrade schedule. The reasons you'd want it are some subset of:

1. Cost predictability past a certain volume. SaaS error tracking gets expensive when you have a popular app and a small team. The crossover where your own ops time is cheaper than per-event billing depends on volume but exists.
2. Compliance / data residency. Your stack traces include user IDs, request paths, and sometimes payloads. If those have to live in a specific country, or off the public internet, or inside a corporate VPC, SaaS does not help.
3. Air-gapped operation. Industrial control, defense, financial back-office. There is no "send my errors to the cloud" option here. The error tracker has to live behind the firewall.
4. The principle of the thing. Some of us run our own services because we can. This is a real reason and I will not gaslight you about it.

What self-hosting is not is a way to avoid the underlying complexity. The error tracker still has to receive events, parse stack traces, look up source maps, group issues, send notifications, and not lose data in a power blip. The question is how much of that complexity is exposed to you, the operator.

The four self-hosted options worth comparing

Sentry self-hosted

The reference implementation. Sentry the open-source codebase is the same code that runs at sentry.io, which means the feature set is unmatched: replay, profiling, tracing, performance monitoring, the works.

The cost is the footprint. The official self-hosted setup ships as a Docker Compose stack with twenty-something containers — web, worker, cron, events-consumer, forwarder-consumer, relay, snuba-api, snuba-consumer, snuba-replays-consumer, snuba-subscription-consumer, four flavors of Kafka, ClickHouse, Postgres, Redis, Memcached, Symbolicator, vroom, and a handful of utility containers. The minimum recommended VM is 4 cores and 16 GB RAM. That is not a homelab footprint; that is half of a homelab.

The codebase is also actively user-hostile to people who want to deploy it themselves: every couple of major versions, the upgrade path requires a database migration sequence that takes hours and leaves your Sentry instance read-only during the window. Sentry has been transparent about this — they're not optimizing for self-hosters; they're optimizing for sentry.io. That is a fair stance for them to take. It does mean if you self-host you are running a stack that is not really designed for you.

Verdict: full feature parity with the cloud. Footprint is enterprise-only. Maintenance overhead is real. You probably have heard about the recent licensing drama; that is a separate post and I will not relitigate it here.

GlitchTip

GlitchTip is the spiritual heir to "Sentry without the hard parts." It implements the Sentry SDK protocol — meaning your existing @sentry/browser clients can point at a GlitchTip instance and just work — but rebuilt with a small footprint in mind.

The architecture is much friendlier: Django web app, Postgres, Redis, Celery worker, optional valkey. Five containers in the Docker Compose, not twenty-three. RAM footprint sits around 1-2 GB depending on traffic. AGPL-licensed.

The feature set is deliberately narrower. GlitchTip does errors, releases, and basic uptime checks. No replay, no profiling, no full performance monitoring, no flamegraphs. The team has been clear that this is the trade: keep the surface small enough for one or two engineers to maintain a self-hosted instance.

Verdict: the right answer if your priority is "Sentry-compatible self-hosted error tracker, minimum fuss." Still requires Docker. Still requires Postgres and Redis administered by you. But manageable.

SigNoz

SigNoz is the OpenTelemetry-native option. It positions itself as an APM (application performance monitoring) tool more than an error tracker — traces, metrics, and logs are first-class; errors are derived from traces.

The architecture is heavier than GlitchTip: ClickHouse cluster (1+ nodes), the SigNoz frontend, the query service, the alert manager, an OTel collector, ZooKeeper, Schema Migrator, optionally Kafka. The official Helm chart assumes Kubernetes; the Docker Compose works but expects ~4 GB RAM minimum because ClickHouse.

The strength is OpenTelemetry. If your services already emit OTel spans, SigNoz consumes them natively and you get distributed tracing alongside errors. The weakness is that if you wanted "an error tracker," you've now learned ClickHouse operations, OTel collector configuration, and how to deal with high-cardinality dimension explosion. Power, but at a cost.

Verdict: pick SigNoz if you want OpenTelemetry-native traces and you're already comfortable with ClickHouse. Don't pick it if you just want to know which errors fired today.

Netwarden Apps (the option I built)

Disclosure: I'm the founder of Netwarden. The reason this post exists at all is that I went looking for a self-hosted error tracker that was a single binary, found nothing, and built one. So this section is going to read like a sales pitch even though the comparisons above were honest. I'll keep it tight.

Netwarden Apps is part of the Netwarden self-hosted edition, which compiles to a single Bun executable plus a SQLite database file. No Docker. No Postgres. No Redis. No Kafka. No ClickHouse. You download a binary, run it, point your SDKs at it. Footprint is around 80-120 MB resident memory at idle and uses one CPU core under normal load.

The compromise is that the feature set, like GlitchTip's, is deliberately narrower than Sentry's. We ship error tracking with stack-trace symbolication, dependency-CVE alerts cross-referenced against OSV.dev every day, lite analytics (pageviews, uniques, custom events), and the same alert pipeline as the host-monitoring side of the product. We do not ship session replay, profiling, distributed tracing, or full APM. If you need any of those, the answer in this comparison is Sentry self-hosted or SigNoz, full stop.

What's in: errors, source-map symbolication, dependency-update advisories across npm / PyPI / RubyGems / Go / Cargo / Maven / NuGet / Composer, lite analytics, JS / Node / Python SDKs.

What's out: session replay, profiling, distributed tracing, OpenTelemetry-native ingest, mobile SDKs (in flight), frontend performance monitoring beyond pageview timing.

The single-binary self-hosted edition is in beta as of this writing — see /self-hosted for the current status. The hosted version (app.netwarden.com) has been generally available longer.

Verdict: pick this if "single binary, SQLite, runs on a Pi 4" is a hard requirement and you can live without replay/profiling. Don't pick it if you need APM-grade tracing or mobile SDKs.

Footprint comparison at a glance

Numbers are from default Docker Compose / Helm values published by each project as of writing. Real-world footprint varies with traffic.

| Tool | Containers / processes | Min RAM | Min disk | Database | Notes | |---|---|---|---|---|---| | Sentry self-hosted | ~23 containers | 16 GB recommended | 50 GB+ for Kafka topics | Postgres + ClickHouse + Kafka + Redis + Memcached | Full feature parity with sentry.io | | GlitchTip | 5 containers | 1-2 GB | 5-10 GB | Postgres + Redis | AGPL, Sentry-protocol compatible | | SigNoz | 7-9 containers | 4 GB recommended | 20 GB+ ClickHouse | ClickHouse + ZooKeeper | OpenTelemetry-native | | Netwarden Apps (self-hosted) | 1 binary | 128 MB | 1 GB+ growing with retention | SQLite (embedded) | Beta. Single Bun executable. |

The headline difference is operational, not feature-list. The feature lists between GlitchTip and Netwarden Apps overlap heavily; the difference is whether you want to administer Postgres and Redis, or whether you want a systemd unit that points at a binary.

When self-hosted is the wrong answer

I want to be honest about the case against self-hosting at all. Three patterns where you should just pay for SaaS:

Volume so low that hosting costs more than the SaaS plan. If you'd be on a free or $9 SaaS tier, the $5/month VPS plus your time is more expensive than the SaaS plan. Self-host because you want to, not because you think it's cheaper at small scale. It usually isn't.

Solo dev, no on-call rotation. If your error tracker goes down at 3 AM, you have to fix it. SaaS reliability engineers are awake; you are asleep. The math changes if errors go uncaptured for the hours you're sleeping vs. captured by someone else's pager.

Compliance you can't actually enforce on your own VPS. "Self-hosted" on DigitalOcean is not the same as "in our SOC 2 environment." If the compliance constraint is real, the answer is usually a private SaaS deployment from a vendor who can pass the audit, not a single binary you administer yourself.

How to choose

The honest decision tree, in three questions:

1. Do you need replay, profiling, or distributed tracing? Yes → Sentry self-hosted or SigNoz. No → continue.
2. Are you willing to run Postgres + Redis as part of the deployment? Yes → GlitchTip is the cleanest. No → Netwarden Apps single-binary build.
3. Do you need to ingest OpenTelemetry traces today? Yes → SigNoz. No → see the previous two.

If you're optimizing for "fewest moving parts, runs on hardware I already have, gets out of my way," the binary option exists in 2026. If you're optimizing for "feature parity with sentry.io," the answer is still Sentry self-hosted, with the operational cost that implies.

What I actually run

For the record: a single Bun binary on a 4 GB Hetzner VPS, alongside the host-monitoring side of Netwarden, total ~250 MB resident. SQLite for the database. systemd for supervision. Backups via litestream to a Backblaze bucket. No Docker. The whole thing is one config file and the binary, and that's the part of the trade I personally optimized for.

If that sounds appealing — the self-hosted page has the install instructions and current beta status. If you want the hosted version instead because operating things isn't your hobby, that's at app.netwarden.com, $9/month after the free first project. Both run the same code.

If you've decided to leave Sentry — for any of the reasons above — the migration guide walks the SDK swap step by step. If you're earlier in evaluation and want the feature comparison without the self-hosting angle, the Sentry alternatives roundup is the one to read next, and the Sentry comparison page has the side-by-side at-a-glance.

Self-hosting an error tracker in 2026 should not require a Kubernetes cluster. The fact that most options still expect one is the gap I built into.

Keep reading

• Sentry alternatives without per-event bills — the pricing-model breakdown.
• Migrating from Sentry to Netwarden in 30 minutes — the SDK swap.
• Self-hosting Netwarden — the Bun binary preview — current status of the single-binary build.
• Why I built Netwarden — the homelab story behind the product.