Supabase

Draftbit can run a managed Supabase backend for your project: a PostgreSQL database, authentication, file storage, and edge functions that every app in the project can use. Supabase support is in open beta.

The AI agent builds most of the backend for you, such as tables, row level security policies, and edge functions. The Supabase panel in Draftbit is where you check that work and change the settings yourself, including sign-in providers, redirect URLs, custom SMTP, email templates, secrets, and storage buckets. You don’t need a Supabase account, and you don’t need to contact support to change these settings.

Adding Supabase to a project

Supabase runs as an app in your project. To add it, open your project, add an app, and choose Supabase Backend. Each project can have one Supabase Backend app, and the other apps in the project share it.

An API Backend can also use Supabase as its own database. See Supabase in an API Backend.

You can also connect a Supabase project you already own through the Supabase MCP. That project stays in your own Supabase account, so you manage it in Supabase’s dashboard rather than in this panel.

Opening the Supabase panel

Use any of these:

• In the builder, open the app switcher menu at the top of the screen and select Supabase.
• On your project’s page, select Manage Supabase on the Supabase Backend app’s card.
• In any app in the project, open Integrations in the main menu and select the Supabase tab. In other apps, the tab is under Project and appears once the project has a Supabase instance.

You need the Editor role or higher to manage Supabase. Viewers see the connection status only.

Choosing an environment

Each environment has its own Supabase project with separate data, users, settings, and secrets. Use the environment menu at the top of the panel to choose which one you’re looking at and changing. Everything you change in the panel applies only to the environment you have selected.

A Supabase Backend app has these environments:

• Development is where the agent works while you build.
• Staging and Production are created the first time you publish the Supabase Backend app to them. Until then, they show as “created on first publish”.

When you’re ready to release, open the panel and select Publish, or publish the Supabase Backend app from its Publishing page. Publishing deploys the database migrations and edge functions saved in the app’s files. It doesn’t copy changes you made by hand in the panel, such as auth settings, secrets, or rows you edited, so make those changes in each environment that needs them.

Projects that added Supabase before Supabase Backend apps existed have a project-level instance instead. See Projects with a project-level Supabase instance.

Publishing a Supabase Backend app

Open the Supabase Backend app’s Publishing page and select the Environments tab to see where each environment stands. Each card shows the environment’s Supabase URL, which you can copy, and a status:

• Development is always marked “Isolated development target”. The agent works here, and it isn’t replaced when you publish.
• Staging and Production show “Target ready; publish to apply repository migrations and functions.” once their Supabase project exists but nothing has been published to it. After a publish, the card shows the version you deployed, such as “Deployed v1.0.0”.

Publish to Staging or Production the same way you publish any other app. Each publish applies the migrations and edge functions in the app’s files to that environment only, so publishing to Staging doesn’t change Production.

Connecting your apps to Supabase

Your mobile apps, web apps, and websites reach Supabase with two values: the project URL and a publishable key. Each environment has its own URL and keys, so your app needs a different pair for Development, Staging, and Production.

Draftbit doesn’t add these values to your apps. You or the agent add them as environment variables in each app’s Settings. The names are whatever your app’s code reads. Mobile apps commonly use EXPO_PUBLIC_SUPABASE_URL and EXPO_PUBLIC_SUPABASE_PUBLISHABLE_KEY. Web apps use the VITE_ prefix and websites use PUBLIC_, for example VITE_SUPABASE_URL.

Finding the URL and publishable key

• Project URL. The top of the Supabase panel lists each environment with its URL, such as https://<project-ref>.supabase.co, and a copy button. For a Supabase Backend app, the Environments tab on its Publishing page shows the same URLs.
• Publishable key. Choose the environment at the top of the Supabase panel, open API Keys, and copy a key whose type is Publishable. The keys you see belong to the environment you selected.

Never put a secret key in one of these apps. Secret keys bypass row level security, and plain text variables are built into your app where anyone can read them.

Setting the values for each environment

1. Publish your Supabase Backend app to the environment first. Staging and Production don’t have a URL or keys until their first publish.
2. In the Supabase panel, select that environment and copy its URL and publishable key.
3. In your app, open Settings, go to Environment Variables, and select Add Variable.
4. Enter the URL variable’s name, paste the URL as the value, choose Plain text, and under Environment select only the environment the URL belongs to. Save, then do the same for the publishable key.
5. Repeat for each environment. You can add a variable with the same name more than once, as long as each copy covers different environments.
6. Publish your app to that environment again. Your app reads these values when it’s built, so a build made before you added them won’t have them.

