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.
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.
[context.deploy-preview.environment]
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.
[context.branch-deploy]
command = "echo branch"
[context.branch-deploy.environment]
NODE_ENV = "development"
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:
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
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…
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.
Steps:
Add env variables to UI. PRODUCTION_API_SECRET, STAGING_API_SECRET
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
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
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)
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.
