Privacy Policy

RunPy ("we", "us") provides a browser-based Python and HTML IDE designed for UK secondary school classrooms. This policy explains what personal data we collect, why, and the rights you have under the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018.

If you have questions about this policy, contact us at support@runpy.co.uk.

• Account data, name, email address, role (student, teacher or school safeguarding lead), school name (for teachers and safeguarding leads), and a hashed password. Collected when an account is created.
• Classroom data, class names, join codes, membership of classes, files you save (Python and HTML source), folder names, and code snippets a teacher distributes to a class. Collected when teachers create classes and when students save work.
• Safeguarding logs (opt-in for schools) - when a school sets up a safeguarding account and a teacher joins it with a code, we record each comment that teacher leaves on a pupil's file (including edits and deletions, with their original bodies preserved) and each direct code edit they make to a pupil's file (the lines added and removed, plus one full snapshot per editing session). Nothing is logged for teachers who aren't in a school. See "The safeguarding dashboard" below for the full detail.
• Operational telemetry, short rows recording when a coding session began and ended (per file) and when an account last signed in. Used to power the admin dashboard (DAU charts) and to time out idle sessions. No keystroke or content tracking.
• Usage analytics, anonymised page views and performance metrics via Vercel Analytics. No cross-site tracking; no advertising cookies.
• Support correspondence, anything you send us via the contact form or by email.
• Subscription / billing data, if you upgrade to the paid teacher plan, Stripe stores your payment method (card details, billing address) on our behalf. We never see or store your full card number, expiry, or CVC. From Stripe we only receive a customer ID, subscription ID, status, interval, and the date the subscription renews or ends. See "Who processes your data on our behalf" below.

Python and HTML code you write in the browser is executed locally on your device by Skulpt; we never execute your code on our servers. Code only leaves your device when you explicitly save a file to your account or share a snippet.

We rely on legitimate interests (Article 6(1)(f) UK GDPR) to provide the service to teachers and adult users, and on performance of a contract for paid plans. For pupils under 13, schools obtain any required parental authorisation under their existing safeguarding arrangements; RunPy is provided as a tool for use under teacher direction.

• Supabase, authentication, Postgres database hosting and back-end services. Our Supabase project runs on AWS in the London region (eu-west-2), so all of your personal data - accounts, profiles, classes, files, comments, code, safeguarding logs and session events, is stored at rest in the United Kingdom. See "Where your data is stored" below for full detail.
• Vercel, application hosting and analytics. Vercel is GDPR-compliant.
• Stripe Payments Europe, Limited, payment processing for paid subscriptions. Stripe is a regulated payment service provider (PCI DSS Level 1). When you upgrade, you enter your card details directly into a Stripe-hosted form embedded on our page; Stripe collects, stores, and processes those details on our behalf. We only receive non-sensitive identifiers (customer ID, subscription ID, status, interval, renewal date). Stripe may transfer some data outside the UK/EU under their standard contractual clauses, see Stripe's Privacy Policy.
• RunPy admin dashboard, a small number of authorised RunPy staff can access an internal admin dashboard to support accounts, investigate issues, and manage subscriptions. Access is logged and limited to the minimum data required.

All personal data RunPy collects is held in a Postgres database managed by Supabase. The Supabase project we use runs on Amazon Web Services in the London region (eu-west-2). Your data does not leave the United Kingdom for routine operation.

Specifically, the following lives in our UK Supabase project:

• Auth records (email, hashed password, role metadata) held in Supabase's auth.users table.
• Profiles, classes, class memberships and join codes.
• Pupil files (Python and HTML source you save), folder metadata, teacher comments on files, and class-level code snippets.
• Safeguarding logs: schools, school_teachers, teacher_comment_events and teacher_edit_events.
• Operational rows: session_events (idle/end timestamps) and login_events (sign-in date/role).
• Billing identifiers from Stripe (customer id, subscription id, status). The card data itself is held by Stripe, not by Supabase.

Security controls applied by Supabase / AWS:

• Encryption at rest using AES-256 on the underlying RDS volumes, and encryption in transit using TLS 1.2+ for every connection.
• Daily automated backups retained for the period our Supabase plan provides, plus point-in-time recovery on the same eu-west-2 infrastructure.
• Network isolation via AWS VPC; the database has no public IP and is only reachable through Supabase's authenticated API.
• Row-Level Security (RLS) is enabled on every table that holds user data. Each user's session can only read or write rows the policy explicitly allows, students can only see their own files; teachers can only see files for students in their classes; safeguarding leads can only see logs for their own school.
• The Supabase service-role key (which bypasses RLS) is never sent to the browser. It is held only as an encrypted environment variable on our Vercel server and is used by a small number of server-side API routes (signup, safeguarding logging, retention cleanup).

