The short version
- The collector sets no cookies and sends measurements, not people. Query strings, IDs, emails and tokens never leave the browser.
- Keys are stored only as SHA-256 hashes and shown once. Public keys only work from your site’s own address.
- Every project is walled off in the database, and deleting one deletes everything in it.
- We run on Vercel and Supabase, and we say plainly what we don’t have yet.
What we hold
The less we collect, the less there is to protect. The collector sends page templates, device class and speed readings, never names, emails, IP addresses or full URLs. The full list is in our privacy policy.
| Data | Where it lives | How it’s protected |
|---|---|---|
| Speed measurements | Supabase (Postgres) | Row-level security per project. No personal data in them. |
| Your account | Supabase Auth | Passwords are hashed by Supabase. Google sign-in uses Google’s own login. |
| Keys | Supabase (Postgres) | SHA-256 hashes only. The full key is shown to you once. |
| Releases and commits | Supabase (Postgres) | Row-level security per project. |
| Profile photo | Supabase Storage | Only the photo you upload, 2 MB at most. |
Encryption
- In transit: every page, API call and measurement goes over HTTPS. Browsers are told to always use HTTPS (HSTS).
- At rest: the database and file storage are encrypted on disk by Supabase. Confirm with Supabase plan
- Backups: daily database backups by Supabase. Backup window
Keys and access
Each project has two credentials, kept apart on purpose:
- Public key, in your script tag. It can only add measurements, and only from the site address you registered. Rotate it any time; the old one keeps working for 24 hours so nothing breaks mid-deploy.
- Deployment secret, in your CI. It can only register releases. Keep it in your CI’s secret store, never in the browser. You can replace it from the project’s Setup page.
Neither key can read your reports. Only signed-in members of a project see its data.
Application security
- Isolation: row-level security in the database keeps every project separate, even if a bug slipped into our code.
- Rate limits: collection is limited per project, per minute and per month, and the contact form per address.
- Browser protections: our pages can’t be framed by other sites, and send strict content-type and referrer headers.
- Pause anytime: pausing a project in its settings makes us refuse its measurements straight away.
Hosting and providers
We don’t run our own servers. The site and APIs run on Vercel, and the database, sign-in and file storage run on Supabase. Both are listed, with their regions, on our data processing page, and we’ll announce any new provider there first.
| Provider | What it does | Region |
|---|---|---|
| Vercel | Website, dashboard and APIs | Region |
| Supabase | Database, sign-in and file storage | Region |
Deleting your data
- Delete a project from its settings, and every measurement, release and key in it goes with it.
- Delete your account from the Account page, and your projects go too.
- Copies in backups expire within backup window.
What we don’t have yet
We’d rather be clear than sound bigger than we are:
- No SOC 2 or ISO 27001 report. CodeGecko is a small, young product.
- No single sign-on (SSO) or two-step sign-in codes yet. Google sign-in is available.
- No outside penetration test yet. We review our own code regularly.
Reporting a problem
Found a security issue? Tell us through the contact form, or write to security email. Please give us a chance to fix it before sharing it publicly. We’ll reply, keep you updated, and credit you if you’d like.
