Shared Secrets / Environments

What’s the best way to set secrets to be re-used by multiple apps.

For example, a preview app generated from a pull-request which needs several secrets to be set before the first deployment, copied from a static staging environment.

Not all of these are even secret, but because it seems the only way to define non-secret environment variables is via fly.toml, it’s no good for multiple environments, something that’s pretty critical to delivering stable software.

Overall I’m impressed with fly but I have a few concerns on how enjoyable it is to use once you get beyond a trivial use-case.

2 Likes

Probably not the answer you’re looking for, but I found it helpful to use Doppler for this purpose. I set configs in Doppler, I add a single secret to each app (doppler API key) and have it pull down env variables from Doppler

Unsure what the best way is, but this is what we do: The relatively static shared secrets (like, api tokens) all come from github repository secrets, which are deploy to “multi-env” Fly apps via github-actions.

The shared but dynamic secrets (like oft-rotating private keys), are generated / downloaded into github-actions, decrypted if needed (the decryption key is static, stored with github), and then deployed to “multi-env” Fly app.

:wink:

I wanted to chime in with a potential solution and a request.

The solution: you could have a shim job that reads in Env secrets and other environment variables and then remaps the environment before spawning a subprocess and exiting.

The request: it would be helpful if the fly.toml contained a section that lets you remap secrets to named environment variables. Then I wouldn’t need to run this shim job.

1 Like