You can also give the agent the values and ask it to add the variables for you. Tell it which environment each value is for.

If a variable your code reads still has no value in an environment, the missing-variables notice in Settings lists it with the environments it’s missing from.

Database

The Database section has five tabs.

• Tables lists the tables in your database. Open a table to browse its rows, add a row, edit a row, or delete rows. Select Query your database to run SQL and optionally chart the results.
• Backups lists available backups and point-in-time recovery, where your project’s Supabase plan includes them. Restoring a backup overwrites the database.
• Connection shows connection strings, connection pooling settings, and SSL enforcement for connecting from other tools. It also has network restrictions, which limit database connections to the IP ranges you allow, when your project’s plan supports them.
• Access shows row level security policies, tables that don’t have row level security, and database roles. This tab is read-only. To change policies, run SQL from the Tables tab or ask the agent to write a migration.
• Migrations lists the migrations applied to the database, with the SQL each one ran.

Storage

The Storage section has two tabs.

• Buckets lets you create buckets, set whether a bucket is public, limit file size, and restrict the allowed file types. Inside a bucket you can upload files, create folders, download, move or rename files, copy a public URL, or generate a signed URL that expires. You can also empty or delete a bucket.
• Policies shows the row level security policies that control access to files. This tab is read-only. To change them, run SQL from the Database section or ask the agent.

Authentication

The Authentication section holds your app’s sign-in settings.

Turn sign-ups on or off

General Settings controls whether new users can sign up. When sign-ups are off, existing users can still sign in. This is also where you allow anonymous sign-ins and let your app link a second sign-in method to an existing account.

Turn on Google, Apple, or another OAuth sign-in provider

Under Sign in methods, select a provider, turn it on, and enter the credentials from that provider. For example, Google sign-in needs a client ID and client secret from Google Cloud, and Apple sign-in needs a client ID and a secret key generated from your Apple private key.

Available sign-in methods:

• Email and password, including whether users must confirm their email address
• Phone number
• Web3 wallet (Solana or Ethereum)
• Google, Apple, GitHub, Azure, Bitbucket, Discord, Facebook, Figma, GitLab, Kakao, Keycloak, LinkedIn, Notion, Slack, Spotify, Twitch, X, WorkOS, and Zoom

Use the search box to find a provider quickly.

Set redirect URLs

Under URL Configuration, set the site URL and the Redirect URLs that sign-in links, password resets, and OAuth providers are allowed to send users back to. Add one URL per entry. Wildcards such as https://example.com/** match any path.

Draftbit adds the published web addresses of your project’s apps, including custom domains, and keeps them up to date. Those entries are marked as managed by Draftbit. URLs you add yourself are kept.

Send auth emails from your own domain (custom SMTP)

By default, Supabase sends confirmation, magic link, and password reset emails from its own address. To send them from your own domain, open Custom SMTP under Emails and enter your email provider’s SMTP host, port, user name, password, and sender details.

Custom SMTP settings are always saved to Production as well as the environment you have selected, so your live app sends from your domain. For a step-by-step setup, including email rate limits, see Setting up custom SMTP for auth emails.

Edit email templates

Open Email Templates under Emails to edit the subject and HTML body of each authentication email and security notification, with a live preview. The editor lists the template variables you can use. Some Supabase projects require custom SMTP before templates can be edited.

Email Notifications chooses which security notifications users receive, such as when their password, email address, or phone number changes, or when a sign-in method or MFA factor is added or removed.

Sessions, MFA, CAPTCHA, and rate limits

Under Sessions & Security:

• Sessions & Tokens sets how long access tokens last, how refresh tokens work, and session limits.
• Multi-Factor Authentication chooses which second factors users can enroll and verify with. Turning off verification for a factor that users have already enrolled can lock them out.
• Bot & Abuse Protection requires a CAPTCHA on sign-up, sign-in, and password reset. Your app must send the CAPTCHA token with each auth request.
• Rate Limits sets how often users can request emails, text messages, and tokens. A value of 0 blocks that action.

Auth hooks

Under Auth Hooks, you can point Supabase at your own endpoint or database function to customize auth:

