Per-branch environment variables (=secrets)

Suppose you are building a NextJS project. The project needs to use access credentials to third-party data services, both during the build (for fetching and rendering static content) and also post-build in an SSR deployment (for fetching and rendering dynamic content).

Different branches of the project need to use different access credentials. Specifically, the production branch needs to access data in a production repository, while other branches use data from a staging repository.
Non-production branches should not be able to access the production repository, and vice versa.

Currently, to my knowledge, the only way to provide secrets to Netlify build/SSR processes is through the Netlify environment variables - but unfortunately this doesn’t distinguish between different branches/environments.

Previously I have used a similar feature on a different hosting service, and it would be great to have it on Netlify too.

Hi @frogger77

Welcome to the forums

It is possible to have branch and deploy context specific environment variables. Below is a section from File-base configuration > sample netlify.toml file

# Here is another way to define context specific environment variables.
  ACCESS_TOKEN = "not so secret"

# Branch Deploy context: all deploys that are not from a pull/merge request or
# from the Production branch will inherit these settings.
  command = "echo branch"
  NODE_ENV = "development"

See the Site deploys > Deploy context and File-based configuration > Deploy contexts for more information.

Thanks, but the thing is that the netlify.toml file is in the source control, and it would be a bad idea to store secrets there!

If the repository is private, then technically speaking the only people who will seem the secrets are those working on the project who should have access to them.

So your feature request is to specifically have per-branch and per-deploy context environment variables settable via the Netlify UI, correct?

While I agree with @coelmay that that is the easiest way to handle them, I understand your desire to keep them out of your repo. The only environment variables that go to functions (which handle our ISR) are anyway the ones shown in our UI.

So, if you are ok sticking variables in our UI, here’s a way to use selectively per branch:

  1. use a trick like this to make a context-specific deploy: [Support Guide] Conditional build/deploy behavior for context / branch on Netlify
  2. in the production deploys, change the variables used - e.g. “for a master build, use MASTER_ENDPOINT, and for any other build use DEV_ENDPOINT”.

This will allow your site to work differently for different branches without committing secrets to the repo.

It does not necessarily prevent your staging/etc deploys from accessing the $MASTER_ENDPOINT, but it should allow you to develop build logic to only use the correct endpoint in your code to achieve your goals in deploying :slight_smile:


Thanks, that’s the solution we are thinking of.
But of course it would be better to not have the risk of sharing production credentials with a non-production environment…

1 Like

Thanks for sharing that feedback, @frogger77! We appreciate it, and I have shared it with the appropriate team.

1 Like

So you mean we should put the secrets in the UI and override public variables in netlify.toml?
What if the secrets are different per-branch?
Is there a way to specify a mapping of what env variable per context.

  • In netlify.toml production deploy env context, map API_SECRET::PRODUCTION_API_SECRET
  • In netlify.toml staging deploy env context, map API_SECRET::STAGING_API_SECRET

Have you gone through this:

You can use [context.deploy-preview] and set the variables in there.

Thanks for your reply @hrishikesh

I’m stil not sure I understand the solution.

My situation:
I have an ACCESS_TOKEN for prod and ACCESS_TOKEN for staging.
I don’t want to commit both in git. A.k.a in the netlify.toml file.

**Solution **
The solution that’s being proposed here in this thread. I might be misunderstanding so pls feel free to correct me.
Add ACCESS_TOKEN = “prod secret” in the UI
Add this in netlify.toml to overide the ACCESS_TOKEN in UI for staging

ACCESS_TOKEN = "staging secret"

With this solution, I still have to write the secret in the netlify.toml file even if it’s just for the staging content.

Or am i missing something?

Hello @0xsoji

The process we outline in this thread mostly focus on having the access tokens as variables in the UI, and then reuse them depending on the context. Here is a great explanation of what we mean:

The idea is for you to keep the variables stored safely on the UI and call specific scripts (which export the correct token, per context)

Let me know if this helps!

Thanks @gualter for your reply.

I understand now, I’ll give this a shot.

Does this work for cloud functions too?


Now that Vercel has node16 runtime, i’ll be moving to them.
Just can’t figure out why this isn’t working with cloud functions and i’ve spent so much time on it already.
But apart from this feature, I think netlify is a great service so kudos to you all.