Feature request: update secrets for next deployment

1

I often want to deploy new code together with new secrets, but not have those happen independently. It would be great to update secrets for the following deployment.

4 Likes
2

This is definitely a weak spot of our secrets <-> environment variables setup. We should be able to fix this down the road.

I’ve worked around this by having an [env] block in my app config that lets me rotate secrets. Basically, fly secrets set MY_SECRET_2=asdf, and then something like this config:

[env]
MY_SECRET_KEY=MY_SECRET_2

The app needs to know about this indirection, but it works reasonably well in a pinch.

3

Just wanted to check to see if there was an updated workflow to this? I know that set is being used for adding one-off secrets, but if we could have something where we run flyctl secrets set-all --from-file .env, that would be super helpful.

In the above scenario, that would remove all secrets and replace them with the secrets found in .env (or by supplying it from STDIN).

To do the equivalent with existing commands I’d need to do something like:

  • flyctl secrets list
    (write a script to parse the keys)
  • flyctl secrets unset [INSERT KEYS HERE]
  • flyctl import (via stdin)

Just a thought!

4

No update just yet… we’re discussing steps that will enable this kind of atomicity, but nothing concrete as of now.

5

Thanks for letting me know! Not a big problem but great to hear that it’s being discussed

1 Like
6

@kurt could you explain a bit more about your solution?

For each secret you have as well an [env] variable set within the config, and then just point the env variable to the env secret?

e.G. I have an “AWS_ACCESS_TOKEN” so I would call:

flyctl secrets set AWS_ACCESS_TOKEN_V1=abcd

and then within my config:

[env]
AWS_ACCESS_TOKEN=AWS_ACCESS_TOKEN_V1

and if I want to update the secret I set it first to a new version, e.G. AWS_ACCESS_TOKEN_V2 and then with the next code deployment change the [env] pointer to the new version?

If yes, why does the app then needs to know about this?

Would love to have this handled by flyctl somehow. I just ran into the issue that I wasn’t able to deploy a new version of my app because of some conflict between code and secrets so it always reverted back to the oldest working version.

7

@kurt would be nice if the fly deploy --env also accepted stdin env pairs like fly secrets import. For example, I have a script that fetches secrets, getSecrets.sh | fly deploy --envs

1 Like
8

Current secret set has a --stage flag.

  --stage           Set secrets but skip deployment for machine apps
1 Like