Privacy Policy

• Your account. When you sign in — magic link, GitHub, Google, or GitLab — Supabase Auth stores an account record: your email address, plus whatever display name and avatar URL the provider returns. That is the entire account.
• Subscription status. To decide whether you're entitled, the engine asks Polar for the customer matching your email and reads that customer's subscription status and product. For a Team subscription it also reads the seat list, to see whether your address holds a seat. The answer is cached in memory for about five minutes and is never written down.
• An MCP revocation counter. If you mint a token for an external AI client, a single integer — the current revocation epoch for your account — is stored on your Supabase user record. Raising it is what invalidates old tokens. That integer is the only thing we store about MCP access; the tokens themselves are signed rather than saved, so there is no token list anywhere.
• Server logs. Our hosts keep ordinary request logs — IP address, timestamp, path, status — under their own retention schedules. The engine also keeps per-IP and per-token request counters in memory for rate limiting; they're swept as they go stale and never persisted.

• Your content. The engine is stateless. Every request carries the files it needs, they're processed in memory, and they're discarded. There is no database, no object store, and no write to disk anywhere in the request path. We could not produce a copy of your documents, because we don't have one.
• Your git tokens. GitHub and GitLab access tokens live in your browser. When you open or commit to a repository, the token is forwarded with that single request to our SCM broker, which uses it and retains nothing.
• Your prompts. The MCP server receives whatever text your AI client sends it to lint or validate, handles it in memory like any other request, and drops it. We don't log prompts, and we never send anything to an AI provider — your client talks to us.
• Your payment details. Polar is the merchant of record. Card numbers and billing addresses are collected and held by Polar; we never see them.
• Anything analytical. No product analytics, no session recording, no tracking pixels, no advertising, and no third-party scripts of any kind. This isn't a setting you have to find — there's nothing there to switch off.
• Crash reports from your browser. We don't currently run a third-party crash reporter. When something fails in the editor it goes to an in-app console you can read yourself — capped, in memory, and gone when you reload. Our own servers do log their own failures; that's sections 1 and 3.

We don't sell your data, and we don't train models on your content.

Worth being precise about, because it's the one place an identifier touches a log file. When a subscription lookup or an MCP check fails, the engine records the failure so it can be diagnosed — but it writes a truncated SHA-256 of the identifier, not the identifier itself. Two failures from the same account are recognisably the same account; the log on its own doesn't say which.

That's pseudonymisation, not anonymity: anyone holding both the log and a guess at your address could confirm the match. What it rules out is your address sitting in plain text in a log aggregator.

None of this leaves your device except where section 1 says otherwise.

The credentials are named exactly so you can go and check them — open your browser's developer tools, look at local storage for this site, and you'll find those four and nothing else that matters. Clearing site data removes all of it.

The single cookie, sidebar_state, is host-only and purely functional: it does not track you, and there are no advertising cookies. Your sign-in session lives in local storage rather than a cookie.

That's the whole list. We don't share your repository content with any of them.

The account record persists until you delete it. Entitlement answers live in memory for about five minutes. Rate-limit counters live in memory for minutes and are swept. Content is never retained at all. Host request logs follow each host's own schedule, which we don't control.

Every connection uses TLS. The application ships a strict Content-Security-Policy with no inline-script escape hatch and a named list of hosts it may talk to, specifically so that an injected script can neither run nor ship your stored git tokens somewhere. MCP tokens are signed and verified rather than stored, so there is no credential table to steal. Your git tokens never leave your browser except on the request that uses them.

Those are commercially reasonable precautions, not a guarantee. No method of transmission over the internet is completely secure, and you're responsible for the security of the account you sign in with.

Email hello@vale.sh to access, correct, export, or delete your account. There's no automated deletion form because there's so little to delete; the manual path is faster than a form would be at this scale.

Your content needs no export mechanism from us — it already lives in your repository, and git clone is the export button. Deleting your account removes the Supabase record; billing records held by Polar are governed by Polar's own policy and their legal retention obligations.

Vale CMS is not directed at anyone under 16, and we don't knowingly collect their data. If you believe a child has created an account, tell us and we'll delete it.

We'll post revisions here and move the date at the top. Material changes are announced in-product. Questions: hello@vale.sh.