Legal
Security
How FlyKo protects the data your school entrusts to it: where it is stored, how it is encrypted, who can reach it, and what happens if something goes wrong.
Last updated 28 September 2026
Our approach
FlyKo holds records that a flight school relies on to keep its aircraft serviceable and its training on track. We treat that data as sensitive and design the service around a few simple ideas: collect only what is needed, separate each school's data, give each person access only to their part, encrypt everything, and keep working backups.
This page describes the controls we run in production. During the private Beta some features are still being rolled out; where that is the case it is noted below.
Infrastructure and hosting
The application is hosted on Vercel and the database, user authentication and file storage run on Supabase (managed PostgreSQL). Both providers hold recognised security certifications such as SOC 2; current attestations are available from each provider.
We do not run our own physical servers. Access to the hosting and database consoles is limited to named administrators and protected by multi-factor authentication.
Encryption
- In transit: all traffic between your browser and FlyKo uses HTTPS with TLS 1.2 or higher. HTTP requests are redirected to HTTPS.
- At rest: the database, file storage and backups are encrypted at rest with AES-256 by the platform provider.
- Secrets: API keys and credentials are stored in a secrets manager, not in source code, and are rotated on a schedule and after any suspected exposure.
Access control and roles
FlyKo is built around five roles: administrator, instructor, student pilot, pilot and mechanic. The role is set when a person joins a school and decides what they can see and do.
- an administrator manages the school's members, join codes, programmes and documents;
- an instructor records lessons and keeps a file on their own students;
- a student pilot sees their own logbook and training record only;
- a pilot books aircraft and logs their own flights;
- a mechanic works with aircraft, documents and maintenance records only.
These limits are enforced on the server through row-level security policies in the database, not only in the interface, so a crafted request cannot reach data outside the caller's role or school.
Authentication
Accounts are protected by a password, which is stored only as a salted hash using a modern algorithm. Sessions use signed, time-limited tokens and can be ended by signing out.
Multi-factor authentication for user accounts and single sign-on for schools are on our roadmap.
Data isolation between schools
Every record carries the identifier of the school it belongs to. All queries are scoped to the caller's school at the database level, so one school cannot see or change another school's aircraft, people or training data.
Backups and recovery
- The database is backed up automatically by our database provider, Supabase.
- Backups are encrypted and stored separately from the primary database.
Secure development
- changes go through code review and automated checks before release;
- environments for development, testing and production are kept separate;
- dependencies are monitored for known vulnerabilities and updated promptly;
- access to production follows least privilege and is logged.
Monitoring and logging
We collect application and infrastructure logs, error reports and uptime metrics. Logs that may contain personal data are access-controlled and retained for up to 12 months. We review alerts for unusual activity such as repeated failed sign-ins.
Sub-processors
We use a small set of vendors to run the service: Vercel for hosting, Supabase for the database, authentication and file storage, and Google (Gmail) for email. A current list is in our Privacy Policy and available in full from flyko2026@gmail.com. We give notice before adding a new sub-processor that handles personal data.
Incident response and breach notification
We have an incident response process covering detection, containment, investigation and recovery. If we confirm a personal data breach that is likely to create a risk to affected people, we will notify the relevant supervisory authority within 72 hours where required, and inform affected schools and users without undue delay, with what we know and what we are doing about it.
No system is completely secure. To the fullest extent permitted by law, we are not liable for any loss, leakage or theft of data that occurs despite the controls described on this page. See the "Limitation of liability" section of our Terms of Service for how our liability is limited.
Reporting a vulnerability
If you believe you have found a security issue in FlyKo, please email flyko2026@gmail.com with enough detail to reproduce it. Please do not access data that is not yours, do not run denial-of-service tests, and give us a reasonable time to fix the issue before making it public. We will acknowledge your report, keep you updated, and credit you if you wish once the issue is resolved.
Your part
- use a strong, unique password and do not share your account;
- give each person their own account with the correct role rather than a shared login;
- remove access promptly when someone leaves the school;
- keep your own copies of safety and compliance records;
- report anything that looks wrong to flyko2026@gmail.com.
Questions about this document? Write to flyko2026@gmail.com. See also our Privacy Policy, Terms of Service and Security page.