Sentry SDK compatible | Self-hosted error tracking

The reality of the Sentry SDK ecosystem

The Sentry SDKs are one of the strongest parts of the error-tracking world. They are mature, thoroughly documented, actively maintained across dozens of languages and frameworks, and already present in millions of codebases. Telebugs speaks exactly the same wire format, so you keep that entire client-side investment.

Current information from Sentry's own documentation, public discussions, and user reports shows a consistent picture:

• Hosted Sentry is powerful but becomes expensive at scale due to per-event pricing. Many teams report surprise bills when volume spikes.
• Self-hosted Sentry is the "free" option on paper, but the official docs describe it as packaged for low-volume or proofs-of-concept, with warnings about increasing infrastructure demands over time. Real deployments often require 16+ GB RAM, 20+ containers (Kafka, ClickHouse, etc.), and ongoing maintenance coordination.
• The SDK ecosystem itself is the valuable part: rich context (breadcrumbs, user, extras, releases), excellent language support, and familiarity for developers. Moving the backend shouldn't force you to throw that away.
• Teams often end up looking for simpler self-hosted backends that accept the same SDK payloads without the operational tax.

Telebugs lets you keep the SDKs you (or your team) already know while running a dramatically simpler server side that you own forever.

How Telebugs is different by design

Telebugs accepts the exact same Sentry SDK envelopes as the official backends. The difference is what happens after the events arrive and what it costs you to operate the system.

Aspect	Sentry SDKs + official backends (hosted or self-hosted)	Sentry SDKs + Telebugs
Client code changes	None required for basic migration (just DSN).	None required (just DSN). Full context, breadcrumbs, tags, releases, etc. continue to work.
Server architecture	Hosted: usage-based pricing, data leaves your control. Self-hosted: typically 20+ containers, high RAM (16 GB+ recommended), complex maintenance.	Single Docker container. One command install (handles Docker + TLS). Extremely minimal operational surface. Low resource usage (runs well on modest hardware / ARM).
Cost model	Hosted: per-event pricing that scales with volume (can become expensive). Self-hosted: "free" but you pay in infra + engineer time.	One-time $299.99 purchase. Self-hosted only. Unlimited events forever. No recurring fees, no per-event costs, no surprise bills.
Support	Hosted: vendor support (tiered). Self-hosted: community Discord only; official docs state no dedicated support or SLAs.	Email support included with every purchase. No tiers or upsells.
Scope & focus	Full observability platform (errors + performance + replays + more in hosted; self-hosted can be heavy even for errors-only).	Focused error tracking done well. No APM bloat. Everything you need to collect, group, notify, and collaborate on errors.
Key strengths	Mature SDK ecosystem with rich context. Familiar to many teams. Hosted option for those who don't want to self-host.	Keep the entire SDK investment. Dramatically simpler + cheaper self-hosted backend. Included support. One-time cost. Lightweight and easy to run on your own hardware.

These comparisons draw from Sentry's official self-hosted documentation, public discussions (HN, Reddit, forums), competitor analyses, and widespread user reports. The SDK layer is the same; the server-side experience and cost model are where the practical differences appear.

When Sentry SDKs with Telebugs makes sense

We are not saying the Sentry SDK ecosystem is always the wrong choice with other backends. There are situations where it is reasonable:

• You (or your team) are already deeply familiar with the Sentry SDKs and want to keep that code and mental model while changing only the backend.
• You need to keep a hybrid setup (e.g. Sentry in one environment or for specific projects, Telebugs for dev/staging/unlimited or as backup).
• You value the broad language/framework coverage and rich context the SDKs provide but want to avoid hosted per-event costs or the complexity of official self-hosted Sentry.
• You are evaluating self-hosted options and the "just change the DSN" story removes a major migration barrier.

For teams that want the SDK familiarity plus a simple, predictable, owner-operated backend, Telebugs is a strong fit.

How to migrate (or adopt) in three steps

