Telebugs Security and Trust | Self-Hosted Error Tracking
A practical trust model for error data you operate yourself
Telebugs is built for teams that want production error tracking inside their own infrastructure boundary. This page explains what Telebugs controls, what your team controls, and what to review before buying. If your team needs a step-by-step review path, use the security review checklist.
Short version
Telebugs is self-hosted commercial software with source code provided after purchase. Your applications send errors to the Telebugs instance you run. Core error tracking runs locally. Initial downloads, update checks, legacy receipt migration, external notifications, and your own integrations use outbound network access. Restore lifecycle status is sanitized, best effort, and never includes production error data.
- Data boundary: error reports land on your Telebugs server.
- Source access: the purchased app source is available for your own Telebugs installation under the license.
- Network control: isolated environments can disable automatic update checks and update manually.
- Access control: users, project access, API keys, webhooks, and MCP clients should be reviewed like any production admin surface.
- Compliance: Telebugs provides controls; it does not make legal or compliance guarantees by itself.
Shared responsibility
| Area | Telebugs provides | Your team owns |
|---|---|---|
| Application data | A self-hosted backend for Sentry SDK error events, grouping, reports, notes, releases, retention, and notifications. | What your apps send, SDK filtering, secrets handling, and whether production data belongs in an error report. |
| Infrastructure | A focused Docker-based application designed for small-server operation. | The server, TLS, firewall rules, DNS, disk, backups, monitoring, and restore testing. |
| Updates | 1.x updates included with the license, plus update checks when network access is allowed. | Choosing when to update, reviewing release notes, and manually updating isolated environments. |
| Access | Project access controls, API access, connected MCP apps, notification settings, and retention controls. | User lifecycle, project membership, admin review, webhook destinations, and token rotation. |
Data boundary and offline mode
Telebugs does not require a hosted Telebugs ingestion service. Your apps point their Sentry SDK DSNs at the instance you operate. That makes the deployment boundary concrete: the server, database, files, backups, logs, notification destinations, and network routes are yours to design.
Core error tracking works without outbound internet: ingestion, grouping, reports, releases, source maps, notes, retention, purging, and local administration after license receipt migration. Initial downloads, automatic update checks, one-time legacy receipt migration, and external email, push, webhook, or chat delivery depend on network access. Format-2 backup verification and authorization are offline; restore may still need registry access when the captured image is not already present.
Source access and license
Telebugs is not open source, but the source code is included after purchase. You can inspect it and modify it for your own Telebugs installation under the license. The boundary matters: the license does not let you redistribute Telebugs or reuse its code in another product.
Review the software license and pricing page before purchase if your team has procurement, legal, or source-review requirements.
AI and MCP access
Telebugs supports MCP so approved AI coding tools can inspect structured error context from your self-hosted instance. Treat MCP access like production tooling access: approve only the clients you trust, scope access, review connected apps, and revoke access when it is no longer needed.
See MCP error tracking for the user workflow and privacy-first error tracking for the data-boundary angle.
Backup and restore expectations
Self-hosting means backups are part of your security posture. The
telebugs data backup command creates a mode-0600,
manifest-backed archive containing the SQLite databases, uploaded
artifacts and source maps, configuration, encryption keys, application
secret, and immutable image identity. It stops a running instance for
validation, archiving, and archive verification to create a consistent
snapshot, then restarts the instance. Backup time grows with data and
disk speed, so large installations should schedule a maintenance
window. Because the archive contains recovery secrets, store it
encrypted and separate from the Telebugs server. Manifest verification
detects corruption; it is not an external signature, so the backup
location must also be access-controlled and tamper-resistant.
Restore verifies and stages the archive before changing an installation, uses the captured image digest, retains the previous storage and configuration, and automatically puts them back if the restored instance does not become ready. This protects the Telebugs data unit; your team still owns host backups, off-server replication, restore drills, registry access, DNS, TLS, and infrastructure monitoring. The archive includes the queue database, so a drill host must not reach production notification destinations until restored jobs are contained and safe test endpoints are configured.
The public recovery bootstrap sends a best-effort event containing the request IP observed by auth. Its binary request also includes the selected operating system and architecture. These download events do not contain a license token or backup identity.
New backups contain a signed, same-domain recovery receipt and can
authorize restore offline. Legacy manifest backups require online
exact-domain authorization from auth.telebugs.com; auth
never changes the licensed domain. Restore sends best-effort lifecycle
status with a random correlation ID, backup format, fresh or replacement
target, and fixed failure-stage and rollback enums. Auth adds customer
email, the stored licensed domain, and observed request IP from
server-side state before forwarding to Telesink. Archive names, paths,
error messages, secrets, raw license tokens, database details, and
notification destinations are not forwarded. Telemetry has a short
timeout, no retries, and cannot alter restore or rollback.
For the operational checklist, read installation expectations. For a production readiness pass, use the installation readiness checklist. For security review questions, read the security review checklist. For retention and purging, read data retention and compliance. For exact commands and recovery behavior, read the backup and restore runbook.
What this page does not claim
- It does not claim Telebugs makes your organization compliant by itself.
- It does not replace legal, security, procurement, or incident-response review.
- It does not mean you should send every possible request field to error tracking.
- It does not remove your responsibility to patch the server, restrict access, rotate secrets, and test backups.
Frequently asked questions
Does Telebugs send error data to a Telebugs cloud service?
No hosted Telebugs processing is required. Your applications send errors to the Telebugs instance you run.
Can Telebugs run without outbound internet?
Yes for core error tracking. Initial downloads, legacy receipt migration, external notifications, and unavailable image retrieval require network access. Format-2 backup authorization works offline, and failed restore telemetry never blocks restore or rollback.
Is Telebugs open source?
No. Telebugs is commercial source-provided software. You receive source access after purchase under the license.
Does Telebugs make us compliant?
No. Telebugs gives you technical controls for self-hosted error data, but compliance depends on your data, contracts, policies, infrastructure, and jurisdiction.