Security

1. Certification status

We do not currently hold a SOC 2 report or an ISO/IEC 27001 certification. Nothing on this page means it has been verified by an outside auditor.

If you need a security questionnaire answered or a contract reviewed, write to [email protected].

2. Infrastructure and where data lives

• The service runs in Google Cloud's Seoul region (asia-northeast3), and the data you upload and its backups are stored in Korea. The exceptions (payment, the AI agent) are in section 6 of the privacy policy.
• Today it runs on a single server. There is no server redundancy or automatic failover yet, so if that server stops, the service stops until it is recovered.
• Current status is at /status.

3. Isolation between projects

• Every project has its own database roles and its own database login. The API opens a project's connections with that project's login, so one project's SQL cannot switch to another project's role.
• A token is valid for one project only. A token correctly signed with another project's key is refused.
• Every platform table a customer's role can reach has row level security (RLS) on it.
• This isolation is checked again by automated tests whenever the code changes.

4. Encryption

• In transit — The console is served only over HTTPS: it redirects HTTP requests to HTTPS and sends HSTS. Deployed sites and project APIs are served over HTTPS but do not redirect HTTP requests automatically. Direct database connections require TLS.
• At rest — Server disks and the backup bucket are encrypted with Google Cloud's default encryption at rest. Customer-managed keys (CMEK) are not supported yet.
• Secrets — Values such as OAuth client secrets, two-factor secrets and uploaded certificates' private keys are sealed with AES-256-GCM under a key derived per project before they are stored. A database dump alone cannot open them.
• Passwords and tokens — Passwords are hashed one way with scrypt; API tokens and invitation links are stored only as hashes.

5. Account security

• The console supports two-factor authentication with an authenticator app (TOTP), and an organisation can require it of every member. Recovery codes are stored only as hashes, and a code already used is not accepted again.
• At sign-up and on a password change, the password is checked against known breaches. Only the first five characters of its hash are sent; the rest is compared on our server.
• Repeated failed sign-ins to the same account are blocked for a while.
• Permissions within an organisation are split into five roles: owner, admin, developer, billing and viewer.

6. Records

• Significant changes in an organisation are written to an audit log. A database trigger refuses to change or delete it, and the platform's own service role is no exception. It is kept for three years, then destroyed.
• Each time personal data is reached through the console (the user list, tables, SQL, a backup download), an access record is written. It is kept for two years, and the organisation can read and download it.

7. Operator access and change management

• Operators reach the server through a Google Cloud IAP tunnel with Google account authentication (OS Login).
• Code is deployed by GitHub Actions, and only from commits that passed the automated tests. It authenticates to Google Cloud with no stored key, through workload identity federation allowed for this repository only.
• The server's settings and secrets live only in a file on the server with restricted access, never on a command line or in the repository.
• The database image is pinned to a specific version, and security patches follow a set procedure.

8. Backup and recovery

• Every night the database and files are backed up to a separate backup bucket (Seoul). The database's write-ahead log (WAL) is copied to the bucket every five minutes, a base backup is taken weekly, and a snapshot of the server's disks is taken daily, with seven kept.
• The backup bucket keeps backups that were deleted or overwritten for a period (object versioning, soft delete).
• Every week the newest backup is actually restored into an isolated temporary server by an automatic rehearsal, and the operators are alerted if it fails.
• Projects on a paid plan can be restored to a moment within the last seven days.
• Rebuilding the whole server from backups alone has not yet been timed, so we do not promise a recovery time objective (RTO).

9. Monitoring and incident response

• The database, backups, the restore rehearsal, disk, certificates, error rates and similar checks run every minute, and a confirmed problem is sent to the operators by email and webhook.
• A service outside the server receives a signal from it every minute and raises the alarm when the signal stops, so that even a server that has stopped entirely is noticed.
• If we learn of a personal data breach, we notify the people affected and report it as the Personal Information Protection Act requires.

10. Entrustment and overseas transfer

Every company entrusted with processing personal data, and every overseas transfer, is listed in sections 5 and 6 of the privacy policy.

11. Reporting a vulnerability

If you have found a security vulnerability, please tell us at [email protected]. We will reply as soon as we have looked. A machine-readable contact is at /.well-known/security.txt.