Skip to main content
Mythos builds the frontend; Supabase is the backend you bring. Connecting your own Supabase project gives your app a database, authentication, and file storage — all living in your Supabase account, not Mythos’s. Once connected, the agent knows your project exists and writes code that reads and writes your data through a typed client. You connect Supabase from inside the workspace, under Services → Cloud.
Cost: connecting Supabase does not cost credits. Asking the agent to wire a form, table, or login into it is an edit (2 credits) or part of a build (3 credits). See Credits & pricing.
Your Supabase vs ours. This page is about your own Supabase project — the one holding your app’s data. Mythos runs on a separate Supabase for its own accounts; you never touch that one. See Integrations overview.

​
Why connect Supabase

  • Save real data. A contact form, a sign-up list, a booking — anything that needs to persist needs a database. Supabase is that database.
  • Add user accounts. Supabase auth gives your app login, signup, and per-user data.
  • Store files. Uploads and assets go to Supabase storage.
  • You own all of it. The project, the data, and the keys live in your Supabase account.

​
Prerequisites

  • A Mythos project (the agent has scaffolded at least a starting page).
  • A Supabase account. If you connect with OAuth and have no project yet, Mythos can create one for you.

​
How to connect

You have two ways to connect: paste your project’s keys, or authorize with Supabase OAuth.
1

Open Services → Cloud

In the workspace, open the Services panel and select Cloud. Before you connect, the Cloud section shows a single Enable Cloud card.
2

Choose how to connect

Use the Connect button to authorize with Supabase (OAuth), or “Already have a Supabase project? Connect it here” to paste credentials instead.
3

Connect with OAuth (recommended)

Authorize Mythos in the Supabase consent screen that opens in a popup. If your account has no project, Mythos provisions one for you and shows “Setting up your database…” while it becomes ready. The workspace stays open the whole time.
4

Or paste credentials

Paste your project’s URL, anon key, and service role key. Mythos validates the URL and key shapes and pings your project’s health endpoint before saving.
5

Start building against it

Once connected, the Cloud console (Database, Users, Storage, and more) appears, and the agent can wire your app to the database. Ask it to build a form, a table, or login.

​
Provisioning states (OAuth)

If Mythos creates a project for you, the connect flow moves through these states:
StateWhat you seeWhat you do
Provisioning”Setting up your database…”Wait — the workspace stays open; it can take a minute.
ConnectedThe Cloud console (Database, Users, Storage, …) appearsStart asking the agent to wire data.
FailedA connection errorRetry the OAuth connect and accept the requested permissions.

​
Examples

Once connected, describe the data you want in plain language: 
Add a contact form that saves name, email, and message to a `leads` table, with RLS so only I can read it.

Add email sign-in with Supabase Auth and a profile page each user can edit.

​
What happens on connect

  • Your credentials are encrypted at rest (AES-256-GCM) and stored server-side. They are not exposed to your app’s frontend or to the AI beyond what is described below.
  • The integration scaffold is committed to your repo — integrations/supabase/client.ts (a typed client), integrations/supabase/types.ts (types generated from your live schema), a committed .env (your project URL and the public anon key), and supabase/config.toml. This is what lets the app — and the published build — actually reach Supabase.
  • The agent gets only { url, anonKey }. It is told your project URL and public anon key so it can import the client and write code against it. It does not receive your service role key.
The committed .env contains your project URL and the public anon key only — these are public by design and safe in your repo. Your service role key is never committed and never given to the AI. Keep any private keys (payment secrets, third-party API keys) out of .env and out of prompts.

​
What the agent can and cannot see

Visible to the AI agent
Project URLYes
Public anon keyYes
Service role keyNo — stays server-side
Your table dataNo
Live schema (table/column names)Yes, via generated types

​
Database migrations

When you ask the agent to add a table or change your schema, it uses a db_migrate step. On an OAuth-connected project, this applies the migration to your live database and regenerates the TypeScript types in the same turn, so the agent’s code stays in sync with your real schema.
For destructive schema changes (dropping tables or columns) and for paste-connected projects, the agent does not auto-apply. Instead it writes a .sql file into your repo for you to run yourself. This protects against accidental data loss.
Every new table must have Row Level Security. A migration that creates a table is refused unless it both enables RLS and adds a policy for that table — otherwise anyone holding the public anon key could read it. Just ask for it in plain language (for example, “so only I can read it”) and the agent writes the policy. If a schema request is rejected, a missing RLS policy is the most likely reason.

​
The Cloud console

After an OAuth connect, Services → Cloud is a console over your own Supabase — Database, Users, Storage, an SQL editor, Secrets, Edge functions, Logs, and Usage. These run against your project server-side; they are operations you initiate, not Mythos proxying your app’s traffic.
Paste-connected projects connect successfully, but the live console steers you toward OAuth — the console’s advanced sections rely on the Supabase Management-API token that OAuth provides.

​
Limitations & good to know

  • Supabase is the supported backend. A few other provider names (Neon, Vercel, PlanetScale, custom MCP) exist as reserved values, but no connect flow writes them and they get no agent wiring — treat Supabase as the path that works.
  • Legacy already-connected projects may need one reconnect (or a fresh build) to receive the committed .env, because an edit only commits changed files.
  • Switching projects means pointing at a new Supabase project — Mythos does not migrate your data between projects.

​
Troubleshooting

ProblemFix
”Couldn’t connect” on OAuthThe authorization may be missing a scope. Retry the OAuth connect and accept the requested permissions.
Published site white-screens with a “Missing VITE_SUPABASE_URL” errorThe repo is missing the committed .env. Reconnect Supabase, or run one fresh build, to commit it.
A schema change didn’t applyDestructive changes and paste-connected projects fall back to a .sql file in your repo — apply it in Supabase yourself.
A “create a table” request was refusedA new table needs RLS plus a policy. Re-ask and say who should read it (e.g. “so only I can read it”) and the agent adds the policy.

​
FAQ

No. The agent receives only your project URL and the public anon key. The service role key stays server-side and is never given to the AI; your table data is never sent to it.
Yes. The committed .env holds only the project URL and the public anon key, which are public by design. The published build needs them to reach Supabase. Private keys are never committed.
Connect with OAuth and Mythos can provision one for you, then wait for it to become ready before finishing the connection.
Not today. Other provider names exist in the system as reserved values, but Supabase is the only backend with a working connect flow and agent support.
From the same Services → Cloud panel where you connected. Disconnecting removes the stored credentials; your Supabase project and its data are untouched.