Solution

Privacy-first bug reporting tool

BugBundler captures screenshots, logs, and network context locally, then exports a portable report your team can share safely.

Privacy by default

  • No cloud upload required for bug data.
  • No server infrastructure to maintain.
  • Portable report format for controlled sharing.

What "privacy-first" means in practice

Most bug-reporting tools work by shipping your captured page to a vendor's servers, where it is stored and becomes someone else's data-protection problem. BugBundler inverts that: capture, annotation, and report generation all happen in the browser, and the output is a single HTML file on your own disk. There is no report hosting on our side and no dashboard of your captures — so screenshots, DOM snapshots, and console or network logs stay on the machine that recorded them unless a person deliberately sends the report somewhere.

The one route that involves us at all is the optional Jira integration. If your admin has connected a Jira site and a reporter chooses to file a report into it, that one request passes through our infrastructure in Finland in order to reach your own Jira site. It is held in memory for the length of the request and discarded: never written to our database, our file storage or our logs, and never retained. The report ends up in your Jira project, under your permissions and your retention rules.

That distinction matters for anyone who has had to answer a security questionnaire. A tool that stores none of your report content cannot leak it, cannot be compelled to hand over what it does not have, and does not appear in your record of processing activities as a recipient that retains that content.

Sensitive data is redacted before it reaches the report

Local capture alone is not enough — a screenshot of a logged-in admin page can still expose credentials to whoever opens the file. BugBundler redacts known-sensitive fields automatically, and the same rules apply to both the screenshot and the DOM snapshot, so a field that appears blurred never leaks its raw value in the markup underneath.

  • Password inputs, credit-card number, CVC, and expiry fields, and inputs whose names suggest card, credit, CVV, or SSN data are masked by default.
  • Any element you mark with data-redact is masked, and you can add your own CSS selectors for app-specific fields.
  • Captured keys matching patterns like token, secret, password, auth, session, cookie, jwt, csrf, api_key, and private_key are replaced with a configurable mask.
  • Screenshot redaction is on by default rather than opt-in, so the safe path does not depend on remembering to enable it.

Per-domain capture scopes

Not every application should be captured the same way. You can set rules per domain that control whether capture is allowed at all and which categories are collected. Console and network context are included by default; browser storage is excluded by default, since it is the category most likely to hold session material. That lets you keep rich diagnostics on your own staging environments while capturing far less on a customer's production system.

Where the data that does leave your machine lives

BugBundler is not a zero-server product — accounts, workspaces, seats, and billing have to live somewhere. That data is processed exclusively in EU regions: Cloud Functions in Finland (europe-north1) and Firestore in Stockholm, Sweden (europe-north2). Traffic is encrypted with TLS, and data at rest uses Google Cloud's default encryption. Card details go directly to Stripe under its own PCI-DSS certified infrastructure; BugBundler never stores full card numbers.

We also don't run analytics or session-replay SDKs inside the extension. For the full picture, including subprocessors and what we have not yet certified, see Security, Compliance, and GDPR & EU data residency.

Common questions

Does the extension need internet access to capture a bug?

No. Capture, annotation, and export run locally, so the workflow keeps working on an air-gapped or network-restricted machine. Account setup and seat management do require connectivity.

Who can read an exported report?

Anyone you give the file to — it is a self-contained HTML document that opens in any browser with no login and no BugBundler account. Distribution is entirely under your control, which is the point, and also the reason redaction defaults matter.

Is BugBundler SOC 2 or ISO 27001 certified?

Not yet, and we would rather say so plainly than imply a certification we don't hold. Compliance tracks what is in place today and what is still on the roadmap.

Check it against your own data

See what a report contains before you trust it

Capture a bug on a page with real data in it, open the exported file, and read exactly what was and was not written into it.