Branching - Hosting provider integrations

[MildTomato]

This discussion is for tracking requests/demand for hosting providers that Supabase could integrate with so that Preview Branches can support their preview deployments.

Vote for Git providers here and for general branching feedback, use this discussion.

[MildTomato]

Vercel

status: In active development

[empz]

How does the sync of environment variables into Vercel work? Which variables needs to be overriden for preview environments? I successfully installed the Vercel integration but only Production variables are sync. I have a preview branch (which I created manually) that doesn't have any of the SUPABASE_ env. variables. Not sure how this is supposed to work.

[kamilogorek]

You can either mark a "preview" checkbox in the integration settings, which will repopulate the same env vars for each environment, or you can use it alongside GitHub integration, which will automatically set new branch env vars for every PR created.
We do not automatically sync env vars for manually created branches, as there has to be a Vercel deployment with the given name first, which is only created once Vercel detects new GitHub branch.

[empz]

Uhm, I created the branch manually and then created a PR and got the branch-specific environment variables populated into Vercel. So it seems the integration does sync vars even for manually created branches, but seems to be happening when the PR is created.

[kamilogorek]

Correct, the trigger used here is github webhook notifying us of the PR creation. We just dont sync manual branches at the time of their creation.

[johnford2002]

Cross posting a feedback post from the Branching thread since it seems more relevant to the Vercel integration piece.
https://github.com/orgs/supabase/discussions/18937#discussioncomment-10438263

The integration doesn't seem to clean up after itself when a PR is merged and the resulting branch is deleted from GitHub.

[MildTomato]

Netlify

status: Currently not in development

[ThatGuySam]

This is the big one for me.

Netlify has historically been very affordable for Open-Source projects and I end up using it commercial projects as well.

[MarkBennett]

Does Netlify expose the env values needed to access the branch in the api anywhere? If so, would you be open to a community implementation of this that could run in a GH Action?

We use Netlify and are looking at adding a db. Supabase is in the running but Deploy Previews are a huge part of our workflow so integration would be a big pro vs some of the alternatives. Currently comparing with AstroDB and Neon.

[MildTomato]

Render

status: Currently not in development

[MildTomato]

Cloudflare pages

status: Currently not in development

[remorses]

You are focusing on the wrong problems, let people change the env variables by themselves and make the GitHub app optional. Instead focus on making the core branching functionality work: add a merge button in the dashboard and collect all the bugs that happens when you try to merge, for example

• what happens if the schema migration fails?
• what happens if you delete a table with data in it? Should you add a error? Or confirmation message?
• how can you merge main back to a branch?

These are all things that PlanetScale implements, I suggest copying what they do and later add the GitHub app, only after you know the core model works

[ihadabs]

agree a branching like PlanetScale would be super nice

[LordZardeck]

A railway integration would be extremely helpful to us, or some API at least to fetch the env variables for a given branch name so we can make our own integration

[kamilogorek]

or some API at least to fetch the env variables for a given branch name so we can make our own integration

https://api.supabase.com/api/v1#/environments/v1-list-all-branches + https://api.supabase.com/api/v1#/environments/v1-get-a-branch-config :)

[verbose-void]

I'm interested and super excited to be able to use this feature! would it be necessary to have multiple instances of environment variables stored in vercel? or would we be able to have the same environment variables across production, preview, and development (within vercel linked to supabase with supabase env vasrs) to still be able to use database branching?

also, how would database schematics definitions work? migration files are okay, but can they compare to, say, terraform/pulumi-style migration diffs for infra (or in this case, DB schema) changes? especially automatically and portably?

[verbose-void]

likewise, would be super nice to be able to have policies/row-level-security/etc described in code (and therefore version-controlled). at that point- templates would be so much more powerful as well, because you could define full suites of everything ready to go at the push of a button, and streamline having multiple dev environments for maximum data-security.

[kamilogorek]

