Is this for security reasons? If that’s the case, I have a hard time understanding why, because anyone that has access to fly secrets list also has access to fly ssh console and can run printenv in that shell.
In fact, I wrote a small Python script to easily view the values:
Would be nice if I could just use fly secrets for this.
Our API doesn’t have access to the contents of secrets. When you set a secret through the API, we seal it in a software HSM, to which our API server has no access (we currently store an authenticator tag of the secret so you can match them up between apps, but I’m dubious about the value of this feature and lobbying to get rid of it).
You can, of course, recover secrets by SSH’ing into an app, or, for that matter, deploying a new version of your code that simply logs the secret in plaintext; at the end of the day, something has to be able to see the secret, even if I would prefer that we implement pure write-only secrets instead. 
What you should expect from us moving forward is work on tightening secrets even further, both by restricting who can SSH to things (that’s coming soon!) and also by tightening the default environment an SSH session drops you into. The goal is to make it difficult to casually recover^H^H^H^Hexfiltrate a secret, bearing in mind that the primary thing people do with Fly.io is deploy new code on it, and code is generally always going to get secret access.
I’m not sure if you’re familiar with vercel but their secrets are also obfuscated but you’re able to de-obfuscate in the ui and change them, I think this is a happy medium of keeping it secure while also keeping the DX nice
I understand the convenience of that feature! But the design we have amplifies the convenience of reasoning about the security of our API, which we also deeply value. Our API can’t recover secrets at all, because it doesn’t store them.
