Security at DeadBro

How we protect your account and your application data.

Infrastructure Data Redaction Authentication Compliance

Last updated: October 12, 2026

DeadBro APM runs inside your infrastructure via the dead_bro gem, and the data it collects — request traces, SQL, errors — can be sensitive. This page describes, concretely, what we do to protect it. For our data-handling policy and legal basis, see our Privacy Policy and GDPR page.

1. Infrastructure & Network

  • Production data is hosted on dedicated servers located in Germany — no shared/multi-tenant hardware.
  • All traffic to the dashboard, API, and marketing site is proxied through Cloudflare for DDoS protection, WAF, and TLS termination.
  • HTTPS is enforced everywhere; there is no unencrypted path to reach the ingest API or the dashboard.
  • Data is logically isolated per account at the application layer — every query is scoped to the authenticated account.

2. Sensitive Data Is Redacted Before It Leaves Your Server

This is the part most APM vendors don't do: the dead_bro gem redacts likely-sensitive values inside your app, before the payload is ever sent — not after we receive it.

  • Request params, headers, and session data are scanned key-by-key (including nested keys like user[password]) and any key matching password, token, secret, api_key, access_key, auth/authorization, credential, ssn, or credit_card/cvv/cvc is replaced with [FILTERED].
  • Captured SQL query text is scanned for the same sensitive keywords appearing as literal values (e.g. token = "...") and those values are stripped, even inline in the query string.
  • Backtraces are filtered so file paths that look like they contain a credential (e.g. a path segment with "secret" or "token" in it) are redacted.
  • Error reports pass through the same redaction before being serialized and sent.

This runs synchronously in your application process, so a leaked API key or password in a request param never reaches our servers in the first place.

3. Account & Authentication Security

  • Passwords are hashed with bcrypt (12 stretches) — we never store or can recover a plaintext password.
  • Email confirmation is required before an account can sign in.
  • Accounts are automatically locked after repeated failed sign-in attempts, and sign-in activity is tracked.
  • OAuth sign-in is available via Google, GitHub, and Apple, in addition to email/password.
  • Sensitive stored credentials (e.g. uptime-check basic-auth passwords) use field-level encryption at the database layer, not plaintext columns.

4. Access Control

  • Team members are added by invitation only, with owner/member roles per account.
  • Access can be revoked at any time by an account owner.
  • MCP access (for AI clients querying your APM data) uses per-user bearer tokens you generate and can revoke independently of your login credentials.

5. Payments

Billing is handled entirely by Mollie, our PCI-compliant payment processor. DeadBro never sees or stores your card details.

6. Data Retention & Backups

Application data retention depends on your plan. Backups are taken automatically and old backups are rotated and purged on a schedule. See the pricing page for current plan limits and the GDPR page for data handling.

7. Compliance

DeadBro is operated by Ruby Dev SRL (Romania) and processes data under EU GDPR. A Data Processing Addendum (DPA) is available on request at [email protected]. Full detail on sub-processors, data location, and your rights is on the GDPR page.

8. What We're Building Next

In active planning, on our near-term roadmap:

  • Two-factor authentication (TOTP) for all accounts.
  • SSO/SAML for enterprise identity providers (Okta, Azure AD, Google Workspace).
  • Account audit logs — who viewed what, and who changed account/alert/team settings.
  • User-configurable redaction rules, on top of the automatic key-based scrubbing described above.

9. Reporting a Vulnerability

If you believe you've found a security vulnerability in DeadBro, please email us at [email protected] with details. We ask that you give us a reasonable window to investigate and fix an issue before any public disclosure, and we won't pursue legal action against good-faith, non-destructive security research reported to us this way.