Vibecoding provisions every site we build directly onto your Supabase project. You paste your URL + service role key + management PAT once, encrypted at rest. After the build, we exit the data path — your site talks to your DB.
Email, magic link, Google SSO — all using Supabase Auth on your project. Sessions in cookies, refresh tokens handled.
Schema migrations applied via the Supabase Management API. Row-level security policies generated for every table.
Public + private buckets for images, attachments, media. Signed URLs, transformations.
Forms write to a leads table on your DB with disposition pipelines. WhatsApp alerts ping on submission.
Posts, categories, tags, OG metadata. AI generation writes drafts directly to your DB.
Scheduled functions run on Vercel, write back to Supabase. Idempotent by default.
From your Supabase dashboard, you give us three values once. Encrypted at rest, used only during builds.
We never store your password. We never read other Supabase projects on your account.
Only when you click Build. The credentials you paste in the Connections tab are AES-256-GCM encrypted and used solely to: (a) apply the schema migrations for the features you enabled, (b) seed sample data if you asked for it, (c) optionally configure auth providers. After the build completes, your site talks to your Supabase directly — Vibecoding never sits in the data path.
Free tier is enough to start. A typical small business site fits well within the free tier limits (500 MB DB, 1 GB storage, 50 K monthly active users for auth). Upgrade only if you scale past those limits.
Yes. Vibecoding's migrations are vanilla SQL — if you add a column in the Supabase Studio UI, it just becomes part of your schema. The next chat turn will pick up the change. We don't enforce a model.
Paste its credentials in the Connections tab. Vibecoding inspects the schema and only applies migrations that don't conflict with existing tables. You'll see a preview of what will run before anything executes.
Each Vibecoding-built site has its own ordered migration sequence in `supabase/migrations/`. Migrations are tracked in a `_skeleton_migrations` table on your DB so re-runs are idempotent. You can inspect or roll back any migration via standard Postgres tooling.
Yes — wired by default for chat-style features. If you build something with live updates, the corresponding Realtime channels are configured during the build.