- Connect your Supabase account - With a click of a button, an OAuth flow launches to securely authenticate with your Supabase project
- Provide database credentials - This allows Dreamlit to securely connect your app and complete the integration.
Configuring Supabase Auth emails
If you’re using Supabase Auth for user authentication, you’ll need to set up a proper email sender for all your auth emails—otherwise you’ll be stuck with Supabase’s defaults, which are not production-ready.Do I need to configure auth emails?
Do I need to configure auth emails?
You need custom auth emails if you’re using any of the following authentication methods:
- Email and password accounts
- Passwordless login (magic links or OTP sent via email)
- Email-based user invitations (from dashboard or admin APIs)
- Social login with email confirmation
- User sign-up with email verification
- “Forgot password” functionality
- Account email changes that require confirmation
- Admin-invited users who receive invitation links
- Passwordless login where users click a link in their email
Why Supabase's default auth emails aren't production-ready
Why Supabase's default auth emails aren't production-ready
Supabase default auth setup is intended for:
- Exploring and getting started with Supabase Auth
- Testing templates with team members
- Toy projects, demos, or non-critical applications
- Blocks real users: Emails only go to addresses in your project’s team (managed in organization settings)
- Error for everyone else: Non-team addresses fail with “Email address not authorized”
- Example: If your team has 3 members, only those 3 email addresses can receive auth emails
- Currently limited to 4 emails per hour (can change without notice)
- This means only 4 password resets, sign-ups, or magic links per hour for your entire app
- Rate limits are subject to change at Supabase’s discretion
- Sends from
[email protected]
(runs the risk of being marked as spam)
- No SLA for delivery or uptime
- Provided as “best-effort” only
- Explicitly stated as not for production use
Your (non-Dreamlit) options to setup a custom email sender
Your (non-Dreamlit) options to setup a custom email sender
Supabase provides two options for production auth emails:
Configure SMTP
Setup: Add SMTP credentials in Supabase dashboardPros: Easier to get going compared with Auth HooksCons: Still uses Supabase’s basic templates, and must be customized in the Supabase dashboard (with no AI). Limited to their template variables. Must manage SMTP credentials.
Setup Auth Hooks
Setup: Write and deploy webhook endpointsPros: Full control over emailsCons: Requires backend development. Must handle email sending logic. Need to manage infrastructure. Complex error handling and retries.
Setting up Supabase Auth with Dreamlit
As part of the setup process, you’ll be asked if you’d like to configure auth emails with Dreamlit. Simply select “yes” and the process will take care of the rest. It’s that easy! If you select “yes”, the setup will:- Setup an auth hook for your Supabase project
- Automatically create and publish 6 workflows for you in Dreamlit, one for each of the auth email types in Supabase Auth: password reset, magic link, reauthentication, email change, confirm email, and invite link
- Generate beautiful default templates branded with your app name and sender
- Configure everything to work immediately with your existing Supabase Auth setup
How to trigger auth emails
When you configure auth emails through Dreamlit’s setup process, we automatically install a Supabase Auth Hook in your project. This hook intercepts auth events and routes them to Dreamlit for custom email delivery. Unlike regular database-triggered workflows, Supabase Auth emails work through API calls: Auth emails ONLY trigger when your app calls Supabase auth APIs. Your app code must invoke the appropriate method for each email type:Email Type | Supabase API Method | When to Use |
---|---|---|
Password Reset | supabase.auth.resetPasswordForEmail() | User clicks “Forgot Password” |
Magic Link | supabase.auth.signInWithOtp() | For passwordless login (magic link or OTP) |
Reauthentication | supabase.auth.reauthenticate() | Before password change (if Secure Password Change enabled) |
Email Change | supabase.auth.updateUser({email}) | Changing user email (if Secure Email Change enabled) |
Confirm Email | supabase.auth.signUp() | New user registration (if Confirm Email enabled) |
Invite Link | supabase.auth.admin.inviteUserByEmail() | Admin inviting new users |
To reemphasize: Supabase specific auth emails are not triggered by persisting events to your database. Auth emails only work through Supabase API calls.
Making schema changes safely
As your application evolves, you’ll need to update your database schema. To ensure your Dreamlit workflows continue running smoothly during schema migrations, we recommend one of the following approaches:Option 1: Unpublish, change, then publish again
Option 1: Unpublish, change, then publish again
If you don’t mind brief downtime for your workflows, this is the quickest approach.
- Unpublish any workflows referencing the old column/table.
- Apply your schema update.
- Adjust your Dreamlit workflow steps to reference the new schema.
- Publish your workflow again.
Option 2: Phased migration
Option 2: Phased migration
You can follow the “expand, migrate, and contract pattern” to make your schema changes.
- Add new columns or tables.
- Write to both old and new columns from your application.
- Backfill data into the new columns or tables.
- Update your Dreamlit workflow to reference the new columns/tables, and possibly update your application to reference the new columns/tables.
- Remove (or rename) the old columns/tables once no longer needed.
Technical deep dive: how Dreamlit configures your database
Dreamlit’s notification architecture is optimized for the performance and robustness of your workflows. Your database is minimally instrumented accordingly. The very first time you set up a database connection, Dreamlit creates adreamlit
schema (if it doesn’t already exist) and an event_log
table
inside it. Then, whenever you publish a workflow containing a Database Trigger step, Dreamlit creates:
- A table trigger on the specified table, which activates whenever a relevant insert or update occurs.
- A trigger function in the
dreamlit
schema that runs when the trigger fires, which simply logs a row to thedreamlit.event_log
table indicating that a new event has occurred.
dreamlit.event_log
table, and whenever it sees a new row matching an active trigger, it launches the associated workflow.
In addition to the
event_log
table, Dreamlit may create other small
housekeeping tables in the dreamlit
schema. It never writes to your existing
tables (beyond installing triggers).What's a schema and why does Dreamlit need one in my db?
What's a schema and why does Dreamlit need one in my db?
A schema is a grouping of tables, functions, and other database objects.
It’s a way for you organize your tables, often for security reasons. See here for more.Dreamlit manages its objects in a dedicated schema so that it provides a clean separation between your application and the Dreamlit-managed objects. Dreamlit’s approach allows for events
to be detected in realtime, while ensuring events don’t get lost. This separate schema approach is inspired by
similar techniques used in other tools like Supabase and Hasura.
Uninstalling Dreamlit
If you ever want to remove Dreamlit entirely:- Unpublish all workflows that depend on your Supabase connection (this removes triggers/functions).
- Delete the connection in the Dreamlit dashboard.
- (Optional) Drop the
dreamlit
schema to remove all Dreamlit-managed objects.
That’s it! By connecting Supabase to Dreamlit, you can create powerful,
real-time workflows triggered by database changes — without writing any custom
code in your application.