Do not rebuild when changing environment variables (cache container builds)
complete
J
Jaap Frolich
Just use the previously build container image. Even better would be to cache the git ref, so even if the same ref is being published to a new branch (perhaps staging => production) it will be a fast deploy.
Log In
Paige Kehoe - Render PM Team
complete
M
Michael Hellein
I really don't think this should be considered complete. If the original report is not explicit enough that restarting a container with new environment values is the expected behavior, I can make a new feature request to reflect that. Considering that this one waited 5 years for a partial solution, I really hope that is not the path a new request will take.
M
Michael Hellein
Paige Kehoe - Render PM Team I'm not saying that the original report described this well, but that an interest in having containers be able to restart with new environment variables has been attached to this feature request over the years. (See my comment from March 1, 2023.) The feature surely doesn't meet what commenters have been asking for.
Paige Kehoe - Render PM Team
Me again! We were actually working on finishing the second half of this request this week so hadn't marked the top level issue as "Done" yet. Happy to report we now have 3 options for your env var updates including one to skip builds when updating env vars for services. Check it out and please let me know your thoughts!
I joined Render last month to help us focus on larger production teams and supporting their development workflows, so if that's a concern for you, I would love to chat more to learn about current needs and wants for your teams and production apps! Email me paige@render.com to set up some time.
Paige Kehoe - Render PM Team
Hi! Paige from the Render PM Team here - we just updated environment variable functionality so now when you change variables, you have the option to "save and deploy" or "save and apply next deploy". Does this solve the problem for you? Kenn Ejima
B
Ben Lopatin
Paige Kehoe - Render PM Team "Save and deploy [and rebuild]" or "Save and deploy [deploying the existing build artifact with the new environment variables]"?
The big problem is unnecessary rebuilding for a change in an [application runtime effecting] environment variable, rather than wanting to delay a full build.
R
Rich Shakespeare
Ben Lopatin Agreed, the ideal is what Heroku does which is just re-releases the built app with the new config (in seconds)
K
Kenn Ejima
Paige Kehoe - Render PM Team wow, I'm impressed — thanks for your quick action! Yes, the problem solved indeed! 🎉
K
Kenn Ejima
Ben Lopatin I just checked and it won't trigger rebuild when you choose "Save and apply on next deploy". Try it!
K
Kenn Ejima
Rich Shakespeare You mean restart without rebuild? I thought it's doable already?
B
Ben Lopatin
Kenn Ejima it does not apply the updated environment variable to the running app - I think we are fundamentally concerned about different things here. The update shared here
is
helpful, but MY concern is not that I want to be able to update a bunch of variables and apply when its time - my concern is that I want to be able to change environment variables that impact RUNTIME and redeploy the app without an unnecessary BUILD
. E.g. an API key that needs to be updated, and instead of it being updated in a matter of seconds, I now need to wait for the ritual of loading the image, rechecking dependencies, etc., etc.The initial request is a little vague, but "Just use the previously build container image" and "it will be a fast deploy" implies a problem that the latest update here does NOT solve, as welcome as that update may be.
K
Kenn Ejima
Ben Lopatin Now that we have "apply on next deploy", you can just restart the server without rebuild? Can you just try it?
E
Erik van Eekelen
Paige Kehoe - Render PM Team - This is great, and exactly what we need as well, but it doesn't seem to be available for Cron Jobs? Any reason for that?
M
Michael Hellein
Paige Kehoe - Render PM Team It sounds like you're saying that now you can change environment variables with no immediate impact on a container, even with auto deploy active.
This may address something that some users want, but what you're describing is clearly not what this issue is about. This issue describes changing the runtime values of environment variables for an existing deployment by restarting it with the new values. Heroku has supported this since day one, I believe, and it seems like an obvious and easily documented use case.
B
Ben Lopatin
Kenn Ejima You can just restart the server, but
based on some brief testing
it does apply the new env vars; enable a running app's debug
status in the env var, then restarting the service did not
have the expected effect. Perhaps my test failed for other reasons, but at this point I'm sufficiently skeptical that the product update here doesn't actually address the original issue.My
suspicion
is that the env vars are added at build time and cannot be updated except with a full build (which is the problem that the original requestor - and myself! - would like to get around).Paige Kehoe - Render PM Team
Ben Lopatin Kenn Ejima Just posted our update at the top level thread, but hopping in here too! We hadn't marked the issue as done _yet_ because the last option for updating your env vars for services was still in progress. :) Please check now and let me know your thoughts
B
Ben Lopatin
Paige Kehoe - Render PM Team this works and the named dropdown options are an improvement over the last iteration in terms of what they communicate, too. I would
prefer
faster resolution of deployment for just updating an env var (still took a little over a minute from deployment start to completion) but
it's still a nice improvement and if this were my request I'd call it "feature complete"!M
Michael Hellein
Ben Lopatin In my experience, there are scheduling gremlins in the deploy process that can add minutes between actual workflow steps, and it's just too long (not to mention unpredictable) to wait for an environment variable change. If your build step is fast (or takes no time), this change doesn't actually have a significant impact on the amount of time a deploy takes. It's a step in the right direction if you have a long build time, but I'd be reluctant to call this feature complete.
J
John Ruble
This should probably be combined with better visibility and control over which env vars are available at _build time_. Maybe when you add an env var to render, you have to say whether to make it available at build-time, runtime, or both?
(then Render would be able to know whether an env var change invalidates a build, and that the build can be safely reused)
Anurag Goel
planned
K
Kenn Ejima
Anurag Goel any updates?
This hit me again today, I would appreciate if there was a checkbox that says "rebuild / deploy upon save" so that I can uncheck it when it's appropriate.
Also, I think it should be unchecked by default. I find it's very rare that automatic rebuild is useful — on the contrary, it's been making env changes harder.
For instance, when you rename a variable name, you'd change it first in the dashboard for preparation, but don't want to apply it until the new code gets loaded and restarted.
M
Michael Hellein
Anurag Goel If what Paige is describing above is what was planned 1.5 years ago, I think this feature needs to be planned again, because what's delivered has missed the mark. I am a patient and mostly satisfied customer, but I cannot fathom why this is something that we're still waiting for.
Paige Kehoe - Render PM Team
Michael Hellein my first post was part 1 of this request and just posted our update with the rest of the work the team did :) Take a look and let me know your thoughts!
M
Michael Hellein
Paige Kehoe - Render PM Team I haven't tested it yet, but it looks like the "Save and deploy" option is what I (and seemingly also the author of this request) am looking for. Each of the three options has a clear use case, and I'm glad to see them supported in Render.
M
Michael Hellein
Paige Kehoe - Render PM Team I've now tested this feature, and it does not meet what I would expect from the feature. The core problem is that a "deploy" is nowhere near as fast as a restart, especially because Render's deploy infrastructure has a number of expected "scheduling" delays, and is not engineered for speed. Possibly the environment variables layer of the stack is not designed properly, if it's not possible to simply apply different values and restart the running container. Changing environment variables should be nearly instantaneous - and it is definitely an infrastructure smell if that's a heavy lift.
M
Michael Hellein
This is absolutely a necessity for operating production services. Needing to wait through a build (which may include an unknown amount of waiting in Render's build infrastructure queues) to make an environment change doesn't make any sense - we are not changing the deployed code, we are changing its environment!
B
Ben Lopatin
This capability (or lack thereof) is a hard blocker to even considering migrating any customer facing services to Render. Whether its a new connection string, API key, or fixing a typo in variable, waiting for a complete build is a non-starter.