Privacy policy
Last updated 14 November 2026
This policy explains what Kerata collects when you use it, why, and what you can do about it. In this policy “Kerata”, “we” and “us” mean the team that runs this service. Questions: the contact page.
The short version
- Code you check without an account is analyzed in memory to produce your result and then discarded. It isn't stored.
- If you're signed in, your checks are saved to your private history so you can reopen them. Only your account can read them, and you can delete them at any time.
- We don't sell your data, we don't use it for advertising, and we don't train models on code you submit.
- Kerata's results are probabilistic estimates, not proof of who wrote a piece of code.
What we collect and why
- Code you check without an account. Used only to compute the result shown to you. It is not written to our database or logs. A per-network counter (your IP address) is kept in memory for one day to apply the anonymous daily limit.
- Account details. Your email address, an optional name, and your password or sign-in links, handled by our authentication provider, Supabase. Passwords are stored by Supabase as salted hashes; we never see them.
- Your history. When you're signed in, each check is saved with its result and the code you submitted, so you can reopen, rename, share, export or delete it. History is stored in a Supabase Postgres database protected by row-level security: each request runs with your own sign-in token, so the database refuses access to anyone else's rows.
- Workspace data. If you use class checks, courses, integrity cases or exams, the submissions you upload and the results are stored in our application database and are visible to the members of your workspace according to their roles.
- Share links. If you create a share link, a read-only copy of that report (including its code) can be viewed by anyone with the link until you turn the link off or delete the check.
- API keys. Stored only as hashes, with usage counters for the plan limits.
- Messages you send us through the contact form (name, email, topic, message), so we can reply.
- Technical data. Server logs (IP address, browser user agent, time, page or API path, errors) used to keep the service secure and working. We don't use third-party analytics, advertising or tracking scripts.
- Cookies and browser storage. Only what the service needs: a sign-in session cookie, a security (CSRF) cookie, your sign-in session and your light/dark theme choice in your browser's local storage.
GitHub repositories
When you ask Kerata to check a public GitHub repository, pull request or commit, our server downloads it from GitHub to analyze it. Without an account, nothing from it is stored; when signed in, the result is saved to your history as described above.
Who processes data for us
- Amazon Web Services hosts the Kerata servers and the application database (United States).
- Supabase provides sign-in (including sign-in emails) and stores signed-in history (United States).
We don't share your data with anyone else unless the law requires it. During the public beta there are no payments, so no payment provider receives your data.
How long we keep it
- History and workspace data: until you delete them or your account.
- Deleted checks are removed from the live database immediately. Our providers' backups may keep a copy for a limited time before it is overwritten.
- Server logs: only as long as needed for security and troubleshooting.
- Contact messages: as long as needed to handle your request.
Your choices
- Export your history any time (History → Export all).
- Delete single checks from History, or your whole account under Settings → Delete account. That removes your account, history, API keys and personal workspace.
- Ask us to access, correct or delete anything else we hold about you through the contact page. Depending on where you live (for example in the EU, UK or California) you may have further rights; we'll honour them.
Schools and organizations
If an institution uses Kerata's workspace features, it decides which student or employee work is uploaded, and people whose work is checked should contact that institution first. Institutions that need a data processing agreement or other terms can contact us; we don't offer a standard one yet.
Children
Kerata isn't meant for children under 13 to use on their own. Instructors who upload students' work are responsible for having the right to do so under their institution's rules.
Security
Traffic is encrypted (HTTPS), history is isolated with row-level security, saved results are signed by the server so they can't be altered, and API keys are stored as hashes. See the security page.
Changes
When this policy changes we'll update it here and change the date above. If a change is significant, we'll also email account holders before it takes effect.