The Vercel application layer that talks to Supabase is deployed across Vercel's European edge. Requests are routed to the nearest edge for speed, but the database itself never moves out of eu-west-2. Logs Vercel keeps for the application (request timings, error traces) are short-lived and do not contain pupil code or comment bodies.

International transfers. Routine processing happens entirely in the UK. The only routine cross-border data flow is to Stripe for billing, which operates under its own privacy policy and Standard Contractual Clauses where relevant. Supabase support staff may, exceptionally, access our project from outside the UK under their data processing agreement; this is logged by Supabase and limited to fixing infrastructure issues.

Schools can opt in to a free safeguarding programme. A designated lead signs up at /safeguarding and receives a join code. Teachers paste that code on their account page to join the school. From that moment on, two activity tables are populated for that teacher, and only for that teacher:

• Comment events, when a teacher creates, edits or deletes a comment on a pupil's file, a row is written with the comment body (or the previous body on deletion), the file id, the pupil id, the teacher id and a timestamp.
• Edit events, when a teacher saves a direct edit to a pupil's code, a row is written with the lines added, the lines removed and a character count. The very first save of an editing session also stores the full pre-edit file as a snapshot, so a safeguarding lead can see the original work and the change side by side.

Who can see the logs. Only the designated safeguarding lead for that school can read the entries. The lead account is created separately from the normal teacher/student sign-in, cannot access pupil dashboards, and cannot see logs from other schools. Teachers can see that they are in a school but cannot see anyone else's logs. Pupils never see the logs.

Transparency. While a teacher is in a school, their account page displays a persistent notice that comments and code edits are being recorded. The affected pupil sees a clear notice on sign-in (once per browser session) explaining that their school is reviewing activity in their account.

Default off. If a teacher has not joined a school, nothing is logged. The free/individual tier is entirely unaffected.

Lawful basis. Where a school operates the dashboard, processing is undertaken for safeguarding purposes, a public interest task under Article 6(1)(e) and a legal obligation on schools under Article 6(1)(c) UK GDPR. RunPy acts as a data processor; the school is the data controller for these records and is responsible for telling pupils and parents that monitoring is in place.

Retention. When a teacher leaves a school or is removed by the lead, their record is moved to an Archived section. The logs remain reviewable by the lead for 30 days; after that, a daily job permanently deletes the membership row and all associated comment and edit events. If the school's own safeguarding lead deletes their account, the school record and all related logs are also deleted.

We use a small number of strictly necessary cookies set by Supabase for authentication and by Vercel for performance measurement. We do not use advertising or cross-site tracking cookies.

Account and classroom data is kept while your account is active. If you delete your account from the account page, your profile, files, classes, and class memberships are removed within 30 days. Anonymised analytics are retained for up to 13 months.

Safeguarding logs are kept while a teacher is part of a school. When the teacher leaves the school, or is removed by the safeguarding lead, the membership row is archived and their comment and edit events remain visible to the lead for 30 days. A daily background job then permanently deletes the membership row and all associated event rows. If the safeguarding lead deletes their own account, the school and every log belonging to it is deleted in the same cascade.

Operational telemetry (session_events, login_events) is retained for up to 13 months for usage charts, after which the rows are deleted.

Billing records (invoices, payment history) are retained by Stripe for as long as required by UK and Irish tax law (typically six years). When you delete your RunPy account, we cancel any active subscription with Stripe and stop referencing your Stripe customer record from our database, but Stripe's own retention rules apply to the payment records themselves.

Under UK GDPR you have the right to access, correct, delete, restrict, or port your data, and to object to processing. To exercise any of these rights, get in touch and we will respond within one month.

If you are unhappy with how we have handled your data, you have the right to complain to the Information Commissioner's Office (ICO): ico.org.uk/make-a-complaint.

RunPy is designed for use in UK secondary schools (typically ages 11–18) under teacher supervision. We do not knowingly collect personal data from anyone under 13 outside of a school context.

We will update this page when our practices change and update the "Last updated" date above. For significant changes, we will let teacher account holders know by email.