## What kind of change does this PR introduce? Feature / abuse-prevention update. Resolves DEPR-198. ## What is the current behaviour? Free projects using Supabase's built-in email service can edit raw Auth email template subjects and HTML in Studio. That is the risky cohort this project is trying to constrain. ## What is the new behaviour? ### Template editing restrictions For free projects using Supabase's built-in email service, Studio keeps Auth email templates viewable and previewable but disables subject/body editing and saving. Editing is unlocked by setting up Custom SMTP, configuring a send-email hook, or upgrading to a paid plan. **Grandfathering:** projects created before `2026-06-01T00:00:00Z` (the platform enforcement cutoff) are exempt; their editing UI stays unlocked. This mirrors `FREE_TIER_TEMPLATE_BLOCK_CUTOFF_DATE` in the platform PR exactly. | After | | --- | | <img width="1024" height="759" alt="Emails Authentication Fizz Test Supabase-173BB09B-0FB9-4133-8202-9E310DDB347A" src="https://github.com/user-attachments/assets/c966212d-ed0c-443b-8197-440cc2937ef6" /> | | <img width="1024" height="759" alt="Emails Authentication Fizz Test Supabase-CD5845EB-0E45-4779-8989-44E775B2411A" src="https://github.com/user-attachments/assets/055a64d6-b5e8-4d37-a261-6e280f04536a" /> | ### Warning dialogs on transitions that reset templates Two flows now surface a warning before the user commits to a state change that resets their custom email templates to defaults: 1. **Disabling custom SMTP** (SMTP settings page): a confirmation dialog warns that templates will be reset to defaults and the email rate limit reduced to 2 per hour. On confirm, Studio resets all 13 templates via the existing per-template reset endpoint (`Promise.allSettled`). The "won't be able to edit" sentence is shown only for post-cutoff projects; grandfathered projects skip it. The corresponding server-side enforcement is in the Platform PR: https://github.com/supabase/platform/pull/33129 2. **Downgrading to the Free plan** (billing settings): an admonition in the existing downgrade confirmation modal warns that custom templates will be reset to defaults and won't be editable without custom SMTP. The admonition is shown only when the org has at least one post-cutoff project; orgs whose projects are all grandfathered skip it. | Custom SMTP | Downgrading | | --- | --- | | <img width="862" height="586" alt="66764" src="https://github.com/user-attachments/assets/6470c8a6-2f79-40a5-ad3b-bfe5b0ba9c54" /> | <img width="1268" height="1552" alt="CleanShot 2026-05-22 at 17 28 37@2x-FEB1901E-38E6-42DF-8C27-0A036D8A1B94" src="https://github.com/user-attachments/assets/e8caa9e6-c3ed-4787-b771-af77a43eb854" /> | ### Informational admonition when enabling SMTP When a user enables custom SMTP for the first time, a sandwiched admonition above the save footer informs them that the email rate limit will be increased to 30 per hour and can be adjusted. _This is just a minor cosmetic change, unrelated to the email template disabling. Sorry._ | Before | After | | --- | --- | | <img width="1024" height="759" alt="Emails Authentication Chisel Toolshed Supabase-54317D18-803C-4A58-8211-2359355D083B" src="https://github.com/user-attachments/assets/29eff649-02dc-40f3-a379-0b4d484a76c7" /> | <img width="1024" height="759" alt="Emails Authentication Chisel Toolshed Supabase-9E12399E-E9FB-4F9A-B029-A08008EA4B50" src="https://github.com/user-attachments/assets/e542ed86-4da6-407e-8293-0f4c0f071e18" /> | ## How to test All existing projects pre-date the enforcement cutoff (`2026-06-01T00:00:00Z`) and are grandfathered, so the restriction UI won't appear by default. To force the restricted state locally, back-date the cutoff in one file: In `apps/studio/components/interfaces/Auth/EmailTemplates/EmailTemplates.utils.ts`, temporarily change: ```ts export const FREE_TIER_TEMPLATE_BLOCK_CUTOFF_DATE = '2026-06-01T00:00:00Z' ``` to: ```ts export const FREE_TIER_TEMPLATE_BLOCK_CUTOFF_DATE = '2025-01-01T00:00:00Z' ``` Revert before committing. With the cutoff back-dated, use a free-plan project and: - **Template restriction + admonition:** navigate to Authentication > Emails with no custom SMTP configured. Subject/body fields should be read-only and the "Set up SMTP" admonition should appear, with its dropdown offering upgrade and send-email hook options. - **SMTP disable warning:** enable custom SMTP on a project, then disable it via Authentication > SMTP Settings. The confirmation dialog should warn that templates will reset to defaults and that editing will be restricted after disabling. - **Downgrade warning:** in billing settings, initiate a downgrade to the Free plan. The downgrade modal should include an admonition warning about template reset and restricted editing (only if the org has at least one post-cutoff project). ## Additional context The default Auth email template copy was also improved across docs, examples, and UI library snippets (separate prior commits). The per-template reset button (`ResetTemplateDialog`) was migrated to the async `AlertDialogAction` pattern introduced in #45960; the dialog stays open and shows a loading state while the reset is in-flight, closes on success, and stays open on error. Closes PRODSEC-183 --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com> Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com> Co-authored-by: Stephen Morgan <stephen@doublethink.co.nz>
Reference Docs
Supabase Reference Docs
Maintainers
If you are a maintainer of any tools in the Supabase ecosystem, you can use this site to provide documentation for the tools & libraries that you maintain.
Versioning
All tools have versioned docs, which are kept in separate folders. For example, the CLI has the following folders and files:
cli: the "next" release.cli_spec: contains the DocSpec for the "next" release (see below).cli_versioned_docs: a version of the documentation for every release (including the most current version).cli_versioned_sidebars: a version of the sidebar for every release (including the most current version).
When you release a new version of a tool, you should also release a new version of the docs. You can do this via the command line. For example, if you just released the CLI version 1.0.1:
npm run cli:version 1.0.1
DocSpec
We use documentation specifications which can be used to generate human-readable docs.
- OpenAPI: for documenting API endpoints.
- SDKSpec (custom to Supabase): for SDKs and client libraries.
- ConfigSpec (custom to Supabase): for configuration options.
- CLISpec (custom to Supabase): for CLI commands and usage.
The benefit of using custom specifications is that we can generate many other types from a strict schema (eg, HTML and manpages). It also means that we can switch to any documentation system we want. On this site we use Next.js, but on Supabase's official website, we use a custom React site and expose only a subset of the available API for each tool.
Contributing
To contribute to docs, see the developers' guide and contributing guide.