1. Architecture
The compiler and runtime are compiled to WebAssembly and execute inside your browser tab. Programs run in a Web Worker with no network or file-system access, an instruction budget, and a timeout. No pseudocode is ever sent to a server to run.
The only server-side components are:
- Static pages and the editor bundle, served by Vercel.
- A workspace sync API that forwards requests to Convex after verifying your session.
- Convex database functions that store and return one workspace per user.
All of these run on servers in the United States.
2. Authentication and access control
Sign-in is delegated to Clerk. Sessions are short-lived JSON Web Tokens. The sync API accepts a request only if Clerk verifies the session, and it forwards your token to Convex, where every query and mutation checks the identity again before reading or writing.
Workspaces are indexed by the verified user ID from the token, never by a value the client supplies. There is no admin bypass, shared secret, or service role in the request path.
3. Data protection
- All traffic uses HTTPS. HSTS, a Content Security Policy, and standard hardening headers are set on every response. The policy limits scripts, connections, and frames to our own origin and the providers we use, but it still allows inline scripts.
- Workspace payloads are validated twice, in the API route and in Convex, with hard limits on size, depth, node count, and shape.
- The editor loads Monaco and its workers from our own origin, not a third-party CDN.
- Secrets live only in environment variables on Vercel and Convex. The repository contains no credentials, and environment files are excluded from version control.
- Dependencies are pinned in a lockfile and reviewed against known advisories before releases.
- When your account is deleted, Clerk sends a signed webhook and Convex deletes your workspace and user record.
4. If something goes wrong
If we learn of a breach that affects your personal data, we will notify affected account holders by email without undue delay and inform the supervisory authorities where the law requires it, including within the 72-hour window set by the GDPR and UK GDPR and the notification duties under China's PIPL.
5. Reporting a vulnerability
If you believe you have found a security issue, please email security@pseudo.build or use GitHub private vulnerability reporting. Do not open a public issue for security problems. A machine-readable version of this policy is at /.well-known/security.txt.
Include the steps to reproduce, the impact you believe it has, and any proof of concept. You will get an acknowledgement within 7 days and a status update within 30 days.
6. Safe harbor for researchers
We support good-faith security research. If you follow these rules we will not pursue legal action and will work with you to fix the issue:
- Test only against accounts you own or have permission to use.
- Do not access, modify, or delete other users' data.
- Do not run denial-of-service, spam, or social-engineering attacks.
- Give us reasonable time to fix the issue before disclosing it publicly.
7. Running your own copy
Because the code is open source you can run Pseudo Build yourself. The README in the repository explains which environment variables are required and how to configure Clerk and Convex for a private deployment. Self-hosted instances are outside the scope of this policy.