Is there any way to set/update environment variables for a running app and then trigger a restart of the service instead of having to deploy a brand-new application (even if it is the same code)? It seems like when setting secrets that behavior exists so I was wondering if there is any undocumented way todo that for regular env variables too?
Hi,
As far as I’m aware, environment variables (including secrets) are provided to the app’s vm when one is created/boots. It’s at that point the vm gets the variables injected into it by the Fly agent (as it gets temporary access to decrypt secrets).
Setting a secret should (or at least it did when I last tried!) trigger a new deploy (incremented version). So it’s the same application (code) but it gets new vms as a result of that new deploy. And those new vms have the new environment variables injected. Since secrets are also environment variables, I would assume it’s the same: if you add/update environment variables, it would need a new deploy for that change to be reflected.
Hi greg, Yeah I understand that, however. It just creates new machines with the same already build image (relatively fast) compared to if I would have todo a full app deployment which would mean it would have to rebuild the docker image just for me to change some parameters.
That is why I was trying to find out if there is a similar way to how secrets work.
If you have a dockerfile instead of using buildkit each build step should be cached, this would make builds that are the same input (files, settingss) as one that has been done before not happen.
Yeah but it still would be slightly slower. AND it would require me to switch back my codebase to the version I’ve previously deployed. So quiet some overhead to (as I need the old code with the new fly toml that contains the changed env vars.
But by the sounds of it there is just nothing available at the moment if I read your responses correctly.
If you wish to re-deploy the already deployed image you can use -i I think to use the deployed image directly.
Edit, something like fly releases --json | jq .[0].ImageRef will get you the image tag, so then fly deploy -i $(fly releases --json | jq.[0].ImageRef) would do what you want.
3 Likes
Ah cool and will that apply the new env variables during that new deploy?
I think so? Try it and see I suppose.