would it be necessary to have multiple instances of environment variables stored in vercel? or would we be able to have the same environment variables across production, preview, and development (within vercel linked to supabase with supabase env vasrs) to still be able to use database branching?

You can already choose what envs you want to sync to, and Vercel fallbacks to preview if there are no branch-specific env vars. However, we do not let you specify which env vars should be actually synced, so they'll always be creating a new instance for a new branch. They are always different though, so I'm not sure how exactly you'd like to share them.

how would database schematics definitions work?

I'm not exactly sure what you're asking about here, but internally how we're using our own CLI to run everything on top newly created branch, so it works 1:1 how described in https://supabase.com/docs/guides/local-development/overview

would be super nice to be able to have policies/row-level-security/etc described in code

Setting up RLS is nothing more than running its corresponding SQL queries, so you can have them stored and diffed inside migrations just fine. See https://supabase.com/docs/guides/database/postgres/row-level-security

[verbose-void]

@kamilogorek

1. you can only have one set of supabase environment variables linked to vercel. now, what do you do when you want a separate database for prod and dev?

2. yeah, i know what RLS is, however you have to go into the website to type all of the commands in instead of having it synchronized with your git repository. it's a lot of manual effort to handle diffs, but terraform among others have a version controlled infrastructure that can apply to this problem as well.

[k2xl]

Hi - I'm a bit confused on whether Vercel (assuming Vercel integration is installed) should be automatically getting environment variables from supabase when a branch is created (for that specific branch db)?

[k2xl]

@kamilogorek Thanks - I do think that it should be clearer in the docs about this functionality and that explicitly creating the branch doesn't work.

Have you considered changing the behavior where it checks to see if the branch exists - and if so tries to populate the env vars (assuming they don't exist?)

[kamilogorek]

• I do think that it should be clearer in the docs about this functionality and that explicitly creating the branch doesn't work.

https://supabase.com/docs/guides/deployment/branching#vercel

Vercel GitHub integration also required.
For branching to work with Vercel, you also need the Vercel GitHub integration.

It's there 😄

Have you considered changing the behavior where it checks to see if the branch exists - and if so tries to populate the env vars (assuming they don't exist?)

I started working on expanding branching support to more providers and making it more generic, so this might naturally come to fruition in the future :)

[k2xl]

Thanks for the reply- the section you quote in the docs was not the part that was not clear.

I already had the integrations enabled.

1. In git I pushed a new staging branch. It appeared on vercel but did not auto create on supabase.

2. I tried manually creating the branch on supabase. Then i checked vercel and the env vars were still empty.

3. I then tried making a new change on the branch (thinking maybe because the branch didnt exist before and now it does) that it would. But it didnt.

4. I tried making the branch persistant. Resetting the branch. Trying combinations but still did not update env vars on vercel.

5. Finally i tried creating a pull request (i think i had deleted the branch at this point). NOW env vars were populated.

Steps 1-4 or some variation i imagine is what people would expect would work. Step 5 being the key could have been more clear in the docs imo.

[kamilogorek]

Ah, gotcha. Updated the docs to reflect this #30969

[k2xl]

Thank you @kamilogorek ! much clearer!

[hbd]

Hey all, even after creating a PR, I'm not seeing env vars populate for my Vercel preview branch. I'm having to manually populate the env vars which requires resetting the Postgres password and constructing the connection string.

[kamilogorek]

Do you have both, GitHub and Vercel integration installed on the same project?

[k2xl]

@hbd If you made the same mistake as I did - you may need to "uncheck" Preview from the env vars that you don't want enabled.

[hbd]

@kamilogorek, yes I do. The Preview deploys are going through when I open/push to a PR, however I'm seeing these issues:

• Env vars for preview branch not populating when PR is first opened
• Some values in Supabase are reset, like site URL, redirect URLs, and max storage upload limits, on the preview branch, every time a new commit is pushed to the feature branch PR