Who we are
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.
What we collect
- 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.
- Server logs, our hosting provider (Railway) keeps short-lived application logs such as request paths, timings and error messages. These do not contain pupil code or comment bodies. We do not run any third-party analytics, cross-site tracking or advertising cookies.
- Support correspondence, anything you send us via the contact form or by email.
- Billing data, if you or your school buy a paid plan, we send an invoice through Stripe. The billing contact's name, email address, billing address and payment records are held by Stripe. You pay on Stripe's own invoice page, so we never see or store card or bank details. 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.
Lawful basis
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.
Who processes your data on our behalf
- 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. Supabase holds ISO/IEC 27001:2022 certification for its information security management system and a SOC 2 Type II report, both covering the database and authentication services we use.
- Railway Corporation, application hosting. Railway runs the RunPy web server that serves the site and handles sign-up, saving and safeguarding requests. Our Railway service runs in Railway's EU West region (Amsterdam, Netherlands), so requests are processed in the EU, which the UK recognises as providing adequate data protection. Nothing is stored there: the database stays in London. Railway is SOC 2 Type II certified and processes data under its Data Processing Agreement.
- IONOS, email delivery. When we send you an email (password resets, account notices, replies to support requests, occasional service updates to teachers), your name and email address are passed to our IONOS mail server to deliver it.
- Stripe Payments Europe, Limited, invoicing and payment processing for paid plans. Stripe is a regulated payment service provider (PCI DSS Level 1). We create and send invoices from our Stripe account; you pay on a Stripe-hosted invoice page, not on runpy.co.uk, and any card or bank details go directly to Stripe. 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 switch paid plans on or off. Access is logged and limited to the minimum data required.
Where your data is stored
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 is stored at rest only in the United Kingdom. The web server that handles your requests runs in the Netherlands (see below).
Specifically, the following lives in our UK Supabase project:
- Auth records (email, hashed password, role metadata) held in Supabase's
auth.userstable. - 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_eventsandteacher_edit_events. - Operational rows:
session_events(idle/end timestamps),login_events(sign-in date/role) andactivity_days(the dates you used RunPy, with your role). - Plan details (free or paid, and when a paid plan ends). Invoices and payment records are 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 Railway server and is used by a small number of server-side routes (signup, safeguarding logging, retention cleanup).
- Supabase's security programme is independently audited: it is certified to ISO/IEC 27001:2022 and holds a SOC 2 Type II report. Details are on Supabase's security page.
The application server. The RunPy web server is hosted by Railway in its EU West region (Amsterdam, Netherlands). When you sign in, save a file or use the site, your request (which can include your name, email, code or comments) travels over TLS to that server, which reads or writes the data in our London Supabase database and returns the response. The server does not keep its own copy of your data. Railway's application logs (request paths, timings, error messages) are short-lived and do not contain pupil code or comment bodies. Railway is SOC 2 Type II certified; see its Privacy Policy.
International transfers. Your data is stored in the UK and processed in the UK and the EU, both covered by UK adequacy regulations. The only routine flow outside the UK/EU is to Stripe for invoicing, which may transfer data under its own privacy policy and Standard Contractual Clauses. Support staff at Supabase or Railway may, exceptionally, access our infrastructure from outside the UK/EU under their data processing agreements; this is logged and limited to fixing infrastructure issues.
The safeguarding dashboard
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.
Cookies
We use a small number of strictly necessary cookies set by Supabase to keep you signed in. We do not use analytics, advertising or cross-site tracking cookies. If you pay an invoice, Stripe's invoice page sets its own cookies to process the payment securely; that page is on Stripe's site, not ours.
Retention
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.
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, activity_days) is retained for up to 13 months for usage charts, after which the rows are deleted.
Billing records (invoices, payment history) are retained in Stripe for as long as required by UK and Irish tax law (typically six years). Deleting your RunPy account does not delete these records, because we are legally required to keep them.
Your rights
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.
Children
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.
Changes
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.