SOPS: encrypting YAML, JSON, ENV, INI and binary files in place
Simple and flexible tool for managing secrets
At a glance
- What is it?
- SOPS is a Go-based editor of encrypted files that keeps the structure of YAML, JSON, ENV, INI and binary files readable while encrypting the values, using AWS KMS, GCP KMS, Azure Key Vault, HuaweiCloud KMS, age or PGP. This review covers how it works, how to install it, and where it stops being the right tool.
- Who is it for?
- SOPS fits teams that already store configuration in Git and want encrypted values to stay in the same file as the plaintext keys. It is the wrong tool if you need a server that hands out secrets at runtime, or if your configuration is not file-shaped at all.
- Can I use it commercially?
- Yes, with conditions. MPL-2.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem SOPS solves: secrets that live next to the config they belong to
Most teams keep application configuration in a file that is committed to Git. Somewhere in that file there is an API key, a database password, or a signing key. The usual answers are to keep the whole file out of the repository, to split secrets into a separate store, or to encrypt the entire file so that nobody can read the non-secret parts either.
SOPS takes a fourth route. It is, in the README's words, an editor of encrypted files that supports YAML, JSON, ENV, INI and BINARY formats. The keys of a YAML or JSON document stay in plaintext and the values are encrypted. A reviewer can open a diff and see that a database host changed without being able to read the password. That is the whole point of the design, and it is also the source of most of its constraints.
The audience is infrastructure and platform engineers who already treat configuration as code. The topics list on the repository includes aws, azure, gcp, pgp, secret-distribution, secret-management, security and sops, which matches the shape of the tool: it is a client-side file transformer, not a service. There is no SOPS server to run, no daemon, and no API to call at application startup. Whatever reads the file has to decrypt it, either through the sops binary or through a library that understands the format.
How the encryption actually works: a data key wrapped by one or more key services
The repository layout makes the architecture visible. There are separate top-level directories named aes, age, azkv, gcpkms, hckms, hcvault, kms, keys, keyservice, pgp and shamir. Each of those is a key source or a cryptographic primitive, and they are peers rather than layers. The README lists the supported backends explicitly: AWS KMS, GCP KMS, Azure Key Vault, HuaweiCloud KMS, age, and PGP.
The data flow follows from those directories. SOPS generates a data key, encrypts the plaintext values with it using AES, and then stores the data key in the file's metadata, wrapped once per recipient or per key service. On decryption, SOPS reads the metadata, asks each configured key source to unwrap the data key, and uses the recovered key to decrypt the values. The metadata block is what makes the file self-describing: it records which key services were used and the encrypted data key, so a file encrypted with age and a file encrypted with AWS KMS are both valid SOPS files with different metadata.
The keyservice directory and the shamir directory are the two places where this gets more interesting than a simple wrapper. A keyservice suggests an out-of-process key provider, and shamir indicates threshold splitting, where the data key is reconstructed from a subset of shares. Neither is documented in the README, which points to getsops.io under "Docs" instead, so treat the directory names as a map of what exists rather than as a description of the interface. The hcvault directory, combined with the HashiCorp Vault API dependency in go.mod, shows that Vault is supported as a key source even though the README's backend list does not name it.
The dependency list is a fair picture of the operational surface. The AWS SDK v2 modules for KMS, S3, STS and credentials appear alongside the Azure azidentity and azkeys packages, the Google Cloud KMS and storage packages, the HuaweiCloud SDK, filippo.io/age, and ProtonMail/go-crypto for PGP. Adopting SOPS means accepting whichever of those credential chains you actually use.
Installing SOPS and encrypting a first YAML file
The repository's Makefile exposes an install target that builds the CLI from source with the Go toolchain:
make installThat target runs go install on github.com/getsops/sops/v3/cmd/sops, so the binary lands in your Go bin directory. The Makefile pins GOPROXY to https://proxy.golang.org for that build. The README itself does not give install instructions; it points to getsops.io under "Docs", and the repository ships a .goreleaser.yaml, which is the usual sign that prebuilt release binaries exist.
Once the binary is on your PATH, the first real use is a configuration file that tells SOPS which key to use for which path. The repository keeps a .sops.yaml at its root, and the config directory holds the parsing logic for it. The repository also ships examples/all_in_one/ and examples/per_file/, which are the directories to read before writing your own rules. The README does not print the schema of that file; the docs site at getsops.io is where it is described.
With the configuration in place, the workflow is a round trip. Run sops on a file and it opens in your editor with the values decrypted and re-encrypts them on save. That round trip is what the tool is built around, and it is why the encrypted file stays in the repository rather than being generated at deploy time. The README does not list the individual command-line flags for encrypting or decrypting, so read the docs site before scripting either operation.
Where SOPS stops: rotation, key loss and the metadata error
The most common failure people hit is a file that SOPS refuses to touch because it cannot find the metadata block. The related searches include "Sops metadata not found", which is the error you get when you point SOPS at a file that was never encrypted by it, or when the metadata was stripped by a YAML formatter or a templating step that rebuilt the document. Because the metadata carries the wrapped data key, losing it means losing the ability to decrypt, not just a cosmetic problem.
The second limitation is key rotation. SOPS can re-wrap the data key for new recipients without re-encrypting the values, but that is a property of the metadata design, not a feature the README advertises. The README does not document rollback, and it does not describe a rotation procedure. If your compliance model requires periodic re-encryption of the ciphertext itself rather than re-wrapping of the data key, you are outside what the documentation covers.
The third is that SOPS is the wrong tool when the secret needs to reach a process that has no file and no credential chain. A container that starts with a read-only filesystem and no cloud identity cannot decrypt anything. SOPS assumes the consumer either has the sops binary and credentials, or links a library that does. Teams that want a runtime API returning a secret over HTTP are looking at a different category of tool, and SOPS will not grow into one.
Finally, the plaintext keys are a real information leak in aggregate. Encrypting values while leaving keys readable means an attacker who obtains the encrypted file learns your schema: service names, environment names, feature flags. That is usually an acceptable trade for reviewable diffs, but it is a trade, and the README does not discuss it.
SOPS compared with HashiCorp Vault: file transformer versus secret server
The natural alternative is HashiCorp Vault, and the difference is architectural rather than a matter of feature lists. Vault is a server. It stores secrets, enforces policy on who may read which path, issues short-lived credentials, and keeps an audit log of every access. Applications authenticate to it and fetch what they need at runtime.
SOPS is a client-side file transformer. There is no server, no policy engine, and no audit log of reads. Access control is delegated entirely to the key service: whoever can call AWS KMS Decrypt on the right key, or holds the age private key, can decrypt the file. That is a strength when your access control already lives in IAM or in a key file, and a gap when you need per-secret policy or an access trail.
The two are not mutually exclusive, and the repository hints at that. The hcvault directory and the hashicorp/vault/api dependency in go.mod mean Vault can serve as a key source for SOPS, so a team can keep the encrypted file in Git while the data key is wrapped by Vault. That is a middle path: the file is reviewable, and unwrapping the data key goes through Vault's policy and audit machinery. The README does not describe this configuration, so it has to be learned from the docs site rather than from the repository front page.
Maintenance, release cadence and what MPL-2.0 means for adopters
The repository is not archived, and the last push was on 2026-09-18. The most recent release listed is v3.13.3 on 2026-07-23, preceded by v3.13.2 on 2026-06-30 and v3.13.1 on 2026-05-16. That is a steady patch cadence of roughly one release every six to eight weeks over the visible window, with no major version bump in the list.
The project's governance is worth noting because it affects upgrade risk. The README states that SOPS was initially launched as a project at Mozilla in 2015 and was donated to the CNCF as a Sandbox project in 2023, now under a separate group of maintainers. Sandbox is the earliest CNCF maturity stage, and the README does not describe a graduated roadmap. For an adopter, that means the project is not abandoned, but it also means the maintainer group is the thing to check rather than an assumed corporate backer.
Upgrade cost is mostly a Go module question. The go.mod declares go 1.25.8 and pulls cloud SDKs at specific versions, so anyone building from source inherits those pins. The Makefile's default target runs test, vet, generate, install and functional-tests, and there is a separate origin-build target that adds functional-tests-all, which suggests the full functional suite is heavier than the default. If you vendor the binary rather than the library, upgrades are a binary swap plus a re-read of the CHANGELOG.md at the repository root.
The licence is MPL-2.0, a file-level copyleft licence. Modifying SOPS source files obliges you to publish those modified files under the same licence; using the binary alongside your own proprietary code does not. That is a summary of the licence identifier, not legal advice, and the LICENSE file at the repository root is the authoritative text.
Editorial conclusion
SOPS fits teams that already store configuration in Git and want encrypted values to stay in the same file as the plaintext keys. It is the wrong tool if you need a server that hands out secrets at runtime, or if your configuration is not file-shaped at all. Before adopting it, verify which key service you can actually authenticate against, check that your .sops.yaml creation rules match the paths you will encrypt, and confirm the MPL-2.0 licence is acceptable to your legal reviewers.
Frequently asked questions
How do I use SOPS?
You install the CLI, define creation rules in a .sops.yaml file that map path patterns to key services or recipients, then run sops on a file to open it in your editor with values decrypted and re-encrypted on save. The README describes SOPS as an editor of encrypted files supporting YAML, JSON, ENV, INI and BINARY formats.
How do I decrypt with SOPS?
SOPS recovers the data key from the file's metadata by asking the configured key service, such as AWS KMS, GCP KMS, Azure Key Vault, HuaweiCloud KMS, age or PGP, so you need credentials for whichever backend was used at encryption time. The README does not print the individual decrypt flags, so check the docs site at getsops.io.
How do I create a SOPS file?
The key service used is determined by the creation rules in your .sops.yaml, which is the configuration file the repository keeps at its root, and the examples/all_in_one/ and examples/per_file/ directories show worked examples. The README does not list the exact encryption flags, so read the docs site before scripting this.
What is SOPS' age support?
age is one of the encryption backends the README lists alongside AWS KMS, GCP KMS, Azure Key Vault, HuaweiCloud KMS and PGP. The repository has a top-level age directory and depends on filippo.io/age, so age recipients can be named in the creation rules of a .sops.yaml.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/getsops-sops)
Community notes