Repository navigation
Feature request: Support decrypting multiple files at a time #945
Description
It would be awesome if sops supported decrypting multiple files at a time.
Use case: For example, say you have multiple encrypted Kubernetes secrets that you'd like to apply all at once, this could be streamlined as:
sops -d secrets/*.enc.yml | kubectl apply -f -
This would be much easier than having to manually specify each file individually, one at a time. This would also require that sops be able to concatenate each file using the --- document delimiter in the resulting YAML stream.
Activity
jaythamke commentedon Nov 1, 2021
Would be nice input and I am also looking forward to it.
By the way any update here? Thanks
narasimhan-coverwallet commentedon Apr 12, 2022
Hello! This is something that would be really nice, for batch operations that include not just for applying on kubernetes. For example, searching en masse when almost all the infra is captured in IaC
LucasVanHaaren commentedon Jun 17, 2022
I agree, it would be very nice to have this feature !
BlacCello commentedon Aug 2, 2022
It would be very helpful to have the support for multiple files for
sops exec-envas well. Currently, we have to nest multiple exec-env commands which is not very clean.beejei commentedon Apr 13, 2023
OMG, I started to use SOPS 2 days before, and I think I'm arriving at the right place.
+1 from my side!
This will make the usage a lot easier especially when specifying decryption on my package.json script
CyberHippo commentedon Jun 9, 2023
+1 as well, that would be awesome
fnayou commentedon Apr 22, 2024
+1 that will be really helpful
vring0 commentedon Jul 18, 2024
+1
maulerjan commentedon Nov 26, 2024
+1 this would simplify my nx scripts a lot
Cristobal-M commentedon Nov 21, 2025
+1
This would help me to, I've multiple projects to manage. I'm using a script to ease management of env variables, that script decrypts recursively a directory into a temporary location and opens a new window of vscode.
It would do it faster If I can pass a batch of files. I think I may create a local tool with a GUI (inspired from infisical) if I had the time.
jgonera commentedon Dec 19, 2025
Another benefit: it would probably be faster when using KMS because we don't have to refetch the same key for each file (if they are encrypted with the same one). This would be really beneficial for Cloud Run (and similar platforms) cold starts. Right now I decrypt secrets on container start and this adds a few seconds to cold starts.
felixfontein commentedon Dec 20, 2025
Since SOPS doesn't fetch keys, but asks the KMS to decrypt the file's encryption key (which is different for every file), this won't help for the reason you mentioned. But it will help for setting up the connection to the KMS, since it only has to do that (and authenticate) once.
I guess the main question for this one is how the user interface should look like. I can imagine multiple use cases:
I can imagine that all three cases will be useful (likely for different persons :) ). Also I would not integrate it into the
decryptsubcommand, to avoid making it more complex than it needs to be. One or more new subcommands (potentially different ones for the different use-cases) sound like a better idea to me.jgonera commentedon Dec 22, 2025
@felixfontein I didn't know the inner workings of KMS, but it completely makes sense that the key would never leave the servers. It would be great to speed this up in any way! Personally, I use JSON so I'd love to see this work for multiple formats.
almaceleste commentedon Jul 5, 2026
Another use case is Docker Compose with several services, each requiring its own secrets file - or even several such files.
czxtm commentedon Aug 10, 2026
@felixfontein for now, if all it did was act like it was called twice, for example:
just behaved like:
that would probably be very easy to implement and still save me a ton of hassle.
For the sake of simplicity I suggest that initially, then the more intricate stuff can be implemented over time.
abd-ulbasit commentedon Oct 17, 2026
I'm working on the smallest slice of this:
sops exec-envwith several files, as czxtm proposed above. PR: #2324 (it refs this issue and does not close it).Shape:
sops exec-env [flags] FILE [FILE...] COMMAND. Every positional argument except the last is a file, and the last is the command, run through the shell as today. Any call with three or more positional arguments currently fails witherror: missing file to decrypt, so no working invocation changes meaning.exec-env FILE -- 'cmd'keeps working.Behaviour:
exec-envcalls: on a key collision the later file wins. File values still override the inherited environment, and--pristineand--same-processwork as before.exec-env a.yaml --pristine b.yaml cmdreaches sops asb.yaml a.yaml cmd. Today that already breaksexec-env file.yaml --pristine cmd. With several files it would silently flip precedence, so theexec-envhelp text in the PR says so.Not in this PR:
exec-file(it substitutes one path for{}, so several files need one placeholder each),decryptwith several files (@felixfontein, you suggested new subcommands for that, so I'm leaving that design to you), and reusing the KMS connection across files.One question: this shape takes the positional tail that #1469 asks for.
sops exec-env secrets.env -- cat foowould try to decryptcat, so a later argv mode would need an explicit flag like the--no-shellyou suggested in #1626. If you'd rather keep the tail free, I can move the extra files to a repeatable flag.