Telebugs Installation Readiness Checklist | Self-Hosted Error Tracking

A go-live checklist for running Telebugs on your own infrastructure

Use this page when your team is past "can we run it?" and ready to decide "are we prepared to run it well?" It turns the broader installation expectations into a concrete readiness review for infrastructure, networking, updates, backups, application SDKs, and rollout.

Short version

Telebugs is designed to be a focused Docker-based self-hosted app, but production readiness still depends on ordinary infrastructure work: a reachable hostname, TLS, persistent storage, backups, update ownership, notification paths, and a staging test error from the apps that will report to it.

  • Install only after DNS, TLS, storage, backups, and network routing are owned.
  • Validate application SDK behavior in staging before changing production DSNs.
  • Decide which outbound features are allowed: update checks, email, webhooks, or chat notifications.
  • Keep rollback simple: preserve the old DSN or previous error-tracking path until rollout is proven.
  • Use the official installation docs for commands; use this page for readiness decisions.

Owner map

Owner Decisions to make Evidence to keep
Infrastructure Server, storage, DNS, TLS, firewall rules, backup location, restore process. Host details, access route, backup notes, restore test result, monitoring owner.
Application team Which apps report errors, which environments send data, which SDK fields are allowed. SDK configuration, sample staging event, release naming, source map or artifact workflow.
Security or operations Access review, outbound integrations, update checks, token handling, retention policy. Admin list, webhook destinations, token rotation notes, retention settings.
Buyer or project owner License fit, support path, go-live timing, rollback threshold, post-purchase owner. License review, purchase owner, rollout decision, support contact.

Readiness checklist

Area Ready when Common miss
Server You have a Linux server, VM, VPS, private-cloud instance, or internal host that can run Docker. The server exists, but nobody owns disk monitoring, host patching, or restart behavior.
DNS and TLS The Telebugs UI and ingestion endpoint have a hostname and trusted TLS path. Server-side apps work, but browser SDKs cannot reach or trust the DSN endpoint.
Network routes Teams can reach the UI, and every reporting runtime can reach the DSN endpoint. Web requests report correctly, but workers, mobile apps, or private-network clients do not.
Notifications Email, webhook, Teams, Discord, push, or custom notification routes are approved and tested. The instance receives errors, but nobody gets alerted in the expected channel.
Storage and retention Retention, artifact cleanup, source maps, and disk monitoring are set before production traffic. A noisy deploy creates far more stored events than the initial server plan expected.
Backups The database, uploaded artifacts, configuration, and restore instructions are backed up. Backups exist, but nobody has restored them on a replacement host.
Updates Someone owns 1.x updates, release note review, and manual update steps for isolated environments. Outbound update checks are blocked, but no manual update process exists.
SDK validation A staging app sends controlled errors with expected context, grouping, release, and environment. The DSN changed, but source maps, worker errors, or release values were never validated.
Rollback The old DSN or previous error-tracking path remains available until production rollout is proven. The team changes production reporting without a clean path back.

Before installing

  • Read the pricing page and software license if source access, domain scope, or procurement review matters.
  • Choose the installation hostname and decide whether it is public, VPN-only, private-network, or customer-environment only.
  • Decide where TLS terminates: reverse proxy, load balancer, tunnel, internal certificate path, or another existing standard.
  • Decide whether the instance may use outbound internet for update checks, email, webhooks, chat notifications, or support diagnostics you explicitly initiate.
  • Choose who can administer Telebugs and who only needs project-level access.
  • Prepare a backup destination that is separate from the Telebugs host.

Staging validation

A staging install should prove the workflow, not just prove that the service starts. Send real controlled errors from the same kinds of runtimes that will report in production.

  • Send one web request error and confirm stack traces, grouping, tags, environment, release, and request context.
  • Send one background job, queue, scheduled task, or worker error if the app uses those paths.
  • For browser apps, confirm source maps resolve and the DSN endpoint is reachable from the browser.
  • Confirm sensitive fields are scrubbed before or during ingestion.
  • Trigger the intended notification path and confirm the right people receive it.
  • Invite a teammate and confirm access boundaries behave the way your team expects.
  • If migrating from Sentry, use the stack migration examples before changing production DSNs.

Production rollout

  1. Start with one lower-risk app, environment, project, or service.
  2. Keep the previous error-tracking destination available during the first rollout window.
  3. Watch event volume, disk growth, notifications, grouping quality, and source map behavior.
  4. Review the first production reports for sensitive data before broadening coverage.
  5. Document the final DSN, owner, backup process, update process, and rollback note.

When a demo is better

Use a private demo when the main question is product workflow: project setup, team access, notifications, MCP access, issue triage, or source map behavior. Install Telebugs yourself when the main question is infrastructure fit: internal DNS, TLS, firewall rules, backups, update policy, or private-network routing.

Frequently asked questions

Is this the install manual?

No. This page helps with readiness decisions. Use the official installation docs for the actual installation steps.

Does Telebugs need public internet?

No for core error tracking. Your apps need a route to the DSN endpoint, and outbound internet is only needed for the external features you allow.

Can we run on a small VPS?

Often yes for modest production volume, but set retention, disk monitoring, backups, and ingest expectations before relying on a small server.

Should we test restore before production?

Yes. A backup plan is incomplete until someone has restored the database, artifacts, configuration, and instructions on another host.