1. Keep your code exactly as it is. The Sentry SDK initialization, context, breadcrumbs, user info, and custom tags all continue to work.
2. Create a project in Telebugs and copy its DSN (the URL that looks like https://[email protected]/api/v1/sentry_errors/123).
3. Update the DSN in your Sentry.init (or equivalent environment variable / config file). Deploy. Errors start flowing to your server.

Example for a Rails app (the same pattern applies everywhere):

gem "sentry-rails"

# config/initializers/sentry.rb
Sentry.init do |config|
  config.dsn = "https://[email protected]/api/v1/sentry_errors/1234"
  config.environment = Rails.env
  # ... your existing config (breadcrumbs, traces_sample_rate, etc.) stays the same
end

The same one-line DSN change works for Python, JavaScript, Go, PHP, whatever SDK you were (or are) using.

For Ruby apps, if you want a vendor-neutral layer on top of the Sentry-compatible SDKs (so you can easily switch between backends like Telebugs and others without code changes), see the Lapsoss project and the Telebugs blog post introducing it.

Full integration guides live in the Telebugs manual and the official Sentry platform docs (just substitute your Telebugs DSN).

Supported languages and frameworks

Sentry maintains excellent SDKs for the platforms developers actually use. Telebugs works with all of them:

• JavaScript / TypeScript: Browser, Node.js, Next.js, React, Vue, Svelte, Solid, Astro, and more
• Ruby: Rails, Sinatra, any Rack app (via sentry-ruby). For a vendor-neutral abstraction layer on top of Sentry-compatible SDKs (to easily switch providers like Telebugs), see the Lapsoss project and the Telebugs blog post.
• Python: Django, Flask, FastAPI, Celery, serverless, etc.
• PHP: Laravel, Symfony, plain PHP
• Java / Kotlin: Spring Boot, Android, plain Java
• Go, .NET, Swift, Dart/Flutter, and many others via official or community SDKs

See the full Sentry SDK list and the Telebugs supported platforms appendix. If a Sentry SDK exists for it, Telebugs will accept the events.

What you gain on the server side

Once the events arrive, Telebugs gives you everything you actually need to act on errors, without the bloat:

• Automatic grouping with smart defaults (stack trace first) plus custom fingerprinting and manual merging.
• Rich context: highlighted in-app frames, full backtraces, breadcrumbs, request data, user, extras, and release info.
• Releases + source map support so production stack traces point at real source lines.
• Flexible notifications (email, PWA push, Slack/Discord webhooks, Teams) with rules so you only hear about what matters. See the notifications and rules guide.
• Collaboration features: notes, ownership, bulk resolve/unresolve, muting and snoozing.
• MCP support for AI coding tools, so authorized clients can inspect real production error context without copying stack traces by hand. See MCP for self-hosted error tracking.
• Data retention policies you control, plus a full REST API. See the retention and compliance guide.

All of it runs in a single Docker container. One command to install. Updates within a major version are free. Pay once ($299.99), own it forever, no event quotas, ever.

Frequently asked questions

Do I have to change any error-reporting code?

No. The only change is the DSN value passed to the Sentry SDK. Everything else (context, tags, breadcrumbs, sampling, etc.) continues to work as before.

Will Telebugs support future Sentry SDK features?

We track the public Sentry envelope specification and the behavior of the official SDKs. New optional fields that don't break existing ingestion are generally supported automatically. If you hit an edge case, let us know. Compatibility is a core commitment.

Can I run Telebugs alongside Sentry?

Yes. Many teams use Telebugs for staging, development, or as an unlimited backup, while keeping Sentry for production or specific projects. Or run Telebugs everywhere and turn off the Sentry SaaS ingestion.

If you're comparing Telebugs with hosted Sentry, start with the Sentry alternative page. If you're evaluating self-hosted Sentry itself and running into the complexity, hardware, and maintenance issues, we wrote a full comparison here: Self-hosted Sentry too complex?

What about importing historical data from Sentry?

Sentry does not make bulk export easy. Telebugs does not currently offer an official import tool. Most teams start fresh (errors are transient signals) or write a small one-off script using the Sentry API + Telebugs REST API if they truly need the history.

Is Telebugs only for people who used Sentry before?

Not at all. The Sentry SDKs are simply the best-documented, most widely supported way to get structured error data from almost any runtime into a server. You can adopt Telebugs as a brand-new error tracker and follow the Sentry platform docs for your language. The only Telebugs-specific value is the DSN you paste in.

Ready to point your SDKs at a server you own?

Read the Sending your first error report guide, pick your platform from the supported platforms list, or get Telebugs and be up and running in minutes.