Self-hosted Sentry too complex? Try Telebugs

The reality of self-hosting Sentry

Many teams start with the official self-hosted Sentry because they want to keep error data on their own infrastructure and avoid recurring SaaS bills. The intention is good. The experience, for a lot of people, is not.

Sentry’s own self-hosted documentation describes the offering as “packaged up for low-volume deployments and proofs-of-concept” and states that it “comes with no guarantees or dedicated support.” Users are expected to rely on the community Discord for help. The docs note that as features evolve, the self-hosted stack can demand additional infrastructure.

Public reports from people who have actually run it tell a consistent story:

• Official minimum requirements (per Sentry docs): 4 CPU cores, 16 GB RAM + 16 GB swap, 20 GB disk. 32 GB RAM is recommended. The stack is disk-I/O heavy due to databases, message brokers, and other services running on a single machine.
• A complex stack with many services and containers — typically 20+ (including PostgreSQL, Redis, Kafka, Zookeeper, ClickHouse, Snuba, Relay, Symbolicator, web workers, and more). Sentry has introduced an “errors-only” mode in recent versions to reduce the number of containers for teams focused only on error tracking.
• Installation via a bash script (./install.sh) plus Docker Compose. The install process pulls images, runs migrations, and sets up configuration; users examining the scripts have noted hundreds of lines across included files.
• Ongoing maintenance: upgrades can require coordination and have been reported as disruptive by users on GitHub, HN, and Reddit. The self-hosted version comes with no commercial support or SLAs — assistance is community-driven via Discord.
• Sentry added official ARM64 support in version 25.6.0. Telebugs has offered native ARM64 support from early versions and is designed to run efficiently on modest hardware (including small ARM devices and cheap VPSes) with far lower resource requirements than a typical self-hosted Sentry deployment.

The result is that what starts as “we’ll just run it ourselves to save money and keep data private” often turns into a significant ongoing tax in infrastructure cost and engineering time.

How Telebugs is different by design

Telebugs was built from the ground up with a different goal: give teams the core capability they actually need (collect, group, and get notified about errors) without forcing them to run an entire observability platform.

Aspect	Self-hosted Sentry (typical)	Telebugs
Architecture	Complex stack with many services/containers (typically 20+ including Kafka, ClickHouse, Snuba, etc.; “errors-only” mode available)	Single Docker container
Install	Bash ./install.sh + Docker Compose (hundreds of lines of scripts reported by users)	One command (handles Docker + TLS cert if needed)
Minimum hardware	4 CPU cores, 16 GB RAM + 16 GB swap (32 GB recommended) per official docs	Runs well on 1–2 GB / 1–2 cores (see table on homepage)
ARM / small hardware	Official support since 25.6.0 (previously required community forks)	Full ARM64 Docker support
Updates	Manual coordination across components	Automatic within major version; optional manual
Cost model	Free software + your infra + your time	$299.99 once, no event quotas, ever
Scope	Full observability platform (errors + performance + more)	Focused error tracking, done well

These comparisons are based on Sentry’s official self-hosted documentation (develop.sentry.dev/self-hosted), the public docker-compose.yml, GitHub issues, and widespread user reports on Hacker News, Reddit, and the Sentry forum. Individual experiences vary depending on event volume, retention settings, and infrastructure.

We also made specific engineering choices that help on real hardware. For example, the ingestion pipeline is designed so that large payloads do not bloat the job queue (see the detailed write-up of how we fixed a 95 GB queue problem that only surfaced because of how we use SQLite under the hood). That kind of operational thinking only happens when the system is small enough for one person to reason about end-to-end.

When self-hosted Sentry might still make sense

We are not saying self-hosted Sentry is always the wrong choice. There are situations where it is reasonable:

• You are a large organization that needs the full set of Sentry features (performance monitoring, profiling, session replays, etc.) and already has a dedicated platform/SRE team that can own the deployment.
• You have strict requirements that only the complete Sentry feature matrix satisfies today and you are willing to pay the operational cost.
• You are already deeply invested in the Sentry ecosystem (custom integrations, many plugins, advanced alerting rules) and the migration cost outweighs the simplification benefit for your team.

For most teams — especially small-to-medium engineering organizations, agencies, bootstrapped companies, or anyone who just wants reliable error tracking without building a second job — the cost/benefit math is different.

What you actually get with Telebugs

Telebugs is a complete, production-grade error tracking system that is intentionally smaller:

• Full Sentry SDK compatibility — change the DSN and your existing integrations keep working (see the Sentry SDK compatible page).
• Automatic grouping with custom fingerprinting and manual merge when you need it.
• Releases and source map support so you can actually read production stack traces.
• Notifications via email, PWA push (installable on phones), and webhooks (Slack, Discord, custom).
• Collaboration tools: error notes, ownership, bulk actions, muting/snoozing with rules.
• Data retention policies you control, a full REST API, and the ability to run completely offline if needed.
• A clean, fast UI built with Hotwire (very low JavaScript) that works well even on modest hardware.

One Telebugs license covers a single domain. You can track errors from as many projects and applications as that instance can handle. There are no per-event limits and no surprise bills when something goes wrong in production when you sleep.

Frequently asked questions

How much hardware do I really need for Telebugs?

Most small-to-medium workloads run comfortably on 1–2 GB of RAM and 1–2 CPU cores. The exact numbers depend on your error volume and retention settings. We publish rough scaling estimates on the homepage based on real measurements.

Can I run Telebugs on a cheap VPS or even a Raspberry Pi?

Yes. Many people run it on low-cost VPS providers (DigitalOcean, Hetzner, etc.) and on ARM devices. The Docker image supports ARM64 out of the box.

What happens when I need more features later?

Many teams never do — focused error tracking solves the majority of “we don’t know what’s broken” problems. If you eventually need distributed tracing, profiling, or other observability signals, you can run Telebugs alongside another tool for those specific needs while keeping error tracking simple and unlimited.

Is Telebugs open source?

No. It is commercial software with a one-time purchase model. You receive the full source after purchase and are free to modify it for your own use (subject to the license). We chose this model because it lets us focus on building one excellent, well-supported product without the pressures of open-source infrastructure maintenance at scale.

How do updates work?

Each installation phones home once per day to check for updates within the same major version. Updates are free. You can disable the check and update manually if you prefer. Major version upgrades (1.x → 2.x) are optional and may have a cost.

Want reliable error tracking without turning it into a second job?

Read the Telebugs manual (installation usually takes under 10 minutes), watch the install video on the homepage, or get your copy and run it on your own server today.