Security and your data
Error reports can contain more than a backtrace. You should know where they go and who can read them. Here’s how that works in Telebugs.
Choose who runs the server
With Self-hosted, your apps send reports to your Telebugs instance. You choose its location and control its network, storage, and backups. Core error tracking happens there; it doesn’t pass through a Telebugs cloud ingestion service.
With Managed, we run a private instance for you in Europe, the United States, or Singapore. We handle server security, updates, backups, email delivery, and uptime. We have the access needed to operate it. Managed doesn’t include source code or direct server access.
In both cases, you decide what your applications send and who on your team should see it. The two hosting options let you choose how much of the operating work you want to own.
Keep secrets out of error reports
A password in a request body is still a password when it reaches your error tracker. Filter unnecessary data in your SDK, then use Telebugs’ sensitive-data scrubbing to remove fields before storage. Inspect a test report to check what actually arrived.
Choose how long to keep reports and release artifacts with retention controls. Those are separate policies, and deleting live data doesn’t remove copies from old backups. Self-hosting gives you control over location; your data handling and contracts still need to meet your own obligations.
Access is a choice
Give members access to the projects they work on. Keep administrator access with people who need to see and manage the whole installation. Review API keys and notification destinations as carefully as user accounts.
Connecting an AI tool through MCP lets that tool read the error context you authorize. Read and write permissions are separate, and you can revoke a client from Connected MCP apps. Data a tool retrieves may reach its provider, so choose a tool whose data handling you accept. See how an agent investigates an error before connecting one.
Know what leaves your server
Self-hosted Telebugs can handle core error tracking without outbound internet once it’s installed and any legacy license receipt has been migrated. Downloads, update checks, legacy authorization, external notifications, and integrations need their own network access. Disable automatic update checks if you operate an isolated instance.
Recovery downloads expose the request IP and requested operating system and architecture. Restore also sends a brief, best-effort status report about its progress; the service associates it with the customer account and licensed domain. Production error data and recovery secrets aren’t included. Failed status delivery cannot block a restore or rollback.
Treat the backup like the server
A Telebugs backup contains your databases, uploaded files, configuration, and recovery secrets. Keep it encrypted, access-controlled, and off the server. Verification catches corruption; protecting the archive is still your job when you self-host.
A restore drill also restores queued jobs. Block production notification destinations until you’ve configured safe test endpoints. Follow the backup and restore runbook for recovery, checks, and cutover.
The self-hosted purchase includes source code you can inspect and change for your licensed installation. The license spells out those rights. Our product facts cover the technical details. Have a question this page doesn’t answer? Email me. I’m Kyrylo, the developer behind Telebugs, and I handle support myself.