1. Scope and responsibility
This policy explains information handling for the BugCapsule website, pilot enquiries, and hosted debugging service. BugCapsule helps development teams capture failures and replay them in a controlled environment. The organisation integrating an SDK decides what its app records and is responsible for its own privacy notices and lawful collection. For self-hosted installations, that organisation also controls the backend and its storage.
Where BugCapsule processes capsule data on a customer’s instructions, the applicable pilot agreement and any data processing agreement describe those responsibilities. This notice does not replace the privacy policy of an app that uses BugCapsule.
2. Information involved
- Enquiries: your name, email address, and the details and correspondence you choose to send.
- Technical requests: hosting and service infrastructure may process IP addresses, request times, browser or client details, requested paths, and diagnostic logs to deliver and protect the service.
- Capsules: depending on platform and integration, app and build metadata, device or browser context, session identifiers, errors and stack traces, UI actions, tracked text, navigation, logs, application state, selected storage values, and HTTP request and response data.
- Project activity: project configuration, capsule labels, replay runs, verification results, and share-link metadata.
Application payloads can contain personal information. Names, email addresses, postal addresses, and order contents are not automatically removed simply because they are personal data.
3. Website, cookies and enquiries
The current landing page loads its fonts, images, styles, and scripts from its own site. Its application code does not set analytics or advertising cookies, use browser storage to track visitors, or collect form submissions.
Enquiries reach us when you email contact@bugcapsule.com. Your email provider handles the message under its own terms. Avoid putting passwords, access tokens, customer records, or unredacted capsules in an enquiry.
Following links to GitHub, documentation, or other services may expose request information to those services. Their privacy practices apply when you visit them.
4. How information is used
Enquiry information is used to respond, assess pilot fit, arrange integration support, and manage the customer relationship. Project and capsule information supports capture, storage, replay, verification, troubleshooting, and the customer’s requested sharing. Operational information supports availability, abuse prevention, incident investigation, and service maintenance.
Where applicable privacy law requires a legal basis, the basis depends on the activity: steps requested before entering a contract and performance of that contract; legitimate interests in responding to business enquiries and securing the service, balanced against individual rights; compliance with legal obligations; or consent where required. Customer-controlled capture requires the customer to establish its own appropriate basis.
5. Capture controls and redaction
SDK redaction runs before encoding and upload. Integrators can configure excluded endpoints, network-body capture, redaction keys and patterns, and hooks for events and checkpoints. Available controls vary by SDK and version. Review actual capsules before expanding capture.
The pilot is intended for QA and internal builds with production capture off. Project controls include retention, capture configuration, and a kill switch. Remote changes take effect according to the SDK configuration-refresh behaviour; a kill switch is not a way to recall files already downloaded by another person.
7. Retention and deletion
Backend capsule retention is configured per project. The documented default is 30 days, with a configurable range of 1–365 days. Expired capsules are removed by the scheduled retention sweep. Deleting a capsule removes API access to it, its run history, and its share links; failed file cleanup is retried.
The documented backup default is 14 days. Deleted data may remain in existing backups until those backups expire. Local SDK queues and saved history depend on platform and configuration. Copies downloaded to developer machines or sent to other recipients are controlled by those recipients.
Enquiry and support correspondence should be retained only as needed to manage the enquiry or relationship, resolve disputes, and meet applicable recordkeeping requirements. Project-wide deletion during the pilot requires an operator request. To locate a particular person’s data, provide relevant app, project, time range, or capsule details without including unnecessary sensitive information.
8. Hosting, transfers and security
The backend documentation describes the hosted pilot on an EU server with Hetzner and off-site backups. Confirm the actual hosting and backup locations in your pilot agreement; self-hosted locations depend on the customer. Access from another country may involve an international transfer. Any required transfer safeguards must be established for the relevant arrangement.
The documented deployment uses HTTPS, project-scoped credentials, hashed API keys, and expiring share tokens. Capsule files and the database are not encrypted at rest by the application itself; they rely on the hosting environment. No storage or transmission method eliminates all risk, and these features do not constitute a certification or a guarantee of legal compliance.
9. Choices and privacy requests
Depending on your location and applicable law, you may have rights to access, correct, delete, or receive a copy of personal information, restrict or object to certain processing, and withdraw consent where consent is the basis. Rights can be subject to exceptions and identity verification. You may also complain to your local data protection authority.
For information captured by an app using BugCapsule, contact that app’s operator first: it controls the capture and can identify the relevant project. Pilot customers can raise access, deletion, and incident requests with their designated BugCapsule contact. Do not send project secrets or share tokens as proof of identity.
10. Children and sensitive information
BugCapsule’s pilot is intended for professional development teams, not for children to use directly. Integrators should use test data and avoid capturing children’s information, payment credentials, health records, or other sensitive personal data. Any proposed use involving such information requires an appropriate agreement and assessment before collection.
11. Updates and contact
Updates to this policy will appear on this page with a revised date. Material changes affecting an active pilot should also be communicated through the pilot relationship before the relevant new processing begins.
For privacy enquiries, email contact@bugcapsule.com or use your designated pilot contact.
Google and GitHub sign-in
When you choose Google or GitHub to sign in or create an account, BugCapsule receives your provider account identifier, verified email address and display name. We use these details to authenticate you, maintain your account and apply workspace and project permissions. Signing in with GitHub does not grant repository access. Provider access tokens are used during sign-in and are not retained by BugCapsule.
The dashboard uses an essential session cookie and a short-lived cookie that protects the sign-in process. Connecting an additional sign-in provider requires an authenticated session; matching email addresses alone do not link accounts. You can end sessions from Account and revoke provider authorization through your Google or GitHub settings. Contact contact@bugcapsule.com for account deletion requests.