# The logic behind a "Release" after adding a secret **URL:** \ **Category:** General\ **Created:** [January 21, 2022, 11:34am UTC](https://community.fly.io/t/the-logic-behind-a-release-after-adding-a-secret/3730 "2022-01-21T11:34:28Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![catadesk](https://avatars.discourse-cdn.com/v4/letter/c/d2c977/32.png) [@catadesk](https://community.fly.io/u/catadesk)\ **Post date:** [January 21, 2022, 11:34am UTC](https://community.fly.io/t/the-logic-behind-a-release-after-adding-a-secret/3730/1 "2022-01-21T11:34:28Z")
So I just added a secret to a very, very simple Rails app we run on [Fly.io](http://Fly.io). In the activity log, I see that that is followed up by a new release. Due to this release, my app was not available for over 10 seconds. What is the logic behind completely taking the app offline when a secret (ENV var) is added? ![image](https://global.discourse-cdn.com/fly1/original/3X/6/9/695652103c3028f871c95c4fb1e54c201f630503.jpeg) ---
**Author:** ![greg](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/greg/32/2119_2.png) [@greg](https://community.fly.io/u/greg)\ **Post date:** [January 21, 2022, 5:03pm UTC](https://community.fly.io/t/the-logic-behind-a-release-after-adding-a-secret/3730/2 "2022-01-21T17:03:47Z")
I believe Fly defaults to a new release when secrets are changed. Arguably that shouldn’t include a secret being _added_ as that could not affect existing code (which would not know about that secret even being there) but it would (potentially) affect a running app if a secret is updated or deleted. As regards taking the app offline, I think _that_ is an unintended consequence of _any_ deploy/release (currently), rather than due to secrets specifically. The current solution is to have an app with at least three instances. See e.g: > [@Internal network DNS propagation and new deployments](https://community.fly.io/t/internal-network-dns-propagation-and-new-deployments/3672/4): > > Yes I think that will work! The deploy downtime you see through \.fly.dev is probably due to our slow service propagation. If you’re running behind an nginx, it probably won’t affect you. The workaround until we get this fixed is to fly scale count 3. You can see more details here: [how do fly.io deploys work? - #2 by kurt](https://community.fly.io/t/how-do-fly-io-deploys-work/3378/2) ---
**Author:** ![catadesk](https://avatars.discourse-cdn.com/v4/letter/c/d2c977/32.png) [@catadesk](https://community.fly.io/u/catadesk)\ **Post date:** [January 22, 2022, 12:14am UTC](https://community.fly.io/t/the-logic-behind-a-release-after-adding-a-secret/3730/3 "2022-01-22T00:14:37Z")
Thanks for the insightful answer @greg! This is exactly what I was looking for, however I didn’t fully understand the latter part of your answer yet. I do have to say my collegue @qqwy has explained the same thing before, I’m just a little slow in understanding I guess. This seems like a very elegant solution by Fly by the way. We’re deploying a couple of our internal services on Fly, hoping that we can migrate with our main app. Very happy so far! ---
**Author:** ![greg](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/greg/32/2119_2.png) [@greg](https://community.fly.io/u/greg)\ **Post date:** [January 22, 2022, 12:37am UTC](https://community.fly.io/t/the-logic-behind-a-release-after-adding-a-secret/3730/4 "2022-01-22T00:37:05Z")
You’re welcome. Kurt posted today they are close to fixing it 🚀 It’s because of how Fly’s innards work. The “3+ VMs” solution just masks it for now. There is some more detail from @kurt here on the cause: > [@how do fly.io deploys work?](https://community.fly.io/t/how-do-fly-io-deploys-work/3378/2): > > You’re probably hitting a slow service propagation issue we’ve been fighting. It will hopefully be fixed for good in a few weeks, but the tldr is we’re probably causing the downtime when you deploy an app with a single VM. You can reduce the impact of this by running fly scale count 2 or more. When you deploy we: Start a canary VM (if you’re using a volume, we skip this step) Remove an old VM from service discovery Wait 30 seconds Stop old VM Start new VM, add it to service discovery fly-pro… ---
**Author:** ![kurt](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/kurt/32/43757_2.png) [@kurt](https://community.fly.io/u/kurt)\ **Post date:** [January 22, 2022, 3:21am UTC](https://community.fly.io/t/the-logic-behind-a-release-after-adding-a-secret/3730/5 "2022-01-22T03:21:04Z")
The secrets require all the VMs to restart because they’re exposed as environment variables. At the moment, there’s no way to add a secret without it immediately being applied in a release. Staging secrets is something we know we need to do, and it should pretty quick after some very not-quick architectural changes we’re making. ---
**Author:** ![kurt](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/kurt/32/43757_2.png) [@kurt](https://community.fly.io/u/kurt)\ **Post date:** [February 23, 2022, 2:45am UTC](https://community.fly.io/t/the-logic-behind-a-release-after-adding-a-secret/3730/6 "2022-02-23T02:45:50Z")
Just so you know, you shouldn’t see downtime when you update secrets any more.