Privacy Policy

Who we are

The Service is operated by Drums Labs, Inc., a Delaware C corporation. This policy explains what we collect and what stays with you.

What we collect

Website and console: basic, aggregate analytics — pages visited, referrer, approximate region — processed by PostHog on our behalf. We deliberately do not enable its click-and-form autocapture or its session recording, so we hold no replay of your screen and no record of what you typed. We do not run invasive tracking or sell advertising, and we honour your browser’s Do Not Track signal.

Console errors: when something breaks in the console itself, the browser error and its stack trace are sent to the same processor so we can fix it. This is diagnostics, not analytics, and it concerns our code — it never contains anything from your repository, which Drums does not read from a browser at all.

The install script: each time drums.sh/install serves the install script, we record one row: the time, the release being served, and a coarse platform bucket (macOS with its CPU architecture, Linux, or other) only when the request itself states it — a plain curl does not, and we store “unknown” rather than infer. We do not store your IP address, your User-Agent string, a cookie, or any location for these downloads; the table has no column to put them in. Nothing links one download to another, or to you.

Contact and booking: if you email us or book a call, we receive what you share — your name, email, and scheduling details (bookings are processed by Google Calendar under Google’s privacy policy).

Accounts: your email address; the name and job title you choose to give us; and, for the organization, its name, team-size band, and how you heard about us. Every one of those beyond the email address is optional, and the onboarding screen can be skipped outright.

Machine credentials: when you connect a machine with drums login, we store a SHA-256 hash of the token and the first characters of it so you can tell two apart. We never store the token itself, which is also why the console can only show it to you once.

Your account’s history: an append-only record of account events — who approved a machine, who revoked one, who changed a role. It is never edited after the fact, including mistakes, and it is deleted with the account.

Cookies: a session cookie on app.drums.sh that keeps you signed in, and one on drums.sh that records only that somebody is signed in, so the marketing site can offer a dashboard link instead of a sign-in one. That second cookie contains no token, no email, and no account identifier — deliberately, so that the session itself never has to be shared across our subdomains.

The CLI, anonymously: drums watch sends a small heartbeat on start and every six hours: a random install id (128 random bits generated on your machine and stored at ~/.drums/install-id — not derived from your hostname, MAC address, username, or repository path), the Drums version, your operating system and CPU architecture, and four running totals — failures detected, repairs attempted, repairs verified, repairs shipped. It carries no repository name, file path, branch name, commit sha, error message, stack trace, request body, URL, agent output, or anything else derived from your code; those are absent from the message rather than redacted from it. The first run that would send anything prints a notice saying all of this before it sends. To send nothing at all, set DRUMS_TELEMETRY=off or put telemetry = “off” in .drums/config.toml. Full detail: the telemetry section of the docs.

The product: to run the loop, Drums reads your repository, your telemetry, and the requests it replays. Error payloads and replayed requests can contain personal data, so payloads are redacted at capture, with the rules visible and editable — a reproduction can use a value the record never stores. In local and private mode the container, the replayed request, and the failing material never leave your environment; Drums moves the record, not the material.

How we use it

To operate and improve the Service, respond to you, schedule calls you request, secure the Service against abuse, and send product updates. We do not sell your personal information.

Sharing

We share data only with the service providers needed to run Drums — hosting (Vercel), the database and sign-in (Supabase), email (Resend), scheduling (Google Calendar), product analytics (PostHog), and the model provider you configure — each bound to process it on our behalf; with authorities when the law requires it; or as part of a corporate transaction, in which case this policy continues to apply to data collected before the change. Enterprise accounts may point Drums at their own model provider agreement, in which case we add no new AI subprocessor.

Security

Data in transit and at rest is encrypted. Drums holds no long-lived production credentials: authority is issued as short-lived, per-task, revocable capability. Access to production systems is restricted and audited. A SOC 2 Type I examination is in progress; contact us for our current security documentation.

Retention and your rights

We keep personal data only as long as needed for the purposes above.

You can delete your account yourself, from the console, without asking us. If you are its only member this removes the account, its connected repositories, its machine credentials and its history together — there is no retained copy and it cannot be undone. If other members remain, your access is removed and the organization keeps its record.

You can also edit your name, job title and email address at any time from the console, or write to us at sahil.jagtap45@gmail.com for access to, correction of, or deletion of anything else. If you are in a jurisdiction with statutory privacy rights (GDPR, CCPA, and similar), we honor the rights those laws provide.

Children

The Service is not directed to children under 16, and we do not knowingly collect their data.

Changes

We will post any changes to this policy here with a new effective date. Questions: sahil.jagtap45@gmail.com.