Loading page
Ready to build
Build the app you keep thinking about.
Describe your idea. Sanic AI builds the real app, end to end.
Describe your idea. Sanic AI builds the real app, end to end.
Every control listed on this page is live in our production codebase today. No marketing asterisks, no claims we can't back up.
Minimum 10 characters, maximum 72. Must contain at least one letter and one number. Passwords matching a common-password blocklist are rejected. Email addresses cannot be used as passwords.
A user cannot access the builder, their projects, or their account settings until they've verified their email. Our edge proxy redirects unverified sessions back to confirmation.
Credentials never touch a client-side Supabase handler. Log-in runs through a rate-limited server route, so we own error handling, logging, and abuse mitigation.
Social log-in via GitHub, plus an optional GitHub connection used to push your exported codebase. The push connection requests GitHub's repo and user:email scopes, the access GitHub requires to create and push to repositories you choose, including private ones. We only ever write to repos you create from the export panel.
We fingerprint each log-in from passive request signals (IP, browser, OS, locale, and form factor) and email the account owner the first time we see a new combination. Suspicious log-ins are surfaced immediately, not buried in a log.
All state-changing API routes (POST, PATCH, DELETE) require a double-submit cookie with a 32-byte token, verified in constant time. The token rotates on log-in and log-out.
Log-in: 30 attempts per 15 minutes per IP, 5 per email. Account creation: 5 per 15 minutes per IP. Password reset: 5 per 15 minutes per IP and 3 per hour per email. Account deletion: 3 per user per day.
Our Postgres schema has Row Level Security enabled and FORCED on every user-facing table, so even the database owner cannot bypass policies. Every read and write is scoped to the authenticated user, in most cases through account-membership checks that resolve to auth.uid().
Third-party API keys and webhook secrets you connect (Supabase, Stripe, OpenAI, GitHub, and similar) are encrypted with AES-256-GCM before being written to the database. Plaintext secrets never land in a row. The short-lived OAuth state cookies used during a GitHub connect flow are HttpOnly, SameSite=Lax, and Secure in production.
Authentication events, credit-ledger movements, and account-deletion records are append-only. Credit-ledger and deletion-log rows are protected by triggers that raise an exception on UPDATE or DELETE, pinned ENABLE ALWAYS so even the service role is blocked; the authentication-event log is insert-only. Stripe webhook deliveries are recorded with controlled status fields used only for idempotent retry handling.
Account deletion is a two-step flow: request it (email and password accounts re-enter their password here), then confirm via a 72-hour single-use email token. Confirmation triggers a hard cascade delete across every table tied to your user.
Your generated code pushes to your GitHub organization. Your backend provisions in your Supabase project. Your Stripe account stays in your name. If you cancel tomorrow, the infrastructure keeps running without us.
All API inputs pass through a sanitizer that strips control characters, validates UUIDs, and bounds-checks strings before they reach business logic. Free-text fields are treated as hostile by default.
The only credential exposed to the browser is the Supabase anonymous key, which is designed to be public and is gated entirely by Row Level Security. Stripe secret keys, admin service tokens, encryption keys, cron secrets: all live exclusively on the server.
Our error reporter strips password, token, api_key, and secret fields from context before logs are written. Even an accidental stack trace can't leak a credential.
All cookies we issue are Secure in production. Session cookies are HTTP-only and SameSite=Lax. CSRF tokens use the JS-readable half of the double-submit pattern only.
Dependencies are pinned and reviewed. We run SSR on standard Next.js. The only place we use the Function() constructor is the /build live-preview subsystem, the compiler that executes your own code plus a one-line capability check it depends on, inside a sandboxed iframe under a tight per-iframe CSP (default-src 'none' with a fixed script-src allow-list). The marketing, auth, dashboard, and API surfaces all disallow 'unsafe-eval' in their CSP.
Appsanic's agent writes, edits, and deletes files inside your project. It does not run arbitrary shell commands; it runs only a fixed allow-list of read-only verification tools, like a type-check and a render-check, that catch errors before you see them, in a sandboxed temp directory under strict time and output caps. The app binary itself is built in Expo's managed pipeline, not an Appsanic execution environment.
Prompts and generated code are processed by our model provider under a commercial API agreement, which does not use inputs or outputs to train or fine-tune foundation models.
Every agent invocation is bound to a single project and account scope, and its tool calls are filtered to that scope on every query. The user-facing API is additionally protected by Row Level Security at the database layer.
Plan mode lets the agent surface its plan for your approval before it writes any code; turn it on and nothing changes until you say go. Nothing about the system requires you to trust it blindly on a long-running task.
All card details are entered in Stripe's hosted Checkout flow. Our servers never touch raw payment data. PCI DSS compliance is inherited from Stripe.
Every Stripe webhook is verified against the signing secret with an HMAC-SHA256 constant-time comparison before any business logic runs. Missing or bad signatures are rejected with a 400.
Subscription events, checkout completions, and refunds are deduplicated by Stripe event ID. The same webhook delivered twice (as Stripe often does) never causes double-charges or duplicated credit grants.
Plan IDs are validated against an allow-list at every boundary (checkout, webhook, admin RPC). Price IDs live in Stripe; only their internal plan labels are stored on our side.
If you believe you've found a security vulnerability in Appsanic, please email contact@appsanic.com instead of filing a public issue. We'll acknowledge valid reports within 48 hours and work with you on disclosure timing.
We appreciate every well-researched report and will credit novel findings publicly with your permission.
Have a procurement questionnaire or deeper technical questions about our architecture? Write to our enterprise team directly. We answer questionnaires ourselves, with no third-party portal in between.