[pull] master from supabase:master

apps/docs/components/Navigation/NavigationMenu/NavigationMenu.constants.ts

@@ -2088,6 +2088,7 @@ export const security: NavMenuConstant = {
       name: 'Product security',
       url: undefined,
       items: [
+        { name: 'Platform configuration', url: '/guides/security/platform-security' },
         { name: 'Product configuration', url: '/guides/security/product-security' },
         { name: 'Security testing', url: '/guides/security/security-testing' },
       ],
@@ -2170,12 +2171,8 @@ export const platform: NavMenuConstant = {
           url: '/guides/platform/multi-factor-authentication',
           items: [
             {
-              name: 'Enable MFA',
-              url: '/guides/platform/multi-factor-authentication',
-            },
-            {
-              name: 'Require MFA for organization members',
-              url: '/guides/platform/org-mfa-enforcement',
+              name: 'Enforce MFA on organization',
+              url: '/guides/platform/mfa/org-mfa-enforcement',
             },
           ],
         },
@@ -2453,7 +2450,26 @@ export const deployment: NavMenuConstant = {
       items: [
         { name: 'Managing environments', url: '/guides/deployment/managing-environments' },
         { name: 'Database migrations', url: '/guides/deployment/database-migrations' },
-        { name: 'Branching', url: '/guides/deployment/branching' },
+      ],
+    },
+    {
+      name: 'Branching',
+      url: undefined,
+      items: [
+        { name: 'Overview', url: '/guides/deployment/branching' },
+        { name: 'GitHub integration', url: '/guides/deployment/branching/github-integration' },
+        {
+          name: 'Branching 2.0 (Alpha)',
+          url: '/guides/deployment/branching/branching-2',
+        },
+        {
+          name: 'Working with branches',
+          url: '/guides/deployment/branching/working-with-branches',
+        },
+        { name: 'Configuration', url: '/guides/deployment/branching/configuration' },
+        { name: 'Integrations', url: '/guides/deployment/branching/integrations' },
+        { name: 'Troubleshooting', url: '/guides/deployment/branching/troubleshooting' },
+        { name: 'Billing', url: '/guides/platform/manage-your-usage/branching' },
       ],
     },
     {

apps/docs/content/guides/deployment/branching/branching-2.mdx

@@ -0,0 +1,67 @@
+---
+title: 'Branching 2.0 (Alpha)'
+subtitle: 'Create and manage branches without using Git'
+---
+
+Branching 2.0 allows you to create and manage Supabase branches without connecting to a Git repository. This is useful for quick testing, prototyping, or when you prefer to manage your database changes outside of Git.
+
+<Admonition type="note" label="Public Alpha">
+
+Branching 2.0 is currently in public alpha. Features and functionality may change.
+
+</Admonition>
+
+## How Branching 2.0 works
+
+With Branching 2.0, you can do the following directly from the Supabase dashboard:
+
+- Create preview branches
+- Make changes to your public schema or edge functions
+- Merge these changes back into production when ready
+- Pull in updates from production
+
+## Enable Branching 2.0
+
+Branching 2.0 is available as a Feature Preview. To enable Branching 2.0 in the Supabase Dashboard:
+
+1. Open the user menu by clicking on your user icon in the top right.
+1. Select **Branching 2.0**.
+1. Click **Enable feature**.
+
+## Creating a branch
+
+Once you've enabled Branching 2.0, you can create a new branch:
+
+1. Click the arrows next to the branch name in the top menu bar. (The top menu bar has the format `YOUR_ORGANIZATION / YOUR_PROJECT / CURRENT_BRANCH_NAME`.)
+2. Click `Create branch`.
+
+## Making changes to a branch
+
+Use the branch selector in the top bar to change to your branch. Any changes you make (including SQL run in the SQL editor, table editor changes, and configuration changes) are now made against the currently selected branch.
+
+You can also use the branch's API keys and connection strings to run changes against the branch from your own code or SQL client.
+
+## Creating a merge request
+
+To review and merge changes from a branch back into your production branch, you must first create a merge request. There are two ways to do this.
+
+The first is to click the merge request button next to the branch selector that's located in the top menu. This will create the merge request and redirect you to the merge page where you can review and merge any changes.
+
+The second is to click on manage branches from within the branch selector, then in the left hand navigation you can click on merge requests. From here you can view all open merge requests and create new ones.
+
+## Pulling changes from production into a branch
+
+When reviewing a merge request you may see a notice at the top of the page asking you to update your branch. This appears when your preview branch has drifted from your production branch. There may be public schema or edge function changes that have been made after your preview branch was created. Clicking update branch will attempt to pull in these changes, but be aware that by doing this your existing edge functions will be replaced. Any new edge functions created on the preview branch will remain untouched.
+
+## Limitations
+
+There are a few limitations you should be aware of before deciding to use branching without git.
+
+- Custom roles created through the dashboard are not captured on branch creation
+- Only public schema changes are supported right now
+- Extensions are not included in the diff process
+- Branches can only be merged to main; merging between preview branches is not supported
+- If your branch is out of date, you can pull in latest changes from main, but keep in mind that all functions will be overwritten
+- Deleting functions must be done manually on main branch
+- Migration conflicts must be manually resolved on the preview branch
+- If you have run migrations on main, new branches will be created from existing migrations instead of a full schema dump

apps/docs/content/guides/deployment/branching/configuration.mdx

@@ -0,0 +1,207 @@
+---
+title: 'Configuration'
+subtitle: 'Configure your Supabase branches using configuration as code'
+---
+
+This guide covers how to configure your Supabase branches, using the `config.toml` file. In one single file, you can configure all your branches, including branch settings and secrets.
+
+## Branch configuration with remotes
+
+When Branching is enabled, your `config.toml` settings automatically sync to all ephemeral branches through a one-to-one mapping between your Git and Supabase branches.
+
+### Basic configuration
+
+To update configuration for a Supabase branch, modify `config.toml` and push to git. The Supabase integration will detect the changes and apply them to the corresponding branch.
+
+### Remote-specific configuration
+
+For persistent branches that need specific settings, you can use the `[remotes]` block in your `config.toml`. Each remote configuration must reference an existing project ID.
+
+Here's an example of configuring a separate seed script for a staging environment:
+
+```toml
+[remotes.staging]
+project_id = "your-project-ref"
+
+[remotes.staging.db.seed]
+sql_paths = ["./seeds/staging.sql"]
+```
+
+Since the `project_id` field must reference an existing branch, you need to create the persistent branch before adding its configuration. Use the CLI to create a persistent branch first:
+
+```bash
+supabase --experimental branches create --persistent
+# Do you want to create a branch named develop? [Y/n]
+```
+
+### Configuration merging
+
+When merging a PR into a persistent branch, the Supabase integration:
+
+1. Checks for configuration changes
+2. Logs the changes
+3. Applies them to the target remote
+
+If no remote is declared or the project ID is incorrect, the configuration step is skipped.
+
+### Available configuration options
+
+All standard configuration options are available in the `[remotes]` block. This includes:
+
+- Database settings
+- API configurations
+- Authentication settings
+- Edge Functions configuration
+- And more
+
+You can use this to maintain different configurations for different environments while keeping them all in version control.
+
+## Managing secrets for branches
+
+For sensitive configuration like SMTP credentials or API keys, you can use the Supabase CLI to manage secrets for your branches. This is especially useful for custom SMTP setup or other services that require secure credentials.
+
+To set secrets for a persistent branch:
+
+```bash
+# Set secrets from a .env file
+supabase secrets set --env-file ./supabase/.env
+
+# Or set individual secrets
+supabase secrets set SMTP_HOST=smtp.example.com
+supabase secrets set SMTP_USER=your-username
+supabase secrets set SMTP_PASSWORD=your-password
+```
+
+These secrets will be available to your branch's services and can be used in your configuration. For example, in your `config.toml`:
+
+```toml
+[auth.smtp]
+host = "env(SMTP_HOST)"
+user = "env(SMTP_USER)"
+password = "env(SMTP_PASSWORD)"
+```
+
+<Admonition type="note" label="Secrets are branch-specific">
+
+Secrets set for one branch are not automatically available in other branches. You'll need to set them separately for each branch that needs them.
+
+</Admonition>
+
+### Using dotenvx for git-based workflow
+
+For managing environment variables across different branches, you can use [dotenvx](https://dotenvx.com/) to securely manage your configurations. This approach is particularly useful for teams working with Git branches and preview deployments.
+
+#### Environment file structure
+
+Following the conventions used in the [example repository](https://github.com/supabase/supabase/blob/master/examples/slack-clone/nextjs-slack-clone-dotenvx/README.md), environments are configured using dotenv files in the `supabase` directory:
+
+| File            | Environment | `.gitignore` it? | Encrypted |
+| --------------- | ----------- | ---------------- | --------- |
+| .env.keys       | All         | Yes              | No        |
+| .env.local      | Local       | Yes              | No        |
+| .env.production | Production  | No               | Yes       |
+| .env.preview    | Branches    | No               | Yes       |
+| .env            | Any         | Maybe            | Yes       |
+
+#### Setting up encrypted secrets
+
+1. Generate key pair and encrypt your secrets:
+
+```bash
+npx @dotenvx/dotenvx set SUPABASE_AUTH_EXTERNAL_GITHUB_SECRET "<your-secret>" -f supabase/.env.preview
+```
+
+This creates a new encryption key in `supabase/.env.preview` and a new decryption key in `supabase/.env.keys`.
+
+2. Update project secrets:
+
+```bash
+npx supabase secrets set --env-file supabase/.env.keys
+```
+
+3. Choose your configuration approach in `config.toml`:
+
+Option A: Use encrypted values directly:
+
+```toml
+[auth.external.github]
+enabled = true
+secret = "encrypted:<encrypted-value>"
+```
+
+Option B: Use environment variables:
+
+```toml
+[auth.external.github]
+enabled = true
+client_id = "env(SUPABASE_AUTH_EXTERNAL_GITHUB_CLIENT_ID)"
+secret = "env(SUPABASE_AUTH_EXTERNAL_GITHUB_SECRET)"
+```
+
+<Admonition type="note" label="Secret fields">
+
+The `encrypted:` syntax only works for designated "secret" fields in the configuration (like `secret` in auth providers). Using encrypted values in other fields will not be automatically decrypted and may cause issues. For non-secret fields, use environment variables with the `env()` syntax instead.
+
+</Admonition>
+
+#### Using with preview branches
+
+When you commit your `.env.preview` file with encrypted values, the branching executor will automatically retrieve and use these values when deploying your branch. This allows you to maintain different configurations for different branches while keeping sensitive information secure.
+
+## Configuration examples
+
+### Multi-environment setup
+
+Here's an example of a complete multi-environment configuration:
+
+```toml
+# Default configuration for all branches
+[api]
+enabled = true
+port = 54321
+schemas = ["public", "storage", "graphql_public"]
+
+[db]
+port = 54322
+pool_size = 10
+
+# Staging-specific configuration
+[remotes.staging]
+project_id = "staging-project-ref"
+
+[remotes.staging.api]
+max_rows = 1000
+
+[remotes.staging.db.seed]
+sql_paths = ["./seeds/staging.sql"]
+
+# Production-specific configuration
+[remotes.production]
+project_id = "prod-project-ref"
+
+[remotes.production.api]
+max_rows = 500
+
+[remotes.production.db]
+pool_size = 25
+```
+
+### Feature branch configuration
+
+For feature branches that need specific settings:
+
+```toml
+[remotes.feature-oauth]
+project_id = "feature-branch-ref"
+
+[remotes.feature-oauth.auth.external.google]
+enabled = true
+client_id = "env(GOOGLE_CLIENT_ID)"
+secret = "env(GOOGLE_CLIENT_SECRET)"
+```
+
+## Next steps
+
+- Explore [branching integrations](/docs/guides/deployment/branching/integrations)
+- Learn about [troubleshooting branches](/docs/guides/deployment/branching/troubleshooting)
+- Review [branching pricing](/docs/guides/deployment/branching/pricing)