Privacy policy
Last updated Oct 10, 2026
Release Butler turns merged pull requests into release notes, takes screenshots of your running app and publishes the notes to a changelog page, a widget inside your product and an email to your list. This page explains what data that involves, where it goes and how long we keep it.
What this covers
This policy covers releasebutler.com, the Release Butler app, the hosted changelog page, the What's new widget and the release emails our customers send.
Our customers are companies. When a company uses the widget or sends release emails, it gives us data about its own users. For that data we act on the company's behalf, and the company decides what to send us.
Who we are
Release Butler is run by Bottelet Ventures ApS, a company registered in Denmark. We are the data controller for the data this policy describes about our customers, their team members and visitors to our site.
For the data our customers give us about their own users, such as widget readers and the people on their email lists, the customer is the controller and we are its processor. Our data processing agreement sets out how we handle that data.
Write to privacy@releasebutler.com with any question about this policy or your data.
Your account
When you sign up, we store your name, your email address, your language setting and a hash of your password. We never store the password itself.
If you turn on two-factor authentication, we store its secret and recovery codes encrypted. If you add a passkey, we store its public key, the name you gave it and when it was last used. The private key stays on your device.
Every account belongs to one organization. We store the organization's name, its settings, its members and who owns it. When you invite someone, we store their email address with the invitation and send them an email.
While you are signed in, we keep a session record on our servers with your IP address and browser details, so you stay signed in.
GitHub
You connect GitHub by installing our GitHub App on the repositories you choose. It has read-only access to repository contents, metadata and pull requests. It cannot write to your repositories.
For the repositories you include, we store each merged pull request's number, title, description, labels, link, merge date and the author's GitHub username. For commits we store the commit hash. We also store the paths of the files each change touched and how many lines it added and removed. We do not store the contents of your files.
We read your release tags so we can suggest the next version number.
The access tokens GitHub gives us last an hour, and we store them encrypted. You can uninstall the app on GitHub at any time, and we stop reading your repositories.
AI drafting
When you ask Release Butler to draft a release, we send Anthropic the changes you picked for it. For each change that is its reference, repository name, label, author's GitHub username, title, the first 600 characters of its description and up to twelve of the file paths it touched.
We also send your organization's tone, audience and writing guidance, and a list of page addresses and titles from your app, so the draft can say which screen to photograph.
To find the screen a change shows up on, Anthropic's model can also look through the repository with our GitHub App's read access. It lists file names, searches the code and reads files up to 300 lines at a time. Those excerpts go to Anthropic for that request only, and we do not store them.
Apart from those excerpts, we do not send your code, your screenshots or anything about your account.
For each call we keep a usage record with what it was for, the model, its size in tokens and the credits it used. We use it to show your usage and to bill you.
Screenshots and test accounts
To take screenshots, a browser on our servers opens the address you gave us for your app, at the screen sizes you chose. It also visits your app's pages to learn which addresses exist, and we store each address with its page title.
If your app needs a sign-in, you can give us an HTTP password, a header, or a username and password for your login form. We store the secret encrypted and only use it to sign in before a capture. Please create a test account for this, and do not use a real person's account.
The browser types the password into your login form directly. It is never sent to an AI model.
Before a screenshot is planned, Typesafe's model is shown a change's title, description and the paths of the files it touched, to judge whether the change can be seen on screen at all.
Some screenshots need a step first, such as opening a dialog. For those, Typesafe's model is shown the structure and text of the page and a short instruction, and picks what to click. When a step needs text typed into a field, a text model from OpenAI writes it.
We store the images with your releases. When you publish a release, its screenshots are shown on your changelog page, in the widget and in your release emails. A screenshot shows whatever the test account can see, so give that account test data.
Your customers' readers
The widget runs inside your product. If you tell it who is reading, it sends us that person's ID in your system and, if you choose, their name, email address and other details you pass along. We store them with the releases each reader has opened and when.
You decide whether to send this and what it contains. We process it for you, show it back to you on the Readers page and in a CSV export, and use it for nothing else.
The widget sets no cookies. It stores one value in the reader's browser: rn-arrived:<your key> in local storage, holding the ID of the last release it announced, so a new-release notice is shown only once. If you send no reader ID, we record nothing about who read what.
When you send a reader ID, the widget also records how that reader interacts with it: which releases and entries they viewed, how far they scrolled, how long a release was on screen, what they clicked and how they closed the widget. We store this tied to the reader ID you supply and show it back to you on each release. Without a reader ID, the widget sends none of it.
Your customers' email lists
Our customers can email a published release to a list of people. The customer builds the list: by adding people one at a time, pasting a list, adding readers the widget has seen, or letting us fetch it from an address they host. For each person we store their email address, their name if the customer gives it, and how they were added.
If the list is fetched from the customer's own address, we store that address, the token we send with it, encrypted, and where in the answer the people are.
When a release is sent, Resend delivers one email to each person on the list, with the sender name and reply-to address the customer chose. For each email we keep the address, the release, when it was sent and, if it was refused, why.
Every release email has an unsubscribe link, and mail programs can offer one-click unsubscribe from the email's headers. When someone unsubscribes, we remove them from the list and keep their address on that organization's do-not-email list, so no way of adding people puts them back. The record of emails they were already sent stays.
You decide who is on your list, and you can remove anyone at any time. We process the list on your behalf and use it only to send your release emails. Make sure you are allowed to email the people you add.
Payments
Paid plans are sold by Paddle, our reseller and merchant of record. When the owner subscribes, we give Paddle their email address and the organization's name. Paddle collects the card and billing address itself, and handles them as a separate controller under its own privacy policy.
From Paddle we store its references for your customer record and subscription, and the subscription's status, plan and current billing period, so we can give your organization the right plan and credits. We never see your card details.
Cookies
We set a session cookie to keep you signed in and an XSRF-TOKEN cookie to protect forms against forgery. The app does not work without them.
The appearance cookie remembers whether you picked light or dark mode and lasts a year. The sidebar_state cookie remembers whether the app's sidebar is open and lasts a week.
We sometimes test two versions of the front page. A visitor who is not signed in gets an experiment_visitor cookie with a random ID, so they keep seeing the same version. It lasts 180 days. We record which version was shown and whether the visitor signed up. Signed-in members are not part of these tests.
We use no advertising cookies and no third-party tracking.
Why we may use your data
We use your account, organization and repository data because we need it to provide Release Butler to you under our terms of service.
We keep sessions and usage records, protect the service against abuse and test versions of the front page because we have a legitimate interest in running a secure, working service and in improving it.
Who we share data with
We do not sell data. We share it only with the services we need to run Release Butler:
- Anthropic, which writes release drafts from the changes you pick and reads parts of your repository to find the screen a change is on.
- Typesafe, whose model judges whether a change can be seen on screen and picks what the screenshot browser clicks.
- OpenAI, whose text model writes what the screenshot browser types into a field when a step needs it.
- Resend, which delivers our emails, such as invitations, email verification and password resets, and our customers' release emails.
- Paddle, our reseller and merchant of record, which handles payments, invoices and sales tax.
- Cloudflare, which stores your screenshots and logos and our database backups, through Laravel Forge's object storage.
- Laravel Forge, which provides and manages our servers. They run on DigitalOcean infrastructure in Frankfurt, Germany.
- GitHub, where we read your repositories through the app you installed.
Our servers and database are in Frankfurt, Germany. Some of the providers above are in the United States. Transfers to them rely on the EU-US Data Privacy Framework where the provider is certified under it, and otherwise on the EU's standard contractual clauses.
How long we keep data
We keep your account and organization data for as long as you have an account.
When you delete your account, we delete it along with your passkeys.
When the owner deletes the organization, we first cancel any paid subscription with Paddle. Then we delete the organization together with the owner's account, the GitHub connection, repositories, changes, releases, readers, email lists, the record of sent emails, the do-not-email list, usage records and our billing records.
Front page test records for visitors who never signed up are deleted after 180 days without activity. If you sign up, your record moves to your account.
Our nightly database backups are kept for at most about 80 days, so deleted data is gone from them within that time.
For each time a reader opens the widget, we keep a short working record so the same report is not counted twice. It is deleted after 30 days. The per-release summary of how a reader read it is kept until you delete the organization, except for a reader ID the widget never recorded opening a release: its engagement is deleted after 30 days without activity, because an ID nobody's page ever named is most likely made up.
Your rights
You can see and correct your name, email address and language in your profile settings at any time.
You can delete your account in your profile settings. An owner with other members must hand the organization over first, and the last member deletes the organization instead.
Under the GDPR you also have the right to get a copy of your data, to have it corrected or deleted, to restrict or object to how we use it, and to take it with you to another service. Write to privacy@releasebutler.com and we answer within a month.
If you use a product that shows our widget, or you get its release emails, the company behind that product decides what it sends us. Ask them about your data first. You can always unsubscribe from a release email with the link in it.
If you think we handle your data wrongly, you can complain to Datatilsynet, the Danish Data Protection Agency, at datatilsynet.dk, or to the data protection authority where you live.
Changes to this policy
When we change this policy, we update this page and the date at the top.