• Custom Access Token adds your own claims to access tokens.
• Send Email and Send SMS send auth messages through your own service.
• MFA Verification Attempt and Password Verification Attempt decide whether a sign-in attempt is allowed.
• Before User Created validates or blocks a sign-up, and After User Created runs after a new account is created.

Hooks are set per environment.

Users

The Users section shows a chart of new sign-ups over a time range you choose and a list of recent users.

API Keys

The API Keys section lists the project’s keys. Publishable keys are safe to ship in your app because row level security still applies. Secret keys bypass row level security, so use them only on a server. You can create publishable or secret keys with a name and description, reveal or copy a key, and delete keys.

Secrets

The Secrets section stores values your edge functions need, such as third-party API keys. Add a secret with a name and value, or delete existing secrets.

Secrets belong to the environment you have selected. Environments don’t share secrets, and deploying or publishing doesn’t copy them, so add each secret to every environment that needs it.

Edge Functions

The Edge Functions section lists deployed functions. Open a function to see its invoke URL, version, whether it verifies JWTs, and request statistics such as error rates. You can create a function, edit its files, and rename it in the panel. Functions that use features the editor doesn’t support show a notice; ask the agent to change those.

Logs

The Logs section shows logs by type, including API, database, authentication, storage, realtime, edge function, and cron job logs. Choose a log type and time range.

Production

The Production section shows recent API logs. Choose a time range.

Suggestions

The Suggestions section lists security and performance recommendations from Supabase, such as tables without row level security.

Projects with a project-level Supabase instance

Projects that added Supabase before Supabase Backend apps existed have one Supabase instance for the whole project, with a Development environment where the agent works and Production.

Your apps use the production URL and keys for builds that should see live data. Use the development URL and keys only for Development. These projects don’t have a separate Staging environment in Supabase, so choose whether your app’s Staging builds use development or production.

Deploying to production

Deploy to production applies the database changes and edge functions you and the agent worked on in development to production, so they become available to every app in the project. Draftbit runs Supabase security checks first and lists anything it finds before deploying, and you can review the source and destination in the confirmation dialog.

A deploy also copies your auth settings from development to production, except custom SMTP and auth hooks. It doesn’t copy secrets or table data, so check those in production before you launch. For a full launch checklist, see Connecting your app to Production with managed Supabase.

Your development environment is kept after a deploy. Draftbit updates it from production so it stays in step, and you keep working in it with the data you already have in it.

Supabase in an API Backend

When you add an API Backend and choose Supabase as its database, or select Provision Supabase on its Database tab later, the API Backend gets its own Supabase database. Only that API Backend uses it. Your other apps reach the data through the API, using the API URL and key variables described in Connecting your apps, not a Supabase URL and key.

Open the API Backend, go to Integrations, and select the Database tab to see it:

• While the database is being set up, the tab shows a Supabase Postgres card with a row for each environment. Staging and Production read “Created on first publish to Staging.” and “Created on first publish to Production.” until you publish the API Backend there. If setup stops or fails, select Retry.
• Once the development database is ready, the tab shows the Supabase panel. Only the Database section is available, because this Supabase instance serves as a database only. Use the environment menu at the top to switch between the environments that exist.

Publishing the API Backend to Staging or Production creates that environment’s database if it doesn’t exist yet, then runs your migrations against it.

Moving the project to your own Supabase account

Select Claim this project at the bottom of the panel to transfer the Supabase project to a Supabase organization you own. Billing, team members, and ownership move to you. Only production is moved, so deploy anything you want to keep from development first.

After you claim it, Draftbit no longer manages the project, and the Supabase panel is removed for it. For a Supabase Backend app, the app is archived: the agent and publishing are turned off, its files stay available read-only, and its development and staging environments are deleted with their data. For an app’s own Supabase database, the development and staging databases are deleted with their data, and every environment of the app then connects to the claimed production database. To let the agent work with the project again, connect the Supabase MCP with your own Supabase account. Claiming can’t be undone.

Limits

• Supabase support is in open beta.
• A project can have one Supabase Backend app.
• A Supabase Backend app’s published environments can’t be unpublished, because that would delete their data.
• Some features depend on your project’s Supabase plan, such as scheduled backups, point-in-time recovery, network restrictions, and editing email templates without custom SMTP. The panel tells you when one isn’t available.
• Policies and roles are read-only in the panel. Change them with SQL or ask the agent.
• A database attached to a single app shows only the Database section.