Telebugs Security Review Checklist | Self-Hosted Error Tracking

Short version

Telebugs is self-hosted error tracking. That means the most important security questions are concrete: where error data lands, who can reach the instance, what your applications send, which outbound integrations are allowed, how updates happen, and whether backups can be restored.

Decide where Telebugs will run and who owns that infrastructure.
Confirm which application data is allowed in error reports.
Review access for users, API keys, webhooks, notifications, and MCP clients.
Plan updates, backups, restore testing, retention, and incident behavior.
Use a private demo when the team needs to inspect workflow before installing.

Review scope

Area	Questions to answer	Evidence to collect
Data boundary	Where do errors land, and which networks can reach the UI and DSN?	Target hostname, network diagram, firewall notes, and owner.
Application data	Which request fields, users, tags, breadcrumbs, and extras can be stored?	SDK configuration, scrubbing rules, retention settings, and sample events.
Access	Who can log in, administer projects, call APIs, and connect MCP clients?	User roles, admin list, token policy, connected-app review process.
Operations	How are updates, backups, restore tests, disk usage, and error storms handled?	Runbook, backup destination, restore test notes, monitoring alerts.

Pre-purchase checks

License: confirm the software license works for your company, domain, and source-review expectations.
Product scope: confirm Telebugs is being evaluated for error tracking, not as a full observability suite.
Demo path: use the live demo for a quick tour or request a private demo for team review.
Install path: review installation expectations with whoever owns servers, DNS, TLS, and backups.
Migration path: if you already use Sentry, review the Sentry migration guide before changing production DSNs.

Infrastructure checklist

Choose the server, VM, VPS, private-cloud instance, or internal host.
Choose the public, private, VPN-only, or customer-network route for the UI and ingestion endpoint.
Put TLS in front of the Telebugs web UI and DSN endpoint.
Restrict inbound access to the networks and users that need it.
Allow outbound access only for chosen features: update checks, email, webhooks, chat notifications, or your own integrations.
Decide where configuration and deployment secrets live.
Monitor disk, queue behavior, backups, and the host itself.

Application data checklist

Review the fields your Sentry SDK sends: request data, user context, tags, extras, breadcrumbs, release, and environment.
Scrub secrets and personal data before storage whenever possible.
Keep production, staging, and development environments separate enough for triage and retention.
Review source map and artifact uploads, including who can upload and how long they are retained.
Choose retention periods that match debugging needs instead of keeping detailed events forever.
Send controlled test errors and inspect the stored payload before production rollout.

Access and integrations checklist

Define who can administer Telebugs and who only needs project access.
Review API keys and rotate them when people, services, or environments change.
Approve webhook, email, Teams, Discord, push, and other notification destinations before production.
Review MCP access like production tool access: trusted clients only, scoped permissions, and revocation when no longer needed.
Document how user access is removed when someone leaves the team or project.
Keep a short owner list for incident-time decisions: muting, resolving, deleting, retention changes, and rollback.

Offline and isolated deployments

Core error tracking can run without outbound internet, but some conveniences are inherently networked. If your environment is isolated, decide this before production:

Disable automatic update checks and document the manual update path.
Use internal email, webhook, or chat destinations only if they are explicitly allowed.
Make sure application SDKs can reach the Telebugs DSN from every runtime that reports errors.
Use internal certificates or trusted TLS termination that works for servers, browsers, and mobile clients.
Plan how source maps, releases, and artifacts reach the instance without broad outbound access.

Go-live checklist

Send a staging test error and confirm grouping, stack traces, breadcrumbs, tags, user context, and release data.
Trigger one notification through the intended production channel.
Confirm sensitive fields are not stored in the final Telebugs report.
Set retention and artifact cleanup before production traffic arrives.
Back up the database, uploaded artifacts, configuration, and restore instructions.
Restore from a backup in a non-production environment.
Keep the old DSN or previous error-tracking path available until rollback is no longer needed.
Name the owner for updates, access review, and incident-time settings.

Frequently asked questions

Is this a compliance document?

No. It is a practical security review checklist. Your legal, security, procurement, and compliance teams still need to apply their own requirements.

Should we review this before or after buying?

Use it before buying if infrastructure, source access, or data handling needs approval. Use it again before production rollout.

Can we use a private demo for security review?

Yes. A private demo is useful for workflow review, user access, notifications, MCP behavior, and sample event inspection before you install Telebugs yourself.

What is the most important control?

Start with application data. Decide what your apps are allowed to send, scrub sensitive fields early, and confirm the stored reports match your policy.

Telebugs Security Review Checklist | Self-Hosted Error Tracking

A concrete review path before running Telebugs in production