On Lazy Secrets Management · @radekmie’s take on IT and stuffOn Lazy Secrets Management<br>By Radosław Miernik · Published on 30 June 2026 · Comment on RedditTable of contents<br>IntroLazy but secureWhat about CI?Password managersClosing thoughtsIntro<br>If the monitor you’re looking at right now has a sticky note with any of your passwords – please, get rid of it (note, not monitor) and change that password. This text can wait, don’t worry.Now, how bad is doing the same in your Git repository? I bet some of you still commit a full .env file, even though you know it’s not a good idea. Or maybe you don’t (yay!), but when a new team member is onboarded, you send them it via Slack or email? In the end, they have to somehow get it, right?If none of the above apply to you, congratulations, you’re either doing the bare minimum… Or are paranoid enough to share passwords exclusively in-person and take time to burn the message afterward.In this text, we’ll talk about the bare minimum, though.Lazy but secure<br>Here’s my take: insecurities are usually a result of either incompetence or laziness. While I can’t directly help you with the former (your manager probably won’t listen to me, sorry), let me suggest something for the latter.You see, I’m lazy as well… Then our amazing DevOps Engineer made me aware of sops. In short, you can keep your .env in-tree, but instead of simple plain text, you keep an encrypted version of it. In practice, it’s as easy as:sops encrypt --in-place .env<br>And that’s literally it – .env is now encrypted and can be safely committed. But before you do so, you have to configure the identities of people who should be allowed to decrypt it. As we’re lazy, we’ll stick to age, a simple modern PGP alternative. And we do it for one reason: it supports SSH keys1:# .sops.yaml<br>creation_rules:<br>- age:<br>- ssh-rsa AAAAB3NzaC1yc2EA...2VF<br>From now on, every newly onboarded team member has to be added to the creation_rules.age list, and a freshly re-encrypted version of .env has to be committed, so they can access it (check out sops updatekeys). And how do you get the SSH keys of your team members? Ask them to add them to GitHub and go to github.com/${username}.keys (here are mine). GitLab also works.What about CI?<br>You may think that the above solution breaks if you need the keys in your CI pipeline. No, it’s just one more age key added in the list of recipients, plus making sure it’s in the SOPS_AGE_KEY during sops decrypt:# GitHub Actions example.<br>jobs:<br>steps:<br>- name: Decrypt secrets<br>run: sops decrypt --in-place .env<br>env:<br>SOPS_AGE_KEY: ${{ secrets.age_key }}<br>This example assumes you know about secrets in GitHub Actions. If you don’t, then again, take your time and read it. Then move all of your hardcoded secrets there. Your AWS region is fine; the account ID probably too.Password managers<br>If you can’t do the above for any reason, consider keeping secrets in some sort of secure vault. Password managers are great – take your time to pick one and really stick to using it. Oh, and check for the recent breaches before making your decision (1, 2).Modern password managers also support API access! If you want, you can keep the secrets in there and leverage them to load your secrets directly from it in your GitHub Actions (e.g., 1Password docs, Dashlane docs).Most of them also have some sort of a CLI, making it relatively easy to share some ad hoc thing with your team members. But age is also a great choice, assuming they’re technical enough to use it:age --encrypt --passphrase --output secret.txt.age secret.txt<br>age --decrypt secret.txt.age<br>Now you can securely send them secret.txt.age however you want and yell the password loud enough. Or agree on a password beforehand. Or use the SSH keys if you sit too far to talk to each other. There are plenty of options.Closing thoughts<br>Sometimes doing the bare minimum is really hard, I know. Especially if you got used to doing something else for years. But as we get hit with a new bunch of compromised packages every single week (1, 2, 3), storing fewer secrets in plain text may be a good idea.Oh boy, what’s next? Encrypting secrets in the database?1The deal with all kinds of encryption is that it’s hard to teach people how to manage their keys. At the same time, due to Git, most developers are aware of SSH keys and have them configured. I hope they don’t share it, though.