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.

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 under Project resources.
• On your project’s page, select Manage Supabase on the Supabase Backend app’s card.
• In the Supabase Backend app, open APIs & Data in the main menu and select the Supabase tab.
• In any other app in the project, open APIs & Data and select Manage 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, except custom SMTP (see Send auth emails from your own domain).

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.

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. If scheduled backups aren’t available, use restore points instead.
• 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.

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.

Restore points and rollback

The Production section has two tabs.

• API Logs shows recent API errors.
• Restore Points lets you save a named snapshot of the database before you make changes, then roll back to it later. A restore point captures schema changes, data, auth users, and storage file references. It doesn’t capture configuration, secrets, the stored files themselves, or deployed edge functions. Rolling back undoes every database change made since the restore point, and it can’t be undone.

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 branch where the agent works and Production.

Deploying to production

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

A deploy also copies your auth settings from the development branch to production, except custom SMTP and auth hooks. It doesn’t copy secrets.

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

Starting a fresh development branch

Use Fresh dev branch, next to the deploy button, when you want to start over with a clean development environment. Draftbit creates a replacement branch from production’s schema and then deletes the current one.

The replacement branch starts empty. Your Supabase secrets and production’s auth settings are copied into it. Everything that lives only in the current branch is deleted with it, including its data and any schema changes or edge functions you have not deployed to production yet. Deploy anything you want to keep before you reset, because the deletion cannot be undone.

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, and all database branches are kept.

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, and its files stay available read-only. 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.