Even if you try and use best practices, the whole ship is just LEAKY!
For example you store your secrets in the env. Well your program crashes and the log capture software dumps the entire env, or it’s included in some crash report.
You have to combine that with some kind of assurances that the window that an key leak happens over is pretty finite, otherwise you can leak one key and not notice and you've lost your redundancy and you're no better off. And you may make incident response mistakes due to a false sense of security when you're made aware that the second key leak has happened.
So, you really need to be doing everything else correctly first and can't use that to fix sloppy key management and monitoring/prevention.
I’m the founder so naturally a bit biased, but with EnvKey[1] you can get pretty strong assurances by using IP restrictions. Even if an attacker gets hold of an ENVKEY token (used to fetch and decrypt an app’s secrets), if you lock it down to the IP range of your severs, they’ll only be able to use it if they can get inside your servers (at which point you are fully compromised regardless). Just getting the key by itself isn’t enough.
I think this is about as good as you can do, honestly, since even using something along the lines of short-lived certs, you still have secrets to protect, and you lose the ability to easily do immediate revocations.
For example you store your secrets in the env. Well your program crashes and the log capture software dumps the entire env, or it’s included in some crash report.
Leaks from every corner.