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; outbound internet is only needed for things you allow, such as update checks, external notification services, or your own integrations.
- 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. Features that inherently leave the server, such as external email delivery, webhooks, third-party chat notifications, and automatic update checks, depend on the network access you configure.
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. Back up the data that would matter during an incident: the database, uploaded artifacts such as source maps, configuration, and any deployment secrets your restore process needs. Store backups somewhere separate from the Telebugs server and test a restore before you rely on it.
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.
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. Disable automatic update checks and update manually when your environment requires isolation.
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.