Enable preview environment group override
planned
z
zach
Proposal
It would be really nice to have the following syntax available in
render.yaml
:envVars:
- fromGroup: my-production-env-group
- fromGroupPreviewOverride: my-preview-env-group
This problem has come up several times in the community and is one of the most important parts of a streamlined CI/CD workflow. I would love to see it on the roadmap :)
Problem statement
Currently, there are 3 options for overriding environment variables in preview environments:
Solution 1
Define them in plaintext within
render.yaml
:envVars:
- key: MY_ENV_VAR
value: production-value
previewValue: preview-value
This works for values that can be shared, but is not suitable for private secrets (which is a pretty common use-case)
Solution 2
Define them with
sync: false
and manually
fill them in on each PR.This works, but is extremely time consuming, especially if your env file has 10+ variables to fill in.
Solution 3 (workaround)
Omit environment groups from
render.yaml
altogether, but still reference them in your services. For example:envVars:
- fromGroup: my-production-env-group
- fromGroup: my-preview-env-group
From here, you must write additional logic into your application to choose the correct variable based on the environment.
let myVariable;
if (process.env.NODE_ENV === 'development') {
myVariable = process.env.LOCAL_VALUE
}
if (process.env.NODE_ENV === 'production') {
// https://render.com/docs/environment-variables#all-services
if (process.env.IS_PULL_REQUEST) {
myVariable = process.env.PREVIEW_VALUE
} else {
myVariable = process.env.PROD_VALUE
}
}
In my opinion, this 3rd solution is the best, but still isn't great because it requires you to expose production variables in your preview environment.
Log In
J
Johannes Lehtonen
I see fromPreviewGroup was added to the blueprint schema, but doesn't seem to have any effect. And this is still marked planned after a year. Are we getting close to completion at long last?
S
Sanjay Ginde
Is there any update on resolving this issue? I have intermittent production issues because my preview environment groups get re-attached to my production instances. There is no consistent way to know which overrides what–it seems to be arbitrary.
J
John Ruble
I have a similar problem, but in my case the value that I wish to override isn't a secret. Zach's proposal (one group overriding another) would work for me, but so would something like this:
envVars:
- fromGroup: dev
- key: NEXT_PUBLIC_SENTRY_ENV
previewValue: review-apps
(Today you can't specify
previewValue
without value
)If this suggestion were easier or faster to build, it might help folks like me while you continue to crank on the first idea.
FWIW, my (hopefully temporary) workaround is to export variables from buildCommand/startCommand scripts :|
Anurag Goel
planned
C
Conrad Chu
Anurag Goel: Yay!!!!!!
J
Jesse House
Anurag Goel: Any updates on this feature?
Was looking for alternatives to Heroku and this might hold me back.
Out of the workarounds that Zach mentioned #2 seems the only viable option, but preview apps should be seamless and not require manually updating variables.
Loving everything else about render deploys
:(
N
Nate Matykiewicz
Anurag Goel is there any update on this? Preview Environments are pretty difficult for us to use.
We pay a lot of money for Sidekiq Enterprise and don't particularly want to commit the key in plaintext in our render.yaml. And manually specifying it in the Preview Environment's new ENV Group every single PR after the preview environment fails to deploy is a huge pain.
We just want to be able to create a Preview Environment ENV Group that all Preview Environments use, which has our Sidekiq key and our development RAILS_MASTER_KEY. Then it can also merge in the redis and postgres connection string URLs for the services it just built.
Anurag Goel
Nate Matykiewicz: thanks for flagging it. Meagan Gamache and I are looking at improvements to preview environments and this one seems very high impact.
N
Nicholas Larus-Stone
Anurag Goel: Don't want to be a bother, but this is a big blocker for us (and has led to some unexpected behavior). Is there some sort of public timeline we can follow along so we don't need to ping in this thread?
t
tom
This is a big stumbling block for us too: like if we have an API key that's in env, and there's a value for production but we want to have a different value for a preview environment - even though the preview value might be 'less critical', it's still bad form to hardcode an API key in a file that we check into source control. It'd be great if the
previewValue
syntax allowed us to also use fromService
or to refer to another API variable, or any option that isn't just hardcoding a value.Because there isn't an option, like the OP we have one hacky workaround that messes with env variables in our application, and we don't really use the previewValue feature at all.
D
Diogo Cabral
This has been a big problem to us.
k
kossy
This is the only thing blocking our switch from Heroku, so I think it should be table stakes not a nice to have
R
Richard Keil
This is a must have for preview environments.