>_ hackerrepos search repos…

← top repos

getsops/sops

Simple and flexible tool for managing secrets

▲ 8 hackers recommend 3 strongly Go ★ 24k MPL-2.0 awsazuredevopsgcppgpsecret-distribution

Recommended between 2025-10-13 and 2026-08-28. Last pushed 2026-11-02.

▲ 8 recommend · ▼ 0 criticisms

What hackers say

“I personally like sops[1].”

— nebezb, 2026-08-28 · strong recommendation · original comment on Hacker News ↗

show original comment

… hope. As patmorgan23 wrote in another comment "Secrets should go in a vault and retrieved with the help of a workload identity." Secrets management unfortunately isn't as easy as config management. I personally like sops[1]. [1] https://github.com/getsops/sops

“I’ve been using sops”

— dgellow, 2026-05-21 · strong recommendation · original comment on Hacker News ↗

show original comment

I’ve been using sops: https://github.com/getsops/sops

“This software has done this for years”

— Zizizizz, 2026-02-24 · strong recommendation · original comment on Hacker News ↗

show original comment

https://github.com/getsops/sops This software has done this for years

“It would be nice to use something like SOPS[1] + age right from the start”

— epistasis, 2026-05-19 · original comment on Hacker News ↗

show original comment

…s for grabbing and moving data. I use LLMs on both of them extensively (having an LLM setup all my proxmox VMs and LXC containers and configure them without doing that yak shaving has been amazing.) It would be nice to use something like SOPS[1] + age right from the start, so I don't feel like I need to go rotate all those keys. It's one thing to have it stored locally on your own box, and another to have it off in the training data of a hugely-overvalued gigantic corporation that's going to do anything it can to survive in the coming years. [1] https://github.com/getsops/sops

“use sops + age [1] or dotenvx [2] (or similar) to encrypt just the values.”

— ctmnt, 2026-02-24 · original comment on Hacker News ↗

show original comment

… leak accidentally, secrets go into env variables (which are exposed and often leak). Which of those do you care about? What are you trying to prevent? At the simplest level, keeping .env-ish files, use sops + age [1] or dotenvx [2] (or similar) to encrypt just the values. You keep the .env file approach, the actual secrets are encrypted, and now you can check the file in and track changes without leaking your secrets. You still have the env variable problems. There are some options that'll use virtual files to get your secrets from a vault to your process's env variables, or you can read the secrets from a secret manager yourself into env variables, but that feels like more complexity wit…

“SOPS reduces the surface area you need to cover.”

— CGamesPlay, 2025-12-13 · original comment on Hacker News ↗

show original comment

SOPS reduces the surface area you need to cover. You can use Age as a backend and then you only need a long lived private key on the server. https://github.com/getsops/sops

“I think parent is referring to something like SOPS [0], which can pass secrets via FIFO.”

— sgarland, 2025-10-13 · original comment on Hacker News ↗

show original comment

I think parent is referring to something like SOPS [0], which can pass secrets via FIFO. That way, there’s nothing on disk, the pipe is cleared after first read, and /proc/cmdline doesn’t reveal anything. 0: https://github.com/getsops/sops

“SOPS can be part of the solution. It takes care of encrypting and decrypting config files.”

— matthew16550, 2025-10-13 · original comment on Hacker News ↗

show original comment

SOPS can be part of the solution. It takes care of encrypting and decrypting config files. https://github.com/getsops/sops

Badge for your README

hackers recommend badge
[![hackers recommend](https://hackerrepos.org/badge/getsops/sops.svg)](https://hackerrepos.org/repo/getsops/sops)