diff --git a/apps/docs/components/Navigation/NavigationMenu/NavigationMenu.constants.ts b/apps/docs/components/Navigation/NavigationMenu/NavigationMenu.constants.ts
index 13db7c5e8ca66..a0e9c1bacfde4 100644
--- a/apps/docs/components/Navigation/NavigationMenu/NavigationMenu.constants.ts
+++ b/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' },
],
},
{
diff --git a/apps/docs/content/guides/deployment/branching.mdx b/apps/docs/content/guides/deployment/branching.mdx
index bd71401941450..dafdb4d0c3714 100644
--- a/apps/docs/content/guides/deployment/branching.mdx
+++ b/apps/docs/content/guides/deployment/branching.mdx
@@ -1,772 +1,16 @@
---
title: 'Branching'
-description: 'Use Supabase Branches to test and preview changes.'
subtitle: 'Use Supabase Branches to test and preview changes'
---
Use branching to safely experiment with changes to your Supabase project.
-Supabase branches work like Git branches. They let you create and test changes like new configurations, database schemas, or features in a separate, temporary instance without affecting your production setup.
-
-When you're ready to ship your changes, merge your branch to update your production instance with the new changes.
-
-If you understand Git, you already understand Supabase Branching.
+Supabase branches create separate environments that spin off from your main project. You can use these branching environments to create and test changes like new configurations, database schemas, or features without affecting your production setup. When you're ready to ship your changes, merge your branch to update your production instance with the new changes.
## How branching works
- **Separate Environments**: Each branch is a separate environment with its own Supabase instance and API credentials.
-- **Git Integration**: Branching works with Git, currently supporting GitHub repositories.
- **Preview Branches**: You can create multiple Preview Branches for testing.
-- **Migrations and Seeding**: Branches run migrations from your repository and can seed data using a `seed.sql` file.
-
-## Prerequisites
-
-- **Supabase Project**: You need an existing Supabase project.
-- **GitHub Repository**: Your project must be connected to a GitHub repository containing your Supabase directory.
-
-You can run multiple Preview Branches for every Supabase project. Branches contain all the Supabase features with their own API credentials.
-
-Preview Environments auto-pause after branching.inactivity_period_in_minutes minutes of inactivity. Upon receiving a new request to your database or REST API, the paused branch will automatically resume to serve the request. The implications of this architecture means
-
-- `pg_cron` jobs will not execute in an auto-paused database.
-- Larger variance in request latency due to database cold starts.
-
-If you need higher performance guarantees on your Preview Environment, you can switch individual branches to [persistent](/docs/guides/deployment/branching#persistent-branches) so they are not auto-paused.
-
-
-
-### Branching workflow
-
-Preview Branch instances contain no data by default. You must include a seed file to seed your preview instance with sample data when the Preview Branch is created. Future versions of Branching may allow for automated data seeding and cloning after we are confident that we can provide safe data masking.
-
-## Git providers
-
-To manage code changes, your Supabase project must be connected to a Git repository. At this stage, we only support [GitHub](#branching-with-github). If you are interested in other Git providers, join the [discussion](https://github.com/orgs/supabase/discussions/18936) for GitLab, Bitbucket, and non-Git based Branching.
-
-### Branching with GitHub
-
-Supabase Branching uses the Supabase GitHub integration to read files from your GitHub repository. With this integration, Supabase watches all commits, branches, and pull requests of your GitHub repository.
-
-You can create a corresponding Preview Branch for any Git branch in your repository. Each time a new Preview Branch is created and configured based on the [`config.toml`](/docs/guides/local-development/cli/config) configuration on this branch, the migrations from the corresponding Git branch are run on the Preview Branch.
-
-The Preview Branch is also [seeded](/docs/guides/local-development/seeding-your-database) with sample data based on `./supabase/seed.sql` by default, if that file exists.
-
-Supabase Branching follows the [Trunk Based Development](https://trunkbaseddevelopment.com/) workflow, with one main Production branch and multiple development branches:
-
-
-
-When you merge your Git branch into the production branch, all new migrations will be applied to your Production environment. If you have declared Storage buckets or Edge Functions in `config.toml`, they will also be deployed automatically. All other configurations, including API, Auth, and seed files, will be ignored by default.
-
-
-
-### Preparing your Git repository
-
-You can use the [Supabase CLI](/docs/guides/cli) to manage changes inside a local `./supabase` directory:
-
-
-
-
-
-
-
-
- If you don't have a `./supabase` directory, you can create one:
-
- ```markdown
- supabase init
- ```
-
-
-
-
-
-
-
- Pull your database changes using `supabase db pull`. To get your database connection string, go to your project dashboard, click [Connect](https://supabase.com/dashboard/project/_?showConnect=true) and look for the Session pooler connection string.
-
- ```markdown
- supabase db pull --db-url
-
- # Your Database connection string will look like this:
- # postgres://postgres.xxxx:password@xxxx.pooler.supabase.com:6543/postgres
- ```
-
-
- If you're in an [IPv6 environment](https://github.com/orgs/supabase/discussions/27034) or have the IPv4 Add-On, you can use the direct connection string instead of Supavisor in Session mode.
-
-
-
-
-
-
-
-
-
- Commit the `supabase` directory to Git, and push your changes to your remote repository.
-
- ```bash
- git add supabase
- git commit -m "Initial migration"
- git push
- ```
-
-
-
-
-
-
-
-
-
-
-Use the Next.js example template to try out branching. This template includes sample migration and seed files to get you started. Run the following command in your terminal to clone the example:
-
-```bash
-npx create-next-app -e with-supabase
-```
-
-Push your new project to a GitHub repo. For more information, see the GitHub guides on [creating](https://docs.github.com/en/get-started/quickstart/create-a-repo) and [pushing code](https://docs.github.com/en/get-started/using-git/pushing-commits-to-a-remote-repository) to a new repository.
-
-
-
-
-### Enable Supabase branching
-
-Once your repository is [correctly prepared](#preparing-your-git-repository), you can enable branching from the Supabase dashboard.
-
-
-
-If your repository doesn't have all the migration files, your production branch could run an incomplete set of migrations. Make sure your [GitHub repository is prepared](#preparing-your-git-repository).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- When clicking `Enable branching` you will see the following dialog:
-
-
-
-
-
- If you don't have the GitHub integration installed, click `Add new project connection`. The integration is required to run migration files and the optional database seed file.
-
- You're taken to the GitHub integration page. Click `Install`.
-
-
-
-
-
- Follow the instructions to link your Supabase project to its GitHub repository.
-
-
-
-
-
- Return to your project and re-click `Enable branching`.
-
-
-
-
-
-
-
- Type in the branch you want to use for production. The name of the branch will be validated to make sure it exists in your GitHub repository.
-
-
-
- To change your production branch, you need to disable branching and re-enable it with a different branch.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-### Open a pull request
-
-When you open a pull request on GitHub, the Supabase integration automatically checks for a matching preview branch. If one doesn't exist, it gets created.
-
-A comment is added to your PR with the deployment status of your preview branch. Statuses are shown separately for Database, Services, and APIs.
-
-
-
-Every time a new commit is pushed that changes the migration files in `./supabase/migrations`, the new migrations are run against the preview branch. You can check the status of these runs in the comment's Tasks table.
-
-### Preventing migration failures
-
-We highly recommend turning on a 'required check' for the Supabase integration. You can do this from your GitHub repository settings. This prevents PRs from being merged when migration checks fail, and stops invalid migrations from being merged into your production branch.
-
-
-
-### Manually create a preview branch
-
-Preview branches are automatically created for each pull request, but you can also manually create one.
-
-
-
-
-
- You need at least one other branch aside from your Supabase production branch.
-
-
-
- You can use the GitHub dashboard or command line to create a new branch. In this example, the new branch is called `feat/add-members`.
-
-
-
-
-
-
- In the Supabase dashboard, look for the branch dropdown on the right-hand side of the top bar. It should be set to your production branch by default. Open the dropdown and click [`Manage branches`](/dashboard/project/_/branches).
-
-
-
-
-
-
-
-
-
-
-
- Click `Create preview branch`.
-
-
-
-
-
- Type in the branch name you want to add. Click `Create branch` to confirm.
-
-
-
- Git branches from external contributors currently can't support a Preview Branch
-
-
-
-
-
-
-
-
-
-
-
-
-The Git integration watches for changes in the `supabase` directory. This includes:
-
-- All SQL migration files, under the subdirectory `migrations`
-- An optional `seed.sql` file, used to seed preview instances with sample data
-
-You can create new migrations either [locally](#develop-locally) or [remotely](#develop-remotely). Local development is recommended.
-
-
-
-
-The Supabase CLI provides two options: [manual migrations](https://supabase.com/docs/guides/deployment/database-migrations) and [generated migrations](https://supabase.com/docs/guides/deployment/database-migrations#diffing-changes) using Supabase's local studio and the `supabase db-diff` command. Let's use the latter and push the change to our Preview Branch:
-
-
-
-
-
-
- Start Supabase locally:
-
- ```bash
- supabase start
- ```
-
- Then proceed to [localhost:54323](http://localhost:54323) to access your local Supabase dashboard.
-
- You can make changes in either the [Table Editor](http://localhost:54323/project/default/editor) or the [SQL Editor]((http://localhost:54323/project/default/sql)).
-
-
-
-
-
-
-
- Once you are finished making database changes, run `supabase db diff` to create a new migration file. For example:
-
- ```bash
- supabase db diff -f "add_employees_table"
- ```
-
- This will create a SQL file called `./supabase/migrations/[timestamp]add_employees_table.sql`. This file will reflect the changes that you made in your local dashboard.
-
- If you want to continue making changes, you can manually edit this migration file, then use the `db reset` command to pick up your edits:
-
- ```bash
- supabase db reset
- ```
-
- This will reset the database and run all the migrations again. The local dashboard at [localhost:54323](http://localhost:54323) will reflect the new changes you made.
-
-
-
-
-
-
-
- Commit and push your migration file to your remote GitHub repository. For example:
-
- ```bash
- git add supabase/migrations
- git commit -m "Add employees table"
- git push --set-upstream origin new-employee
- ```
-
- The Supabase integration detects the new migration and runs it on the remote Preview Branch. It can take up to 10 minutes for migrations to be applied. If you have a PR for your branch, errors are reflected in the GitHub check run status and in a PR comment.
-
- If you need to reset your database to a clean state (that is, discard any changes that aren't reflected in the migration files), run `supabase db reset` locally. Then, delete the preview branch and recreate it by closing, and reopening your pull request.
-
-
-
-
-
-
-
-
-
-
-
-As an alternative to developing locally, you can make changes on your remote Supabase dashboard. You can then pull these changes to your local machine and commit them to GitHub.
-
-
-
-Dashboard changes aren't automatically reflected in your Git repository. If you'd like to see automatic syncing in a future release, [join the discussion](https://github.com/orgs/supabase/discussions/18937).
-
-
-
-
-
-
-
- Select the branch you wish to use in your Supabase [project](https://supabase.com/dashboard/project/_).
-
-
-
-
-
-
-
-
-
-
-
- Make changes to your schema with either the [Table Editor](https://supabase.com/dashboard/project/_/editor) or the [SQL Editor]((https://supabase.com/dashboard/project/_/sql)).
-
-
-
-
-
-
-
- If you don't know the password, you must reset the database password so you know the password. Go to the [database setting page](https://supabase.com/dashboard/project/_/settings/database) and click `Reset database password`.
-
- Save the new password securely for future use.
-
-
-
-
-
-
-
- In your local terminal, navigate to the directory for your Supabase project and use the Supabase CLI to pull changes from your branch to your local migrations directory.
-
- Make sure to use the database URL for your branch:
-
- ```bash
- supabase db pull --db-url "postgres://postgres.xxxx:password@xxxx.pooler.supabase.com:6543/postgres"
- ```
-
-
-
-
-
-
-
- No new migrations will be run on your remote Preview Branch after pushing your changes. This is expected, because your database is already up-to-date, based on the changes you made in the dashboard. But this ensures that your migration files are in GitHub, so they can be correctly merged into production.
-
-
-
-
-
-
-
-
-
-### Disable branching
-
-You can disable branching at any time. Navigate to the [Branches](/dashboard/project/_/branches) page, which can be found via the Branches dropdown menu on the top navigation, then click "Manage Branches" in the menu. Click the 'Disable branching' button at the top of the Overview section.
-
-### Persistent branches
-
-Persistent branches are the type of branches that will remain active even after the underlying PR is closed. Any PR based on a persistent branch will also have a corresponding preview branch created automatically.
-
-You can change any branch to be persistent on the [Branches](/dashboard/project/_/branches) page by clicking the triple dots icon next to the branch you want to modify, and selecting "Switch to persistent".
-
-All persistent branches can be toggled back to be an ephemeral branch in the exact same way.
-
-## Migration and seeding behavior
-
-Migrations are run in sequential order. Each migration builds upon the previous one.
-
-The preview branch has a record of which migrations have been applied, and only applies new migrations for each commit. This can create an issue when rolling back migrations.
-
-### Using ORM or custom seed scripts
-
-If you want to use your own ORM for managing migrations and seed scripts, you will need to run them in GitHub Actions after the preview branch is ready. The branch credentials can be fetched using the following example GHA workflow.
-
-```yaml
-on:
- pull_request:
- types:
- - opened
- - reopened
- - synchronize
- branches:
- - main
- paths:
- - 'supabase/**'
-
-jobs:
- wait:
- runs-on: ubuntu-latest
- outputs:
- status: ${{ steps.check.outputs.conclusion }}
- steps:
- - uses: fountainhead/action-wait-for-check@v1.2.0
- id: check
- with:
- checkName: Supabase Preview
- ref: ${{ github.event.pull_request.head.sha }}
- token: ${{ secrets.GITHUB_TOKEN }}
-
- migrate:
- needs:
- - wait
- if: ${{ needs.wait.outputs.status == 'success' }}
- runs-on: ubuntu-latest
- steps:
- - uses: supabase/setup-cli@v1
- with:
- version: latest
- - run: supabase --experimental branches get "$GITHUB_HEAD_REF" -o env >> $GITHUB_ENV
- - name: Custom ORM migration
- run: psql "$POSTGRES_URL_NON_POOLING" -c 'select 1'
-```
-
-## 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)"
-```
-
-
-
-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.
-
-
-
-#### 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 "" -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:"
-```
-
-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)"
-```
-
-
-
-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.
-
-
-
-##### 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.
-
-### Rolling back migrations
-
-You might want to roll back changes you've made in an earlier migration change. For example, you may have pushed a migration file containing schema changes you no longer want.
-
-To fix this, push the latest changes, then delete the preview branch in Supabase and reopen it.
-
-The new preview branch is reseeded from the `./supabase/seed.sql` file by default. Any additional data changes made on the old preview branch are lost. This is equivalent to running `supabase db reset` locally. All migrations are rerun in sequential order.
-
-### Seeding behavior
-
-Your Preview Branches are seeded with sample data using the same as [local seeding behavior](/docs/guides/local-development/seeding-your-database).
-
-The database is only seeded once, when the preview branch is created. To rerun seeding, delete the preview branch and recreate it by closing, and reopening your pull request.
-
-## Branching and hosting providers
-
-Branching works with hosting providers that support preview deployments.
-
-With the Supabase branching integration, you can sync the Git branch used by the hosting provider with the corresponding Supabase preview branch. This means that the preview deployment built by your hosting provider is matched to the correct database schema, edge functions, and other Supabase configurations.
-
-### Vercel
-
-Install the Vercel integration:
-
-- From the [Vercel marketplace](https://vercel.com/integrations/supabase) or
-- By clicking the blue `Deploy` button in a Supabase example app's `README` file
-
-
-
-For branching to work with Vercel, you also need the [Vercel GitHub integration](https://vercel.com/docs/deployments/git/vercel-for-github).
-
-
-
-And make sure you have [connected](/dashboard/org/_/integrations) your Supabase project to your Vercel project.
-
-Supabase automatically updates your Vercel project with the correct environment variables for the corresponding preview branches. The synchronization happens at the time of Pull Request being opened, not at the time of branch creation.
-
-As branching integration is tied to the Preview Deployments feature in Vercel, there are possible race conditions between Supabase setting correct variables, and Vercel running a deployment process. Because of that, Supabase is always automatically re-deploying the most recent deployment of the given pull request.
-
-## Other Git providers
-
-There are multiple alternative Git providers under consideration. If you're interested in branching for GitLab, Bitbucket, or some other provider, [join the GitHub discussion](https://github.com/orgs/supabase/discussions/18938).
-
-## Alternatives to branching
-
-Under the hood, you can see Supabase branching as a way to programmatically "duplicate" your Supabase project via git flow. This allows spawning a new configured (via [`config.toml`](/docs/guides/local-development/cli/config)) and seeded instance of the database and the adjacent Supabase services (buckets, edge functions, etc.).
-
-1. A new project is deployed on behalf of the user on the Supabase side as the new "branch" if it doesn't already exist. This includes the database, storage, edge-function, and all Supabase-related services.
-2. The branch is cloned and the new project is configured based on the [`config.toml`](/docs/guides/local-development/cli/config) committed into this project branch.
-3. Migrations are applied and seeding scripts are run (the first time) for this branch.
-
-You can make a similar setup with a distinct project for each environment. Or just have two environments, the localhost and the production one.
-
-## Pricing
-
-Branching is available on the Pro Plan and above. The price is:
-
-- Each Preview branch costs per hour
-- Each Preview branch is billed until it is removed
-
-## Troubleshooting
-
-### Rolling back migrations
-
-You might want to roll back changes you've made in an earlier migration change. For example, you may have pushed a migration file containing schema changes you no longer want.
-
-To fix this, push the latest changes, then delete the preview branch in Supabase and reopen it.
-
-The new preview branch is reseeded from the `./supabase/seed.sql` file by default. Any additional data changes made on the old preview branch are lost. This is equivalent to running `supabase db reset` locally. All migrations are rerun in sequential order.
-
-### Deployment failures
-
-A deployment might fail for various reasons, including invalid SQL statements and schema conflicts in migrations, errors within the `config.toml` config, or something else.
-
-To check the error message, see the Supabase workflow run for your branch under the [View logs](/dashboard/project/_/branches) section.
-
-### Network restrictions
-
-If you enable [network restrictions](/docs/guides/platform/network-restrictions) on your project, the branching cluster will be blocked from connecting to your project by default. This often results in database connection failures when migrating your production project after merging a development branch.
-
-The workaround is to explicitly allow the IPv6 CIDR range of the branching cluster in your project's [database settings](https://supabase.com/dashboard/project/_/settings/database) page: `2600:1f18:2b7d:f600::/56`
-
-
-
-### Schema drift between preview branches
-
-If multiple preview branches exist, each preview branch might contain different schema changes. This is similar to Git branches, where each branch might contain different code changes.
-
-When a preview branch is merged into the production branch, it creates a schema drift between the production branch and the preview branches that haven't been merged yet.
-
-These conflicts can be resolved in the same way as normal Git Conflicts: merge or rebase from the production Git branch to the preview Git branch. Since migrations are applied sequentially, ensure that migration files are timestamped correctly after the rebase. Changes that build on top of earlier changes should always have later timestamps.
-
-### Changing production branch
-
-It's not possible to change the Git branch used as the Production branch for Supabase Branching. The only way to change it is to disable and re-enable branching. See [Disable Branching](#disable-branching).
-
-## Feedback
-
-Supabase branching is a new and exciting part of the Supabase development ecosystem. Feedback is welcome.
-
-You can join the [conversation over in GitHub discussions](https://github.com/orgs/supabase/discussions/18937).
+- **Persistent Branches**: Persistent branches are long-lived branches. They aren't automatically paused or deleted due to non-inactivity or merging.
+- **GitHub integration and Branching 2.0**: You can use branching with the GitHub integration, or use Branching 2.0 to manage your branches without Git (in Feature Preview).
+- **Data-less**: New branches do not start with any data from your main project. This is meant to better protect your sensitive production data. To start your branches with data, you can use a [seed file](/docs/guides/deployment/branching/github-integration#seeding) if using the GitHub integration.
diff --git a/apps/docs/content/guides/deployment/branching/branching-2.mdx b/apps/docs/content/guides/deployment/branching/branching-2.mdx
new file mode 100644
index 0000000000000..06ff6b67a8c35
--- /dev/null
+++ b/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.
+
+
+
+Branching 2.0 is currently in public alpha. Features and functionality may change.
+
+
+
+## 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
diff --git a/apps/docs/content/guides/deployment/branching/configuration.mdx b/apps/docs/content/guides/deployment/branching/configuration.mdx
new file mode 100644
index 0000000000000..5355264fff2ac
--- /dev/null
+++ b/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)"
+```
+
+
+
+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.
+
+
+
+### 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 "" -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:"
+```
+
+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)"
+```
+
+
+
+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.
+
+
+
+#### 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)
diff --git a/apps/docs/content/guides/deployment/branching/github-integration.mdx b/apps/docs/content/guides/deployment/branching/github-integration.mdx
new file mode 100644
index 0000000000000..661730e0521c0
--- /dev/null
+++ b/apps/docs/content/guides/deployment/branching/github-integration.mdx
@@ -0,0 +1,102 @@
+---
+title: 'GitHub integration'
+subtitle: 'Connect with GitHub to sync branches with your repository'
+---
+
+Supabase Branching uses the Supabase GitHub integration to read files from your GitHub repository. With this integration, Supabase watches all commits, branches, and pull requests of your GitHub repository.
+
+## Installation
+
+In the Supabase Dashboard:
+
+1. Go to **Project Settings** > [**Integrations**](/dashboard/project/_/settings/integrations).
+2. Under **GitHub Integration**, click **Authorize GitHub**.
+3. You are redirected to a GitHub authorization page. Click **Authorize Supabase**.
+4. You are redirected back to the Integrations page. Choose a GitHub repository to connect your project to.
+5. Fill in the relative path to the Supabase directory from your repository root.
+6. Configure the other options as needed to automate your GitHub connection.
+7. Click **Enable integration**.
+
+## Syncing GitHub branches
+
+Enable the **Automatic branching** option in your GitHub Integration configuration to automatically sync GitHub branches with Supabase branches.
+
+When a new branch is created in GitHub, a corresponding branch is created in Supabase. (You can enable the **Supabase changes only** option to only create Supabase branches when Supabase files change.)
+
+### Configuration
+
+You can test configuration changes on your Preview Branch by configuring the `config.toml` file in your Supabase directory. See the [Configuration docs](/docs/guides/deployment/branching/configuration) for more information.
+
+A comment is added to your PR with the deployment status of your preview branch.
+
+### Migrations
+
+The migrations in the `migrations` subdirectory of your Supabase directory are automatically run.
+
+### Seeding
+
+No production data is copied to your Preview branch. This is meant to protect your sensitive production data.
+
+You can seed your Preview Branch with sample data using the `seed.sql` file in your Supabase directory. See the [Seeding docs](/docs/guides/local-development/seeding-your-database) for more information.
+
+Data changes in your seed files are not merged to production.
+
+## Deploying changes to production
+
+Enable the **Deploy to production** option in your GitHub Integration configuration to automatically deploy changes when you push or merge to production branch.
+
+The following changes are deployed:
+
+- New migrations are applied
+- Edge Functions declared in `config.toml` are deployed
+- Storage buckets declared in `config.toml` are deployed
+
+All other configurations, including API, Auth, and seed files, are ignored by default.
+
+## Preventing migration failures
+
+We highly recommend turning on a 'required check' for the Supabase integration. You can do this from your GitHub repository settings. This prevents PRs from being merged when migration checks fail, and stops invalid migrations from being merged into your production branch.
+
+
+
+### Email notifications
+
+To catch failures early, we also recommend subscribing to email notifications on your branch. Common errors include migration conflict, function deployment failure, or invalid configuration file.
+
+You can setup a custom GitHub Action to monitor the status of any Supabase Branch.
+
+```yaml name=.github/workflows/notify-failure.yaml
+name: Branch Status
+
+on:
+ pull_request:
+ types:
+ - opened
+ - reopened
+ - synchronize
+ branches:
+ - main
+ - develop
+ paths:
+ - 'supabase/**'
+
+jobs:
+ failed:
+ runs-on: ubuntu-latest
+ steps:
+ - uses: fountainhead/action-wait-for-check@v1.2.0
+ id: check
+ with:
+ checkName: Supabase Preview
+ ref: ${{ github.event.pull_request.head.sha || github.sha }}
+ token: ${{ secrets.GITHUB_TOKEN }}
+
+ - if: ${{ steps.check.outputs.conclusion == 'failure' }}
+ run: exit 1
+```
diff --git a/apps/docs/content/guides/deployment/branching/integrations.mdx b/apps/docs/content/guides/deployment/branching/integrations.mdx
new file mode 100644
index 0000000000000..e1d89e75a9bbf
--- /dev/null
+++ b/apps/docs/content/guides/deployment/branching/integrations.mdx
@@ -0,0 +1,30 @@
+---
+title: 'Integrations'
+description: 'Use Supabase branching with hosting providers and other tools.'
+subtitle: 'Use Supabase branching with hosting providers and other tools'
+---
+
+Branching works with hosting providers that support preview deployments. Learn how to integrate Supabase branching with various platforms and tools.
+
+## Hosting providers
+
+With the Supabase branching integration, you can sync the Git branch used by the hosting provider with the corresponding Supabase preview branch. This means that the preview deployment built by your hosting provider is matched to the correct database schema, edge functions, and other Supabase configurations.
+
+### Vercel
+
+Install the Vercel integration:
+
+- From the [Vercel marketplace](https://vercel.com/integrations/supabase) or
+- By clicking the blue `Deploy` button in a Supabase example app's `README` file
+
+
+
+For branching to work with Vercel, you also need the [Vercel GitHub integration](https://vercel.com/docs/deployments/git/vercel-for-github).
+
+
+
+And make sure you have [connected](/dashboard/org/_/integrations) your Supabase project to your Vercel project.
+
+Supabase automatically updates your Vercel project with the correct environment variables for the corresponding preview branches. The synchronization happens at the time of Pull Request being opened, not at the time of branch creation.
+
+As branching integration is tied to the Preview Deployments feature in Vercel, there are possible race conditions between Supabase setting correct variables, and Vercel running a deployment process. Because of that, Supabase is always automatically re-deploying the most recent deployment of the given pull request.
diff --git a/apps/docs/content/guides/deployment/branching/troubleshooting.mdx b/apps/docs/content/guides/deployment/branching/troubleshooting.mdx
new file mode 100644
index 0000000000000..a5c2a2f23620d
--- /dev/null
+++ b/apps/docs/content/guides/deployment/branching/troubleshooting.mdx
@@ -0,0 +1,169 @@
+---
+title: 'Troubleshooting'
+description: 'Common issues and solutions for Supabase branching.'
+subtitle: 'Common issues and solutions for Supabase branching'
+---
+
+This guide covers common issues you might encounter when using Supabase branching and how to resolve them.
+
+## Common issues
+
+### Rolling back migrations
+
+You might want to roll back changes you've made in an earlier migration change. For example, you may have pushed a migration file containing schema changes you no longer want.
+
+To fix this, push the latest changes, then delete the preview branch in Supabase and reopen it.
+
+The new preview branch is reseeded from the `./supabase/seed.sql` file by default. Any additional data changes made on the old preview branch are lost. This is equivalent to running `supabase db reset` locally. All migrations are rerun in sequential order.
+
+### Deployment failures
+
+A deployment might fail for various reasons, including invalid SQL statements and schema conflicts in migrations, errors within the `config.toml` config, or something else.
+
+To check the error message, see the Supabase workflow run for your branch under the [View logs](/dashboard/project/_/branches) section.
+
+### Network restrictions
+
+If you enable [network restrictions](/docs/guides/platform/network-restrictions) on your project, the branching cluster will be blocked from connecting to your project by default. This often results in database connection failures when migrating your production project after merging a development branch.
+
+The workaround is to explicitly allow the IPv6 CIDR range of the branching cluster in your project's [database settings](https://supabase.com/dashboard/project/_/settings/database) page: `2600:1f18:2b7d:f600::/56`
+
+
+
+### Schema drift between preview branches
+
+If multiple preview branches exist, each preview branch might contain different schema changes. This is similar to Git branches, where each branch might contain different code changes.
+
+When a preview branch is merged into the production branch, it creates a schema drift between the production branch and the preview branches that haven't been merged yet.
+
+These conflicts can be resolved in the same way as normal Git Conflicts: merge or rebase from the production Git branch to the preview Git branch. Since migrations are applied sequentially, ensure that migration files are timestamped correctly after the rebase. Changes that build on top of earlier changes should always have later timestamps.
+
+### Changing production branch
+
+It's not possible to change the Git branch used as the Production branch for Supabase Branching. The only way to change it is to disable and re-enable branching. See [Disable Branching](#disable-branching).
+
+## Migration issues
+
+### Failed migrations
+
+When migrations fail, check:
+
+1. **SQL syntax**: Ensure your migration files contain valid SQL
+2. **Dependencies**: Check if migrations depend on objects that don't exist
+3. **Permissions**: Verify the migration doesn't require superuser privileges
+
+To debug:
+
+```bash
+# Test migrations locally first
+supabase db reset
+
+# Check migration logs in the dashboard
+# Navigate to Branches > Your Branch > View Logs
+```
+
+### Migration order problems
+
+Migrations must run in the correct order. Common issues:
+
+1. **Timestamp conflicts**: Ensure migration files have unique timestamps
+2. **Dependency issues**: Later migrations depending on earlier ones
+3. **Rebase problems**: Timestamps getting out of order after Git rebase
+
+Fix by:
+
+```bash
+# Rename migration files to fix timestamp order
+mv 20240101000000_old.sql 20240102000000_old.sql
+
+# Reset local database to test
+supabase db reset
+```
+
+## Connection issues
+
+### Cannot connect to preview branch
+
+If you can't connect to a preview branch:
+
+1. **Check credentials**: Ensure you're using the correct branch-specific credentials
+2. **Auto-pause**: The branch might be paused. It will resume on the first request
+3. **Network restrictions**: Check if network restrictions are blocking access
+
+### Connection timeouts
+
+Preview branches auto-pause after inactivity. First connections after pause may timeout:
+
+1. **Retry**: The branch will wake up after the first request
+2. **Persistent branches**: Convert frequently-used branches to persistent
+
+## Configuration problems
+
+### Config.toml not applying
+
+If configuration changes aren't applying:
+
+1. **Syntax errors**: Validate your `config.toml` syntax
+2. **Git sync**: Ensure changes are committed and pushed
+3. **Branch refresh**: Try deleting and recreating the branch
+
+### Secrets not available
+
+If secrets aren't working in your branch:
+
+1. **Branch-specific**: Remember secrets are set per branch
+2. **Syntax**: Use correct syntax: `env(SECRET_NAME)`
+3. **CLI version**: Ensure you're using the latest CLI version
+
+## Performance issues
+
+### Slow branch creation
+
+Branch creation might be slow due to:
+
+1. **Large migrations**: Many or complex migration files
+2. **Seed data**: Large seed files take time to process
+3. **Network latency**: Geographic distance from the branch region
+
+### Query performance
+
+Preview branches may have different performance characteristics:
+
+1. **Cold starts**: First queries after auto-pause are slower
+2. **Resource limits**: Preview branches have different resource allocations
+3. **Indexing**: Ensure proper indexes exist in your migrations
+
+## Data issues
+
+### Seed data not loading
+
+If seed data isn't loading:
+
+1. **File location**: Ensure `seed.sql` is in `./supabase/` directory
+2. **SQL errors**: Check for syntax errors in seed file
+3. **Dependencies**: Seed data might reference non-existent tables
+
+### Data persistence
+
+Remember that preview branch data:
+
+1. **Is temporary**: Data is lost when branch is deleted
+2. **Isn't migrated**: Data doesn't move between branches
+3. **Resets on recreation**: Deleting and recreating branch loses data
+
+## Getting help
+
+If you're still experiencing issues:
+
+1. **Check logs**: Review branch logs in the dashboard
+2. **Community**: Ask in [GitHub discussions](https://github.com/orgs/supabase/discussions/18937)
+3. **Support**: Contact support for project-specific issues
+4. **Documentation**: Review the latest documentation for updates
diff --git a/apps/docs/content/guides/deployment/branching/working-with-branches.mdx b/apps/docs/content/guides/deployment/branching/working-with-branches.mdx
new file mode 100644
index 0000000000000..f04727d7504a2
--- /dev/null
+++ b/apps/docs/content/guides/deployment/branching/working-with-branches.mdx
@@ -0,0 +1,128 @@
+---
+title: 'Working with branches'
+description: 'Learn how to develop and manage your Supabase branches.'
+subtitle: 'Learn how to develop and manage your Supabase branches'
+---
+
+This guide covers how to work with Supabase branches effectively, including migration management, seeding behavior, and development workflows.
+
+## Migration and seeding behavior
+
+Migrations are run in sequential order. Each migration builds upon the previous one.
+
+The preview branch has a record of which migrations have been applied, and only applies new migrations for each commit. This can create an issue when rolling back migrations.
+
+### Using ORM or custom seed scripts
+
+If you want to use your own ORM for managing migrations and seed scripts, you will need to run them in GitHub Actions after the preview branch is ready. The branch credentials can be fetched using the following example GHA workflow.
+
+```yaml name=.github/workflows/custom-orm.yaml
+name: Custom ORM
+
+on:
+ pull_request:
+ types:
+ - opened
+ - reopened
+ - synchronize
+ branches:
+ - main
+ paths:
+ - 'supabase/**'
+
+jobs:
+ wait:
+ runs-on: ubuntu-latest
+ outputs:
+ status: ${{ steps.check.outputs.conclusion }}
+ steps:
+ - uses: fountainhead/action-wait-for-check@v1.2.0
+ id: check
+ with:
+ checkName: Supabase Preview
+ ref: ${{ github.event.pull_request.head.sha || github.sha }}
+ token: ${{ secrets.GITHUB_TOKEN }}
+
+ migrate:
+ needs:
+ - wait
+ if: ${{ needs.wait.outputs.status == 'success' }}
+ runs-on: ubuntu-latest
+ steps:
+ - uses: supabase/setup-cli@v1
+ with:
+ version: latest
+ - run: supabase --experimental branches get "$GITHUB_HEAD_REF" -o env >> $GITHUB_ENV
+ - name: Custom ORM migration
+ run: psql "$POSTGRES_URL_NON_POOLING" -c 'select 1'
+```
+
+### Rolling back migrations
+
+You might want to roll back changes you've made in an earlier migration change. For example, you may have pushed a migration file containing schema changes you no longer want.
+
+To fix this, push the latest changes, then delete the preview branch in Supabase and reopen it.
+
+The new preview branch is reseeded from the `./supabase/seed.sql` file by default. Any additional data changes made on the old preview branch are lost. This is equivalent to running `supabase db reset` locally. All migrations are rerun in sequential order.
+
+### Seeding behavior
+
+Your Preview Branches are seeded with sample data using the same as [local seeding behavior](/docs/guides/local-development/seeding-your-database).
+
+The database is only seeded once, when the preview branch is created. To rerun seeding, delete the preview branch and recreate it by closing, and reopening your pull request.
+
+## Developing with branches
+
+You can develop with branches using either local or remote development workflows.
+
+### Local development workflow
+
+1. Create a new Git branch for your feature
+2. Make schema changes using the Supabase CLI
+3. Generate migration files with `supabase db diff`
+4. Test your changes locally
+5. Commit and push to GitHub
+6. Open a pull request to create a preview branch
+
+### Remote development workflow
+
+1. Create a preview branch in the Supabase dashboard
+2. Switch to the branch using the branch dropdown
+3. Make schema changes in the dashboard
+4. Pull changes locally using `supabase db pull`
+5. Commit the generated migration files
+6. Push to your Git repository
+
+## Managing branch environments
+
+### Switching between branches
+
+Use the branch dropdown in the Supabase dashboard to switch between different branches. Each branch has its own:
+
+- Database instance
+- API endpoints
+- Authentication settings
+- Storage buckets
+
+### Accessing branch credentials
+
+Each branch has unique credentials that you can find in the dashboard:
+
+1. Switch to your desired branch
+2. Navigate to Settings > API
+3. Copy the branch-specific URLs and keys
+
+### Branch isolation
+
+Branches are completely isolated from each other. Changes made in one branch don't affect others, including:
+
+- Database schema and data
+- Storage objects
+- Edge Functions
+- Auth configurations
+
+## Next steps
+
+- Learn about [branch configuration](/docs/guides/deployment/branching/configuration)
+- Explore [integrations](/docs/guides/deployment/branching/integrations)
+- Review [troubleshooting guide](/docs/guides/deployment/branching/troubleshooting)
diff --git a/apps/docs/content/guides/platform/org-mfa-enforcement.mdx b/apps/docs/content/guides/platform/mfa/org-mfa-enforcement.mdx
similarity index 93%
rename from apps/docs/content/guides/platform/org-mfa-enforcement.mdx
rename to apps/docs/content/guides/platform/mfa/org-mfa-enforcement.mdx
index 6f5a3b95bc942..3fd7a1ff4ec9f 100644
--- a/apps/docs/content/guides/platform/org-mfa-enforcement.mdx
+++ b/apps/docs/content/guides/platform/mfa/org-mfa-enforcement.mdx
@@ -9,8 +9,6 @@ Supabase provides multi-factor authentication (MFA) enforcement on the organizat
MFA enforcement is only available on the [Pro, Team and Enterprise plans](https://supabase.com/pricing).
-This feature is currently in limited preview. If you would like to opt-in to try it, contact support.
-
## Manage MFA enforcement
diff --git a/apps/docs/content/guides/realtime/authorization.mdx b/apps/docs/content/guides/realtime/authorization.mdx
index 3dce5b919f7bb..66c854efcb768 100644
--- a/apps/docs/content/guides/realtime/authorization.mdx
+++ b/apps/docs/content/guides/realtime/authorization.mdx
@@ -18,6 +18,12 @@ Realtime Authorization is in Public Beta. To use Authorization for your Realtime
+
+
+To enforce private channels you need to disable the 'Allow public access' setting in [Realtime Settings](https://supabase.com/dashboard/project/_?featurePreviewModal=supabase-ui-realtime-settings)
+
+
+
## How it works
Realtime uses the `messages` table in your database's `realtime` schema to generate access policies for your clients when they connect to a Channel topic.
diff --git a/apps/docs/content/guides/realtime/concepts.mdx b/apps/docs/content/guides/realtime/concepts.mdx
index 867a53f4a05dc..79ea841817d6e 100644
--- a/apps/docs/content/guides/realtime/concepts.mdx
+++ b/apps/docs/content/guides/realtime/concepts.mdx
@@ -26,6 +26,18 @@ const supabase = createClient('https://.supabase.co', ''
const roomOne = supabase.channel('room-one') // set your topic here
```
+## Authorization
+
+Authorization is done via RLS policies against the table `realtime.messages` which will determine if a user can connect to a Channel and if they are allowed to send messages to a Channel.
+
+By default, channels are public and you need to set that you want to use a private channel.
+
+```js
+import { createClient } from '@supabase/supabase-js'
+const supabase = createClient('https://.supabase.co', '')
+const roomOne = supabase.channel('private-room-one', { config: { private: true } })
+```
+
## Broadcast
Realtime Broadcast follows the [publish-subscribe pattern](https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern) where a client publishes messages to a channel based on a unique topic. For example, a user could send a message to a channel with topic `room-one`.
@@ -45,6 +57,8 @@ roomOne.send({
Other clients can receive the message in real-time by subscribing to the Channel with topic `room-one`. These clients continue to receive messages as long as they are subscribed and connected to the same Channel topic.
+You can also use [Broadcast using the REST API](/docs/guides/realtime/broad cast#broadcast-using-the-rest-api) and [Broadcast using the Database](/docs/guides/realtime/broadcast#broadcast-using-the-database) to send messages to a Channel which allows you to do more advanced use-cases.
+
An example use-case is sharing a user's cursor position with other clients in an online game.
## Presence
@@ -93,6 +107,36 @@ Anyone with access to a valid JWT signed with the project's JWT secret is able t
Clients can choose to receive `INSERT`, `UPDATE`, `DELETE`, or `*` (all) changes for all changes in a schema, a table in a schema, or a column's value in a table. Your clients should only listen to tables in the `public` schema and you must first enable the tables you want your clients to listen to.
+## Settings
+
+
+
+Realtime settings are currently under Feature Preview section in the dashboard.
+
+
+
+
+
+You can set the following settings using the Realtime Settings screen in your Dashboard:
+
+- Channel Restrictions: You can toggle this settings to set Realtime to allow public channels or set it to use only private channels with [Realtime Authorization](/docs/content/guides/realtime/authorization).
+- Database connection pool size: Determines the number of connections used for Realtime Authorization RLS checking
+ {/* supa-mdx-lint-disable-next-line Rule004ExcludeWords */}
+- Max concurrent clients: Determines the maximum number of clients that can be connected
+
+All changes made in this screen will disconnect all your connected clients to ensure Realtime starts with the appropriate settings and all changes are stored in Supabase middleware.
+
+## Choosing between Broadcast and Postgres Changes for database changes
+
+We recommend using Broadcast by default and using Broadcast from Database specifically as it will allow you to scale your application compared to Postgres Changes.
+
## Choosing between Broadcast and Presence
We recommend using Broadcast by default, and then Presence when required. Presence utilizes an in-memory conflict-free replicated data type (CRDT) to track and synchronize shared state in an eventually consistent manner. It computes the difference between existing state and new state changes and sends the necessary updates to clients via Broadcast. This is computationally heavy, so you should use it sparingly. If you use Presence, it's best to throttle your changes so that you are sending updates less frequently.
diff --git a/apps/docs/content/guides/security.mdx b/apps/docs/content/guides/security.mdx
index 6d7e4cb7356c3..f798002bb9cd7 100644
--- a/apps/docs/content/guides/security.mdx
+++ b/apps/docs/content/guides/security.mdx
@@ -17,6 +17,12 @@ The [HIPAA Compliance Guide](/docs/guides/security/hipaa-compliance) explains Su
# Platform configuration
+As a hosted platform, Supabase provides additional security controls to further enhance the security posture depending on organizations' own requirements or obligations.
+
+These can be found under the [dedicated security page](https://supabase.com/dashboard/org/_/security) under organization settings. And are described in greater detail [here](/docs/guides/security/platform-security).
+
+# Product configuration
+
Each product offered by Supabase comes with customizable security controls and these security controls help ensure that applications built on Supabase are secure, compliant, and resilient against various threats.
The [security configuration guides](/docs/guides/security/product-security) provide detailed information for configuring individual products.
diff --git a/apps/docs/content/guides/security/platform-security.mdx b/apps/docs/content/guides/security/platform-security.mdx
new file mode 100644
index 0000000000000..8fee881ff3f2a
--- /dev/null
+++ b/apps/docs/content/guides/security/platform-security.mdx
@@ -0,0 +1,66 @@
+---
+id: 'platform-security'
+title: 'Secure configuration of Supabase platform'
+description: 'Supabase provides a secure yet flexible platform. Here is how to adjust various security settings across the platform.'
+---
+
+The Supabase hosted platform provides a secure by default configuration. Some organizations may however require further security controls to meet their own security policies or compliance requirements.
+
+Access to additional security controls can be found under the [security tab](https://supabase.com/dashboard/org/_/security) for organizations.
+
+## Available controls
+
+
+
+Additional security controls are under active development. Any changes will be published here and
+in our [changelog](https://supabase.com/changelog).
+
+
+
+### Enforce multi-factor authentication (MFA)
+
+Organization owners can choose to enforce MFA for all team members.
+
+For configuration information, see [Enforce MFA on Organization](/docs/guides/platform/mfa/org-mfa-enforcement)
+
+### SSO for organizations
+
+Supabase offers single sign-on (SSO) as a login option to provide additional account security for your team. This allows company administrators to enforce the use of an identity provider when logging into Supabase.
+
+For configuration information, see [Enable SSO for Your Organization](/docs/guides/platform/sso).
+
+### Postgres SSL enforcement
+
+Supabase projects support connecting to the Postgres DB without SSL enforced to maximize client compatibility. For increased security, you can prevent clients from connecting if they're not using SSL.
+
+For configuration information, see [Postgres SSL Enforcement](/docs/guides/platform/ssl-enforcement)
+
+
+
+ Controlling this at the organization level is on our roadmap.
+
+
+
+### Network restrictions
+
+Each Supabase project comes with configurable restrictions on the IP ranges that are allowed to connect to Postgres and its pooler ("your database"). These restrictions are enforced before traffic reaches the database. If a connection is not restricted by IP, it still needs to authenticate successfully with valid database credentials.
+
+For configuration information, see [Network Restrictions](/docs/guides/platform/network-restrictions)
+
+
+
+ Controlling this at the organization level is on our roadmap.
+
+
+
+### PrivateLink
+
+PrivateLink provides enterprise-grade private network connectivity between your AWS VPC and your Supabase database using AWS VPC Lattice. This eliminates exposure to the public internet by creating a secure, private connection that keeps your database traffic within the AWS network backbone.
+
+For configuration information, see [PrivateLink](/docs/guides/platform/privatelink)
+
+
+
+PrivateLink is currently in alpha and available exclusively to Enterprise customers.
+
+
diff --git a/apps/docs/content/guides/security/product-security.mdx b/apps/docs/content/guides/security/product-security.mdx
index 006d56583748e..2c46fe215b4dd 100644
--- a/apps/docs/content/guides/security/product-security.mdx
+++ b/apps/docs/content/guides/security/product-security.mdx
@@ -1,7 +1,7 @@
---
id: 'product-security'
title: 'Secure configuration of Supabase products'
-description: 'Supabase provides a secure yet flexible platform. Here is how to adjust various security settings across the platform.'
+description: 'Supabase provides a secure yet flexible set of products. Here is how to adjust various security settings across the various products.'
---
The Supabase [production checklist](/docs/guides/deployment/going-into-prod) provides detailed advice on preparing an app for production. While our [SOC 2](/docs/guides/security/soc-2-compliance) and [HIPAA](/docs/guides/security/hipaa-compliance) compliance documents outline the roles and responsibilities for building a secure and compliant app.
diff --git a/apps/docs/public/img/guides/platform/realtime-settings--dark.png b/apps/docs/public/img/guides/platform/realtime-settings--dark.png
new file mode 100644
index 0000000000000..b9ee8747b559b
Binary files /dev/null and b/apps/docs/public/img/guides/platform/realtime-settings--dark.png differ
diff --git a/apps/docs/public/img/guides/platform/realtime-settings--light.png b/apps/docs/public/img/guides/platform/realtime-settings--light.png
new file mode 100644
index 0000000000000..3587df9ebd2c2
Binary files /dev/null and b/apps/docs/public/img/guides/platform/realtime-settings--light.png differ
diff --git a/apps/studio/components/interfaces/Advisors/AdvisorRuleItem.tsx b/apps/studio/components/interfaces/Advisors/AdvisorRuleItem.tsx
index ac42d836fe4b2..47cb816ab3836 100644
--- a/apps/studio/components/interfaces/Advisors/AdvisorRuleItem.tsx
+++ b/apps/studio/components/interfaces/Advisors/AdvisorRuleItem.tsx
@@ -11,6 +11,7 @@ import { useProjectLintRulesQuery } from 'data/lint/lint-rules-query'
import { useOrganizationMembersQuery } from 'data/organizations/organization-members-query'
import { useSelectedOrganization } from 'hooks/misc/useSelectedOrganization'
import {
+ Badge,
Button,
Card,
CardContent,
@@ -24,11 +25,19 @@ import ConfirmationModal from 'ui-patterns/Dialogs/ConfirmationModal'
import { LintInfo } from '../Linter/Linter.constants'
import { generateRuleText } from './AdvisorRules.utils'
import { CreateRuleSheet } from './CreateRuleSheet'
+import { DisableRuleModal } from './DisableRuleModal'
+import { EnableRuleModal } from './EnableRuleModal'
interface AdvisorRuleItemProps {
lint: LintInfo
}
+// [Joshen] Context: We're going with a simplified interface for LW15 as we launch
+// this as a feature preview. Going to be purely disabling rules for the whole project,
+// not assigning to members, etc (all these can come in the future when we're ready)
+// Hence using this to clearly indicate where is being simplified
+const SIMPLIFIED_INTERFACE = true
+
export const AdvisorRuleItem = ({ lint }: AdvisorRuleItemProps) => {
const { ref: projectRef } = useParams()
const organization = useSelectedOrganization()
@@ -63,6 +72,30 @@ export const AdvisorRuleItem = ({ lint }: AdvisorRuleItemProps) => {
deleteRule({ projectRef, ids: [selectedRuleToDelete] })
}
+ if (SIMPLIFIED_INTERFACE) {
+ return (
+
+
+
+ Disable specific Advisor categories or rules to prevent them from showing up in Advisor
+ reports or email notifications. This could be useful for rules that might not be applicable
+ to your project.
+
+
+
+
Enabling this preview will:
+
+
+ Allow you to disable advisor rules for your project from the{' '}
+
+ Advisors section.
+
+
- This chart is available from Pro plan and above
+ This chart is available from{' '}
+ {!!availableIn?.length ? availableIn[0] : 'Pro'}{' '}
+ plan and above
+ }
+ className="w-7"
+ tooltip={{ content: { side: 'bottom', text: 'Refresh report' } }}
+ onClick={onRefreshReport}
+ />
{
description="Report data can be stored for a maximum of 3 months depending on the plan that your project is on."
source="edgeFunctionsReportDateRange"
/>
+ {selectedDateRange && (
+
+
+
+
-
- The number of storage requests that are cached at the edge level. A higher number of
- hits is better.{' '}
-
-
- Read More
-
-
-
-
- }
- data={data.cacheHitRate || []}
- renderer={CacheHitRateChartRenderer}
- append={TopCacheMissesRenderer}
- appendProps={{ data: data.topCacheMisses || [] }}
- />
+
+ The number of storage requests that are cached at the edge level. A higher number of
+ hits is better.{' '}
+
+
+ Read More
+
+
+
+
>
)
}
ResetPasswordPage.getLayout = (page) => (
{page}
diff --git a/apps/studio/public/img/previews/advisor-rule-preview.png b/apps/studio/public/img/previews/advisor-rule-preview.png
new file mode 100644
index 0000000000000..703d5a9d5963e
Binary files /dev/null and b/apps/studio/public/img/previews/advisor-rule-preview.png differ
diff --git a/apps/www/_blog/2025-07-16-branching-2-0.mdx b/apps/www/_blog/2025-07-16-branching-2-0.mdx
new file mode 100644
index 0000000000000..22e85de909b54
--- /dev/null
+++ b/apps/www/_blog/2025-07-16-branching-2-0.mdx
@@ -0,0 +1,140 @@
+---
+title: 'Introducing Branching 2.0'
+description: 'Create, review and merge Supabase branches all within the dashboard.'
+categories:
+ - product
+ - launch-week
+tags:
+ - launch-week
+ - studio
+date: '2025-07-16:00:00'
+toc_depth: 3
+author: saxon_fletcher
+image: launch-week-15/day-3-branching-2-0/og.jpg
+thumb: launch-week-15/day-3-branching-2-0/thumb.png
+launchweek: 15
+---
+
+Branching has been a part of Supabase for some time now, a way for you to experiment or build out new features without affecting your production environment. It requires you to connect your Supabase project to a GitHub repository which automates many parts of the workflow, but this also alienates those who prefer not to use Git. Today, we are announcing Branching 2.0 which removes the Git requirement and makes it super simple to spin up new branches.
+
+
+
+
+
+## What is branching?
+
+A Supabase branch is essentially a copy of your Supabase project, minus the data. Rather than making risky changes to your production database, edge functions or configuration, you instead spin up a preview branch and make the changes there. This gives you a safe, isolated environment to work from. When you’re happy with your changes, you merge them back into production.
+
+## Current behavior
+
+The current implementation of branching requires a connection to a GitHub repo. For every GitHub pull request created, a corresponding Supabase branch is also created and kept in sync. Database schema/migrations, functions and configuration all stored within your repo and synced up to Supabase when your commits are pushed. For those who want to work in a local and code first way, this is an ideal workflow, however, this is not suitable for those who prefer to work in a database first or no-code way, including AI Builders.
+
+## New behavior
+
+With these new updates you can now create branches with Git, without Git, or a combination of both. This can be done directly through the dashboard, Supabase CLI, or the [Management API](https://supabase.com/docs/reference/api/introduction). Every branch is a direct copy of production, including schema, functions and configurations. You can then connect your app, make changes, and when ready to launch, you have the option to pull those changes down to your codebase or review and merge without leaving the dashboard. For those using separate Supabase projects for this, you no longer need to do so.
+
+### How it works
+
+For this walkthrough we’ll focus purely on a _Gitless_ workflow. If you are someone who prefers to work in a code-first way, you can view our more extensive [guide to branching](https://supabase.com/docs/guides/deployment/branching).
+
+#### Create a new branch.
+
+
+
+Give your branch a name, optionally sync it to a GitHub branch. If your production branch has previous migrations (e.g., via CLI `db push` ) then these will be run on the new branch. If your production branch has no previous migrations (e.g., all edits have been made through the Table Editor) then a `db dump` will be performed and run as a migration.
+
+#### Make changes to the new branch
+
+
+
+Use the table editor, SQL editor, connection string or any other means to make changes to your schema or functions.
+
+#### Open a merge request
+
+
+
+
+
+You, someone in your team, or the Supabase Assistant can then review the changes made via the merge page.
+
+#### Pull in latest updates from production
+
+If your branch schema or edge functions are out of date, you will first need to pull in the latest changes from production. Note that by doing this any edge function modifications will be lost but new functions will remain in place untouched.
+
+#### Merge to production
+
+
+
+When ready, click the merge button and watch your changes be deployed to production. If your branch is a preview branch you can now choose to remove it or keep it open.
+
+### Current 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.
+
+## When to use
+
+The following table can help you decide whether to use branching with or without git.
+
+| | Git | Without Git |
+| --------------------- | -------------------- | --------------------------- |
+| Isolated environment | ✅ | ✅ |
+| Friction | Low code | No code |
+| Ease of use | Extensive repo setup | One click from dashboard |
+| Merging to production | via Pull Request | via Merge Request |
+| Conflict resolution | File based | None |
+| Version control | Config as code | Only migrations are tracked |
+
+## End state
+
+We ultimately want you to be able to work in a way that produces the highest quality software in the shortest time possible. Your workflows may change as you, your team or your product evolves, and we must allow you to move between workflows seamlessly. If you want to start building directly in the dashboard then later move everything to a codebase, you should be able to do that. If you want to spin up a branch for prototyping then later pull down changes to a local migration, that should also be possible.
+
+We aren’t quite there yet, but through the combination of our CLI and web interface, that vision is closer than ever.
+
+## Getting started
+
+We want to stress that these branching updates are in their early stages and thus behind a feature preview. Anyone can opt-in to them via the dashboard but before you do, please read through the existing limitations as it might not yet be suitable for your use case. If you do make use of branching, please reach out with feedback, we’d love to hear it.
diff --git a/apps/www/components/Hero/Hero.tsx b/apps/www/components/Hero/Hero.tsx
index 313dbc7a8404a..88bbe035a52e8 100644
--- a/apps/www/components/Hero/Hero.tsx
+++ b/apps/www/components/Hero/Hero.tsx
@@ -19,7 +19,7 @@ const Hero = () => {
diff --git a/apps/www/components/LaunchWeek/15/data/lw15_data.tsx b/apps/www/components/LaunchWeek/15/data/lw15_data.tsx
index a4c4aca81ec26..9ecd809939299 100644
--- a/apps/www/components/LaunchWeek/15/data/lw15_data.tsx
+++ b/apps/www/components/LaunchWeek/15/data/lw15_data.tsx
@@ -93,7 +93,7 @@ const days: (isDark?: boolean) => WeekDayProps[] = (isDark = true) => [
d: 2,
dd: 'Tue',
shipped: true,
- isToday: true,
+ isToday: false,
hasCountdown: false,
blog: '/blog/analytics-buckets',
date: 'Tuesday',
@@ -123,18 +123,18 @@ const days: (isDark?: boolean) => WeekDayProps[] = (isDark = true) => [
id: 'day-3',
d: 3,
dd: 'Wed',
- shipped: false,
- isToday: false,
+ shipped: true,
+ isToday: true,
hasCountdown: false,
- blog: '/blog/',
+ blog: '/blog/branching-2-0',
date: 'Wednesday',
published_at: '2025-04-02T07:00:00.000-07:00',
- title: '',
+ title: 'Introducing Branching 2.0',
description: '',
links: [
{
type: 'video',
- href: '',
+ href: 'CRARnyYqrOU',
},
],
steps: [
diff --git a/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/create-branch.png b/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/create-branch.png
new file mode 100644
index 0000000000000..2cfbc31639469
Binary files /dev/null and b/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/create-branch.png differ
diff --git a/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/og.png b/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/og.png
new file mode 100644
index 0000000000000..438df504a54a6
Binary files /dev/null and b/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/og.png differ
diff --git a/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/review-with-ai.png b/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/review-with-ai.png
new file mode 100644
index 0000000000000..1ea2f1261b95d
Binary files /dev/null and b/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/review-with-ai.png differ
diff --git a/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/thumb.png b/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/thumb.png
new file mode 100644
index 0000000000000..3658102d33cf9
Binary files /dev/null and b/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/thumb.png differ
diff --git a/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/view-branches.png b/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/view-branches.png
new file mode 100644
index 0000000000000..67383ccd6262a
Binary files /dev/null and b/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/view-branches.png differ
diff --git a/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/view-merge-request.png b/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/view-merge-request.png
new file mode 100644
index 0000000000000..1ba8d5170c691
Binary files /dev/null and b/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/view-merge-request.png differ
diff --git a/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/view-merge-requests.png b/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/view-merge-requests.png
new file mode 100644
index 0000000000000..a3f960a54e83c
Binary files /dev/null and b/apps/www/public/images/blog/launch-week-15/day-3-branching-2-0/view-merge-requests.png differ
diff --git a/apps/www/public/images/logos/publicity/figma.svg b/apps/www/public/images/logos/publicity/figma.svg
index b9a4cb45b81c2..c4852e094a0e3 100644
--- a/apps/www/public/images/logos/publicity/figma.svg
+++ b/apps/www/public/images/logos/publicity/figma.svg
@@ -1,6 +1,54 @@
-