# Helm — Privacy Policy *Last updated: September 2026* | [View online](https://helm.dev/legal/privacy) | [Open-source notices](https://helm.dev/legal/notices) ## 1. Introduction This Privacy Policy describes how Helm Dev, Inc. ("we", "us"), a California corporation, collects, uses, and protects information when you use our desktop application, Helm ("the Software"). Helm is a local desktop application: almost everything it does happens on your machine, and the sections below are mostly about the few exceptions. Helm is beta software and is under active development. This policy will change as the product does. ## 2. Helm Is an Orchestrator — Where Your Prompts and Code Actually Go This is the most important thing to understand about privacy and Helm. Helm does not supply an AI model. **You choose the provider** — for example Anthropic, OpenAI, Google, or a model running locally on your own machine — and **you connect your own API key, subscription, or local installation.** When Helm sends a prompt, your code, or your project context to a model, it goes **from your machine to the provider you selected**, under the agreement between you and that provider. That means: - **We are not in the path** and we do not receive, store, or process that content. - **The provider's privacy policy and terms govern it**, including whatever they say about retention, human review, and training on your data. Read them for the provider you chose. - If you run a local model, that content does not leave your machine at all. **Two different mechanisms, one destination.** For most work, Helm runs the provider's own command-line tool on your machine and that tool talks to the provider directly — Helm is not part of the conversation. For some features — multi-model code review, and image generation — **Helm makes the request itself**, from your machine, using the API key you supplied. In both cases the content goes **straight from your computer to the provider you chose**, and in neither case does it pass through our servers or reach us. The difference is which program on your machine opens the connection, not where your data ends up. There is one exception, described next. ## 3. The Limited Trial Lane (the one case where prompts route through us) So you can evaluate Helm before connecting a provider of your own, Helm may offer a small, capped amount of trial capacity. When — and only when — that lane is used: - **Your prompt is sent to infrastructure we operate** (`trial.helm.dev`), which forwards it to an AI provider using our key and returns the response. - **The prompt content passes through our infrastructure.** We do not retain it as part of the product's normal operation, but it is not a direct connection between you and the provider, and the statement in Section 2 does not apply to it. - **A salted hash of a machine identifier** (see Section 4.3) is sent with the request so that per-machine usage caps can be enforced. The raw identifier is not sent. Our edge service stores only spending counters against that hash — it does not store your prompts. - **When this lane stops.** It covers only the pre-provider setup stages, up to and including development-plan generation; it never carries code execution. It becomes permanently unavailable on your machine the moment you connect a usable **cloud** AI provider. **Connecting only a local model does not end it** — a local model runs your work while this lane may still serve those setup stages. - **One exception after that:** a single cross-provider verification demonstration, capped at one per machine, may run through our infrastructure even once you have connected your own provider. If you would prefer that no prompt ever passes through our infrastructure, connect your own **cloud** provider key before using Helm's AI features. ## 4. What Helm Collects ### 4.1 Crash Reports (via Sentry) When Helm encounters an error, we may collect the following. This only happens if you have left crash reporting on; see Section 9. - Stack traces and error messages - Operating system type and version - Helm version number - Basic device information (architecture, memory) Crash reports help us identify and fix bugs. They do **NOT** contain your project code, file contents, or personal documents. An error message can name a file or a path when the error originates in your project's files — so treat "no file contents" as exactly that, and not as a promise that no file *name* ever appears. When you approve a diagnostic report (Section 4.4), what is recorded **here** is a note that a report of that kind was submitted — labelled with its error type from a fixed set (for example `rust_panic`) — alongside the crash-report fields listed above. The report's own message text is not sent to Sentry; the report itself goes only to us, as described in Section 4.4. ### 4.2 Usage Analytics (via PostHog) When you have usage analytics switched on (see Section 9), Helm collects anonymized usage analytics to help us understand how the product is used and where to focus improvements. Specifically, we collect: - Feature usage events (which features are used, not what content is created) - Mode selection (AutoPilot, Navigator, Architect) - Project completion rates and timing (e.g., how long phases take, not what the phases contain) - Error types and frequency (not error messages that might contain project data) A single anonymous identifier (randomly generated, not linked to your identity) is used for analytics. This ID is stored locally on your device. This data helps us improve Helm. It **NEVER** includes: - PRD content or project descriptions - Project source code or file contents - File names, directory structures, or project names - Personal information beyond what is in crash reports ### 4.3 Licensing and Machine Identification Helm derives a **machine fingerprint** from your hardware. It is used to bind a license to a device and to enforce per-machine trial caps. It is not used for tracking. **Activating a paid license, and re-checking it, contacts our licensing provider.** When you activate a license, when Helm re-checks it at startup (it re-checks when the last successful check is more than a day old), and when you ask it to check now, Helm sends **your license key and your machine fingerprint** to the licensing provider that issues and validates Helm licenses on our behalf. Deactivating a device sends the identifier of that device's activation so the seat can be released, and **authenticates that request with your license key** so the provider can confirm the seat is yours to release. On each of those paths Helm sends no project contents, no file names, and no prompts. Between those checks your license is verified **on your machine**, against a signed certificate stored locally, so Helm keeps working while you are offline. Our licensing provider holds your license key, the devices activated against it, and when those checks happened, so that the per-device limit and refunds can be enforced. It handles that data for us, under our instructions, and not for its own purposes. The trial lane (Section 3) sends a **salted hash** of the fingerprint — never the raw value — so per-machine caps can be enforced without transmitting the hardware identifier itself. Depending on where you are, a device identifier of this kind may count as personal data under local law even though it is not tied to your name. ### 4.4 User-Approved Error Reports When an error occurs during AutoPilot execution, Helm may ask if you'd like to send a diagnostic report. These reports are only sent with your explicit approval. An approved report contains the error type, the error message, the code location the error was reported from, the Helm version, your operating system, what you were doing at the time, a short description of the app's state, and — if you write one — **the description you type into the report box**. Helm sends that description to us verbatim; it does not filter it. If you paste source code, a file path, a project name, or an email address into that box, that text reaches our servers. **Everything in Section 5 below is subject to this exception: it describes what Helm sends on its own, not what you choose to include in a report you approve.** The error message and the location are captured by Helm, not written by you, and either can contain a file path or other project detail when a crash originates in your project's files. When Helm asks for your approval it shows you **the complete report, in full** — every field it will transmit, with nothing truncated or summarised — so that what you consent to is what is actually sent. Your description is the only part added afterwards, and you type it yourself. Two paths send a report without showing it to you again first, and both exist only because you turned automatic sending on: - **As errors occur.** If you tick **"Always send reports without asking"**, later reports are sent as they happen. You are approving that class of report in advance, not any individual one. - **A catch-up batch when Helm starts.** Reports are saved locally even when they cannot be sent — because you were offline, because a send failed, because they were captured before you turned automatic sending on, or because you were shown one and closed Helm without answering. If automatic sending **and** usage analytics are both switched on, Helm sends up to **ten** of those saved reports a few seconds after it launches, oldest first, without showing them to you. Nothing new is collected: these are reports already sitting on your machine. **A report you declined is not sent.** If Helm shows you a report and you choose **"Save Locally Only"** — or dismiss the window without sending — Helm marks that refusal on the saved report itself. Once the mark is there, turning automatic sending on afterwards does not release it: neither path above will transmit a report marked declined, and Helm offers no way to un-decline one. The report itself stays on your machine and you can still read or export it. Recording that mark is the one step that can fail — for example if the file has already been moved or removed, or the disk refuses the change. **Helm does not fail silently here:** if it cannot record your refusal it tells you on screen at the time, and says what that means. Nothing is transmitted at that moment. The residual risk is only that a report whose refusal could not be recorded still looks unanswered to the catch-up batch described above, so it could be sent later if you switch automatic sending on. If you see that message and the report matters to you, delete the report and the question goes away. You can turn automatic sending off at any time, and reports are always saved locally whether or not they are sent. **This path is not covered by the Settings switch.** If you turn crash reporting and analytics off (Section 9) and then click "Send Report" on a diagnostic, **the report is still sent.** We treat your explicit click as the more specific instruction — the switch tells us what to collect on our own initiative, and this is not that. If you would rather send nothing at all, decline the report: a declined report is never transmitted by any path. ### 4.4a Scenario Failure Reports Separately from the crash reports above, when a Helm test scenario fails you may be offered a one-click **"Send error report"**. This is never automatic — nothing is sent unless you click it, and nothing is sent at all if error reporting is switched off in Settings. That bundle is a different payload from the crash report described above. It contains the failure message, a slice of Helm's own recent internal activity log, your operating system and architecture, the Helm version, and — when Helm is run from a source checkout — the Git revision of that checkout. The format also has room for buffered analytics and diagnostic breadcrumbs; Helm does not currently put any in, and those fields go out empty. The bundle is assembled from Helm's own diagnostics rather than from your project's files. Before the bundle is saved, the failure message and the activity-log entries — the parts that can carry text from your machine — are passed through the same secret-redaction used elsewhere in Helm: API keys, tokens, private keys and connection-string passwords are replaced, and your home directory is rewritten as `~`. **That is redaction, not anonymisation:** the rest of a path survives it, so your project's folder name or a file name can still appear. The bundle is not shown to you field by field before it is sent, so unlike the crash report above, you are approving the ACTION rather than a payload you have read. ### 4.5 Update Checks Helm can check whether a newer version is available. **Automatic update checking is switched off in the current build**, so no update request is made. When it is enabled in a future release, a check will contact our update service, and — like any web request — will necessarily reveal your IP address and the version you are running. It sends nothing else. **That is a statement about update checks, and only about update checks.** Helm does make other requests on its own initiative, including some on every launch, and Section 4.7 describes them. ### 4.6 Look-ups Helm Makes on Public Services Two features work by asking a public service a question. Neither sends your code, neither uses an account or key, and neither is telemetry — but both mean a detail about your project leaves your machine, so they belong here. **True of every look-up in this section, before anything else is said about it.** Each one is an ordinary web request from your computer to somebody else's service, so — exactly as with the update check in Section 4.5 — it necessarily reveals **your IP address**, and the fact that you made the request when you did, to whoever answers it. That is a consequence of asking at all rather than something Helm attaches, and no bullet below is an exception. Where a bullet says what a look-up "sends", it is describing the **project-specific** data in the request, on top of this. - **Dependency licence checks.** When Helm checks the licences of the packages your project depends on, it looks each one up on that ecosystem's public registry. The project-specific data differs by ecosystem, and in each case it is only what that look-up needs: - **npm** (`registry.npmjs.org`) and **crates.io** (`crates.io`) — the only project-specific request data is **the package name**. The request asks for the package's whole record, and which version you depend on is selected from the reply, on your own computer, after it arrives. crates.io additionally receives a fixed identifier for this checker, `Helm/1.0 (license-check)`, which names Helm and says nothing about you. - **PyPI** (`pypi.org`) — the only project-specific request data is **the package name, and the version** when Helm has a specific one to ask about; otherwise the package name alone. None of the three sends your code, your project name, or your file paths. Bear in mind that a list of dependencies says something about what a private project is built with — and that the registry can associate that list with the IP address it came from. - **Custom-domain checks.** If you connect a custom domain, Helm checks whether your DNS records have propagated by querying **public DNS-over-HTTPS resolvers** (Cloudflare first, then Google as a cross-check). The project-specific data it sends is **the domain name you entered and which kind of DNS record is being checked** (`A`, `AAAA`, `CNAME` or `TXT` — an `ALIAS`/`ANAME` record is checked by asking for `A`, because that is all the public internet can see of one). Both are facts about a domain that is, by design, about to be public anyway. Each request also carries `Helm` as its user agent, which names the program asking and says nothing about you. The value you expect the record to hold is **not** sent — the answer is compared on your own computer. These run as part of features you invoke, and they are **not** governed by the Settings switch in Section 9, which covers crash reporting and analytics. ### 4.7 Requests Helm Makes on Its Own Section 4.5 covers a check that is currently switched off, and Section 4.6 covers look-ups that happen because you invoked a feature. This section covers the rest — **requests Helm makes without being asked**, including several on every launch, and the handful it makes to other people's services for information. **True of every request in this section, before anything else is said about it.** Each one is an ordinary web request from your computer to somebody else's service — ours included — so, exactly as with the update check in Section 4.5, it necessarily reveals **your IP address**, and the fact that you made the request when you did, to whoever answers it. That is a consequence of asking at all rather than something Helm attaches. Where a description below says what a request "sends", it means the **project-specific or account-specific** data in the request, on top of this. Two of these requests carry such data, and each says so. #### What Helm fetches from our own servers Every time Helm starts, it fetches three small configuration files from `helm.dev` in the background — whether or not you do anything, and with no setting that turns them off: - a table of **context-window thresholds** for the AI models it knows about, so its context handling can be corrected between releases; - the current **status of its billing-split feature**; - a list of **AI CLI versions known to work with it**. It also fetches the current text of these legal documents from `helm.dev` **when the acceptance screen opens** — which is before you have accepted anything — so that what you are asked to accept is the current version rather than the copy that shipped inside the app. Each of the four is a plain request for a fixed public file. **The project-specific request data is none: no identifier, no licence key, no project detail, no account.** What we can learn from them is what any web server learns — that a machine at your IP address asked for a file at a particular time — which, on the launch fetches, tells us that somebody started Helm. #### What Helm fetches from other people's services Helm also reaches services that are not ours, on its own initiative, to read information rather than to hand anything over: - **A public source repository, currently GitHub.** So it can offer you an accurate list of a provider's current models, Helm fetches that provider's published model configuration from the public repository it lives in (today, one file in the Gemini CLI's GitHub repository). This runs during Helm's start-up model discovery when its cached list is more than six hours old, and again whenever models are refreshed. **The project-specific request data is none** — it is a fixed URL, no account and no credential are involved, and Helm is reading a public file exactly as a browser would. - **Your AI provider's status page.** While Helm is running it checks the status page published by the provider you have selected — Anthropic's, OpenAI's or Google's, depending — so it can tell you when a failure is that provider's outage rather than a problem on your machine. It checks about once every five minutes, more often while AutoPilot is working, and it starts when Helm starts, using the provider you saved as your default; switching provider inside the app moves the check with you. If separate projects use separate providers, the page checked is the one Helm is currently set to, which need not be the provider of whichever project you have open. **The project-specific request data is none**, and the page is public; what the request discloses beyond the IP address and timing above is implicit in who receives it — that a machine at your address is using that provider. (A locally-run model has no status page: while one is what Helm is set to use, it makes no such request at all.) - **Services used by a feature you ran.** Three requests belong to specific features rather than to Helm's own housekeeping, and two of them do send something: - **The model-quality index** (`artificialanalysis.ai`) is fetched only if you have entered an Artificial Analysis API key in Settings, and only when quality scores are refreshed. **That request sends the API key you entered**, because that is what the service requires. With no key entered, the request is never made. - **Branding extraction** fetches **the web page whose address you give it**, so it can read a logo and a name from it. **That address is what the request sends**, and it goes to whoever hosts that page. Helm identifies itself as `Helm/1.0 (design-extraction)`. - **Sample data for a smoke test** is downloaded when a test you have asked Helm to run needs a placeholder file: images come from `picsum.photos`, addressed only by the pixel dimensions wanted, and other file types are downloaded from a public address the AI provider's own web search returns. **The project-specific request data is none** in either case. - **Dependency-advisory services,** when you run an app-assurance check and only after you have said yes on the in-app consent screen. To tell you whether the packages your project depends on carry known vulnerabilities, Helm asks public advisory services about them. The first (currently deps.dev) receives the ecosystem, the name of each dependency you depend on directly, including private and scoped names, and the version your lockfile pins, and, in a second request, the identifiers of the advisories it returned. The others (currently OSV and FIRST.org) receive only advisory or CVE identifiers, never a package name or version, and are not contacted when there is nothing to look up. Requests are capped per check. Because a private dependency name can reveal confidential project or vendor information, Helm sends these names only after your consent, and you should decline the check for a project whose dependency names you cannot disclose. The consent screen names the current services and exactly what is sent; if we add or change a service, that screen and Section 8 change with it. None of the requests in this section is governed by the Settings switch in Section 9, which covers crash reporting and analytics. Unlike the look-ups in Section 4.6, most of these are not tied to anything you invoked — they are how the shipped app keeps itself current, and the honest summary is that running Helm means these requests happen. ## 5. What Helm Does Not Send to Us **Read this as a statement about CONTENT, not about contact.** Helm does contact our own servers on its own initiative — on every launch, and again when the acceptance screen opens, before you have accepted anything. Section 4.7 says which requests those are and what they retrieve; none of them carries anything from the list below, which is the point of keeping the two sections apart. To be unambiguous — Helm never sends the following to **our** servers on its own: - **Project source code** — not transmitted to us - **PRD content** — not transmitted to us - **File contents** — not transmitted to us - **Your name, email, or account details** — we do not collect them (beyond your license key, if you have one, and whatever crash-reporting tools automatically include from the OS) - **Keystrokes or screen content** — never monitored **The exception is a diagnostic report you choose to send us** — a crash report you approve (Section 4.4) or a scenario failure bundle you click to send (Section 4.4a). Those are the only paths by which any of the above can reach us, and each only happens because you chose to send it: the description you type is transmitted verbatim, and the captured error message can itself contain a file path or other project detail. This list describes what Helm sends *by itself* — it is not a promise about content you deliberately put into an approved report. **AI conversation content** goes to the AI provider **you** selected, not to us — with the single exception of the trial lane described in Section 3. Content sent to your chosen provider is governed by that provider's privacy policy. ## 6. Local Data Storage Helm stores data locally on your machine at `~/.vibe/`: - `data.db` — a database containing your projects, tasks, settings, and session history - Project-level data in `.vibe/` directories within your project folders Helm also reads and writes files inside the projects you open with it — that is its core function. This data never leaves your machine unless you explicitly use a feature that transmits it (for example an AI call to the provider you configured, or a deployment to a hosting provider you connected) — with one exception that runs on its own: if you have activated a license, Helm re-checks it with our licensing provider as described in Section 4.3, which sends your license key and machine fingerprint from this database. ## 7. Credentials You Give Helm To do its job, Helm may hold credentials you provide — AI provider API keys, and tokens for services you connect such as GitHub or a hosting or database provider. These are stored on your machine and are used to talk to those services on your behalf. **They are not transmitted to us.** Anyone with access to your machine and your operating-system keychain may be able to reach them. **One credential Helm reads but did not create.** To detect whether you already have a Claude subscription — so it can avoid asking you to set up something you have — Helm reads the login item that Claude Code stores in your operating-system keychain. Your system may show an authorisation prompt when it does. **This is a local read only: the credential is never transmitted to us or to anyone else**, and declining the prompt only means Helm asks you to connect a provider itself. ## 8. Third-Party Services Helm may interact with the following third parties: - **Sentry** (sentry.io) — crash reporting (see Section 4.1) - **PostHog** (posthog.com) — usage analytics (see Section 4.2) - **Our licensing provider** — issues and validates Helm licenses on our behalf. It receives your license key and your machine fingerprint when you activate a license, when Helm re-checks it, and when a device is released, and it holds that data for us under our instructions (see Section 4.3) - **Our own trial edge service** (`trial.helm.dev`, operated on Cloudflare) — the limited trial lane (see Section 3) - **Our own servers** (`helm.dev`) — the configuration files Helm fetches on every launch, and the current text of these legal documents when the acceptance screen opens. These carry no project or account data (see Section 4.7) - **The AI provider you select** — AI interactions are governed by that provider's privacy policy (see Section 2) - **Services you connect** — for example GitHub, or the hosting and database providers you use for deployment, each under their own terms - **A public source repository, currently GitHub, that you did NOT connect** — Helm fetches a provider's published model list from a public repository on its own initiative, so it can offer you current models. This is a different thing from the row above, where you connect an account, and it is described in Section 4.7 - **Your AI provider's status page** — Anthropic's, OpenAI's or Google's, depending on the provider Helm is set to use, checked while Helm is running so it can distinguish an outage from a local fault; none is checked while that provider is a locally-run model (see Section 4.7) - **Services a feature you ran reaches on your behalf** — **Artificial Analysis** (`artificialanalysis.ai`), which receives the API key you entered for it when quality scores are refreshed; **`picsum.photos`** and other public sources of sample files during a smoke test; and **the website whose address you give** to branding extraction (see Section 4.7) - **App Store Connect and Google Play**, when you ask Helm to submit an app for you. Helm uploads your build and its store metadata **to your own developer account**, using the credentials you provided. Your agreement with Apple or Google governs that submission, and it remains your submission — see our Terms of Service. - **Public dependency-advisory services** (currently deps.dev, OSV and FIRST.org), which receive dependency names and pinned versions (deps.dev) or advisory and CVE identifiers only (the others), solely when you run an app-assurance check after consenting in the app (see Section 4.7). - **Cloudflare and Resend, for the helm.dev waitlist.** Cloudflare stores the waitlist for us, and Resend sends the waitlist emails (see the helm.dev Website and Waitlist section). Sentry, PostHog and our licensing provider process data in the United States. A full list of the third-party open-source software distributed inside Helm, and the licence each is used under, is published at [helm.dev/legal/notices](https://helm.dev/legal/notices). That list is generated from the shipped build rather than maintained by hand; it is provided on a best-efforts basis and is not part of this policy. ## 9. Your Choice About Crash Reports and Usage Analytics **We ask before we collect.** The first time you launch Helm, it shows you what crash reporting and usage analytics do and lets you decide. Declining takes one click, changes nothing about how Helm works, and we do not ask again. **The starting position depends on which build you are running, and Helm tells you which:** - **General release.** Crash reporting and usage analytics are **off** until you turn them on. Nothing is sent before you say yes. - **Beta builds.** These start **on** so we can find and fix problems while Helm is still being built — which is what a beta is for. You are told this on the first launch, before anything is sent, and one click turns it off. If you are in the EEA or the United Kingdom, crash reporting and usage analytics stay off until you turn them on, whichever build you are running, so that your consent comes before anything is sent. Either way you can change your mind at any time in **Settings → Privacy**, and the change takes effect immediately — no restart. **What the switch does and does not cover:** - ✅ **Covers:** crash reports (Section 4.1) and usage analytics (Section 4.2) — one switch, both. - ❌ **Does not cover a report you choose to send us.** If you click "Send Report" on a diagnostic (Section 4.4) or a scenario failure (Section 4.4a), **that report is sent even if this switch is off.** Your explicit click is treated as the more specific instruction. The switch governs what Helm sends *on its own*, not what you deliberately hand us. See Section 4.4. - ❌ **Does not cover the trial lane** (Section 3) — it only runs if you use it — **or the look-ups in Section 4.6**, which are part of features you invoke rather than telemetry. - ❌ **Does not cover the requests in Section 4.7**, which Helm makes on its own initiative, including on every launch. They are how the app keeps itself current rather than telemetry, they carry no crash or usage data, and there is no setting that stops them. Turning these off does not degrade Helm in any way. ## 10. Data Retention - **Crash reports:** Retained by Sentry for 90 days, then automatically deleted - **Usage analytics:** Retained by PostHog for 12 months in anonymized form - **Trial-lane counters:** Spending totals keyed to a hashed machine identifier, retained by our edge service while the trial programme runs. Prompts are not stored there. - **License data:** Your license certificate is stored on your machine. Your license key, the devices activated against it, and the times it was checked are held by our licensing provider for as long as the license exists (see Section 4.3) - **Local data:** Stored indefinitely on your machine until you delete it or uninstall Helm - **Waitlist data:** kept until you ask to be removed or until the waitlist closes, and deleted within 12 months after the waitlist closes ## 11. Data Deletion To delete all Helm data from your machine: 1. Uninstall the Helm application 2. Delete the `~/.vibe/` directory 3. Delete any `.vibe/` directories within your project folders For deletion of crash-report or analytics data from our providers' servers, contact us at privacy@helm.dev. ## 12. Children's Privacy Helm is not intended for use by children under 13. We do not knowingly collect information from children under 13. Helm is intended for adults and is not directed to children. If you are in the EEA or the United Kingdom, do not use Helm or join the waitlist unless you are at least 16, or older where your country sets a higher age for consent to online services. ## 13. Documents Helm Generates for Your Applications Helm can generate privacy-policy, terms-of-service, and cookie-notice **templates** for the applications you build with it, including a section listing third-party services detected in your project's code. Those templates describe **your** application, not Helm, and they are informational only — not legal advice, and no warranty that they are legally sufficient. **You are responsible for the privacy policy your own applications publish.** See Section 10 of our Terms of Service, and the disclaimer in every generated file. ## 14. The helm.dev Website and Waitlist This policy is mostly about the Helm app. This section is about the helm.dev website. **Visiting.** helm.dev sets no cookies and runs no analytics. Like any website, our host (Cloudflare) sees your IP address when it serves a page. The site does not respond to Do Not Track browser signals, because it does not track you across websites in the first place. Some pages may load fonts or other assets from a third-party content network; when they do, that provider receives your IP address and browser details for that request, and nothing else about you. **Joining the waitlist.** If you give us your email address we keep it, together with when you joined and, if you arrived through a referral or a tracked link, which one. We do not store your name, IP address or browser details with your signup. If you use a referral link we assign you a referral code and count the people who join through it. When someone opens a referral or tracked link we record the link's code, the time, and the first 80 characters of the browser's user-agent string (the text a browser sends to identify its type), so we can count how often each link is opened and filter out bots. That click record identifies the link, not the person who opened it: it holds no email address, we do not match it to any signup, and we keep it until we purge it. For abuse prevention and security, we may also record the IP address and full browser details of requests to the waitlist and its links; when we do, we keep that record apart from your signup and use it only for those purposes. **What we send.** One welcome message with your place in line and your referral link; occasional updates about Helm; and, when it is your turn, the single message that invites you in. Our email delivery provider (currently Resend) processes your address and the message content to send them. Every update carries an unsubscribe link and our postal address. **Stopping the emails and leaving the list.** Every update carries an unsubscribe link, and unsubscribing stops the updates immediately; you will still receive the invitation when your spot opens. To be removed from the list entirely, reply to any of our emails or write to privacy@helm.dev and we will delete your record. We keep waitlist records until you ask us to remove them or until we close the list, and we delete the records of a closed list within 12 months. **Where it lives.** The waitlist is stored for us by Cloudflare. Nobody else receives it, and we do not sell or share it. ## 15. Your Privacy Rights in the EEA and the UK This section applies if you are in the European Economic Area (EEA) or the United Kingdom. For the processing described in this policy, Helm Dev, Inc. is the controller, and you can reach us at privacy@helm.dev or at the postal address in Section 17. **Lawful bases.** Helm provides the Software and any paid licence, runs licence checks, and operates the trial lane to perform its contract with you or to take steps at your request before a contract (Article 6(1)(b) of the GDPR). It fetches configuration and legal text on launch, keeps its model and status information current, checks dependency licences and custom domains, and protects the trial lane against abuse on the basis of its legitimate interests in operating and securing the Software (Article 6(1)(f)). It collects crash reports and usage analytics, sends error and scenario reports, and runs the dependency-advisory check only with your consent (Article 6(1)(a)). It sends waitlist emails on the basis of your consent. **Your rights.** Subject to the conditions in the law, you may ask us to give you access to your personal data, correct it, delete it, restrict or object to its processing, or provide it in a portable form. Where we rely on consent, you may withdraw it at any time, and withdrawing is as easy as giving it: use the switch in Settings, the unsubscribe link in an email, or write to privacy@helm.dev. Withdrawing consent does not affect processing already carried out. We do not make automated decisions that produce legal or similarly significant effects about you. **How to exercise your rights.** Write to privacy@helm.dev. We respond within one month, and we do not charge for a request unless the law allows it. Because much of what Helm holds sits on your own machine, we will also tell you when a request is one you can carry out yourself, and how. **Complaints.** If you believe we have handled your personal data unlawfully, you may lodge a complaint with your local supervisory authority; in the United Kingdom that is the Information Commissioner's Office. **International transfers.** Helm Dev, Inc. is in the United States, and the providers in Section 8 that process personal data for Helm (currently Sentry, PostHog, Cloudflare, Resend and our licensing provider) also process it in the United States. When personal data moves from the EEA or the United Kingdom to the United States, we rely on the EU-U.S. Data Privacy Framework and its UK extension for providers certified under it, and on the Standard Contractual Clauses with the UK Addendum for providers that are not. Ask us at privacy@helm.dev which mechanism covers a given provider. **Our representative.** Before we open the beta to users in the EEA or the United Kingdom, we will appoint a representative under Article 27 of the GDPR in the EEA and the United Kingdom, and we will name that representative here. ## 16. Changes to This Policy We may update this Privacy Policy from time to time. Changes will be reflected in the "Last updated" date. We will notify you of significant changes through the application. For a material change, we will post the updated policy with a new Last updated date and give notice inside the app, and, where we hold your email address, by email before the change takes effect. If you keep using Helm after that date, the updated policy applies. ## 17. Contact Helm Dev, Inc. is the data controller for the information described in this policy. For privacy-related questions or requests, contact us at privacy@helm.dev, or write to Helm Dev, Inc., 1401 21st Street, Suite 12332, Sacramento, CA 95811, USA.