Security

Security in Vorx is a set of defaults, not a checklist you run at the end. Here's how it's built in.

Isolated builds

Every project builds and previews in its own sandbox, so one app can't reach another's files, data, or secrets.

Safe by default

Generated apps get authentication, input validation, and per-user data scoping from the start — the easy path is also the secure one.

Row-level rules are enforced in the database itself, so "this user shouldn't see that record" holds even if a screen asks for it. You can review those rules alongside your tables under Settings → Cloud → Database.

Secrets stay server-side

Credentials live under Settings → Cloud → Secrets and are only readable by server-side code, so keys never reach the browser or get baked into your app's bundle. See Secrets.

Scanned before every publish

Before anything goes live, Vorx runs a full security scan — a secret pasted into client code, an endpoint returning records it shouldn't, common XSS patterns in source. A live credential blocks the publish outright; the rest warn so you can decide.

You can review the current state under Settings → Cloud → Security.

Destructive actions are bounded

Operations that remove data are deliberately narrow. Deleting a project moves it to Trash rather than destroying it, where it stays recoverable for 30 days (see Deleting and restoring); emptying a storage bucket tells you how many objects went; and the SQL editor — which does run exactly what you type — requires edit access and is never reachable from the AI.

Your data, your control

Connect a repository under Settings → GitHub and take a clean codebase whenever you want. Export tables to CSV from the database view. You're never locked in, and you always know where your data lives.

Enterprise governance

Larger organizations can add SSO, SCIM provisioning, and audit logs. Contact us to talk through requirements.

Next steps

• Authentication — who gets in
• Secrets — credential handling
• Roles and permissions — access to the project