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 getdrums.app/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.getdrums.app that keeps you signed in, and one on getdrums.app 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.

Slack and Linear, if you connect them: both are optional and neither is needed to use Drums, the record is in the console and in your git log either way. Once connected, Drums sends that workspace what it takes to say something useful there: the repository name, a short failure signature (the error class and where it happened), a summary of what Drums proposes or has done, and an approval link back to app.getdrums.app. Following that link approves nothing (it opens a page, and deciding is a signed-in approver pressing a button) but anyone who can read the channel or issue can read the link and the summary beside it, so choose where approvals are delivered accordingly. Drums does not send your source code, your diffs, your telemetry payloads, or the body of a replayed request. Once a message is in your Slack or Linear it is held under their terms and their privacy policy, and it stays there after you disconnect: we cannot delete a message we posted into somebody else’s workspace.

Railway, Vercel, Supabase and PostHog, if you connect them: these are read, where Slack and Linear are written to, and each is optional. From Railway and Vercel Drums reads what shipped and when, deploys, builds, and Vercel’s runtime logs, which carry the method, path and status of requests your application served. That is how a failure is tied to the change that caused it. From PostHog Drums reads the exceptions you already collect, and the metadata of session recordings you already make; it does not turn recording on, and enabling it is a decision you make in PostHog. Supabase is the one connection that is not read-only: it carries database write, because the point of connecting a database is that a repair can propose a change to it. Proposing is all it does, the statement is a diff an approver reads and approves like any other, and nothing runs against your data without that. None of these four is written to by Drums except Supabase, and only then through an approval. Each is authorised by somebody on your account and stops the moment it is disconnected.

Agentation reports, if you connect it: the one connection where what arrives was written by somebody who is not you. Agentation is a browser annotation widget you place in your own software; point its webhookUrl at the address Drums issues and a note one of your users typed is sent to us, their free text, the page they were on, and Agentation’s description of the element they clicked and its position in the page. Free text can contain anything the person chose to type, including personal data, and we cannot know what is in it before it arrives: you decide whether to place the widget at all, and you are the controller of what your users write into it. We strip the query string and fragment from the page address before storing it, so session tokens and signed links riding in a URL are not kept, and we store no request, stack or status code alongside it. Two further pieces of context are kept and one of them deserves saying plainly. The first is the chain of React components the element sits inside, which is your own code’s structure and is already in the bundle you serve. The second is a short sample of the text displayed around the element, text the person did not type, taken from their screen so that a repair can tell which control was meant. On a billing or a profile page that can incidentally include something personal, which is why it is capped at 500 characters: the cap is a privacy bound, not a storage one, and we will not raise it because values are being cut. If that is more than you want leaving your software, do not place the widget on screens where it would be read. Reports are readable by every member of your account and are deleted with the account.

Disconnecting, and what it revokes: disconnecting from the console revokes the credential at the provider wherever the provider allows it, rather than only ceasing to use it. For Slack we call auth.revoke, which retires the bot token in your workspace there and then. Linear, Railway, Vercel, Supabase and PostHog offer no way for an application to retire its own token, so we destroy our copy (access and refresh both) and you can remove the Drums application from that provider’s own settings to end it on their side. We say which of the two happened rather than reporting both as revoked: telling you a credential was retired when only our copy was is the kind of assurance that reads fine until it matters. Agentation is a third case and the simplest: the address is one we issued rather than a grant held somewhere else, so removing it in the console ends it outright and immediately, with nobody to ask. Deleting your account performs the same revocation first, before anything is erased, so closing a Drums account cannot leave a live token behind.

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.

Slack, Linear, Railway, Vercel, Supabase and PostHog are a different relationship and are named separately for that reason. They are not processors we chose on your behalf: they are your workspaces, projects and accounts, connected at your request by somebody on your account, and Drums writes into them what the section above describes. That sharing starts when you connect and stops when you disconnect.

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 revokes every connected credential (Slack at Slack, and the rest by destroying our copy) and then 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, including its integrations: one person leaving does not disconnect a team’s Slack.

You can also edit your name, job title and email address at any time from the console, or write to us at sahil@getdrums.app 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@getdrums.app.