Git-friendly encryption, not a secret server
SOPS solves a specific problem exceptionally well: keeping secret-bearing configuration beside code without committing readable credentials. For YAML, JSON, ENV, and INI files, it encrypts values while leaving keys visible. A database password becomes ciphertext, but reviewers can still see that the file contains a database section and which entry changed. Binary files are supported too, although they are encoded as one encrypted blob.
That design preserves much of what makes Git useful. Changes to separate structured values produce separate encrypted edits, and two branches can often merge unless they touched the same field. Teams can also configure a Git text conversion filter to view authorized diffs in cleartext locally.
SOPS does not store secrets in a running service. Each file contains an encrypted data key, wrapped for one or more configured recipients. Those recipients can be AWS, Google, Azure, or Huawei cloud key services, HashiCorp Vault or OpenBao, age identities, or PGP keys. Anyone with an accepted identity can recover the data key and decrypt the values. That makes SOPS a file workflow with external trust anchors, not a replacement for a secret manager that issues leased database accounts or serves values over an API.
The everyday workflow is pleasantly small
Once keys are ready, the happy path is excellent. Run sops edit file.yaml; SOPS decrypts into an editor and encrypts again when the editor closes. It can also encrypt or decrypt through standard output, update one path with set, remove one with unset, extract a subtree, or operate in place. These commands fit shell scripts and CI pipelines without requiring an SDK or daemon.
A repository-level .sops.yaml removes repeated flags. Creation rules match file paths and assign recipients, so development and production files can use different KMS keys or age recipients. The first matching rule wins. updatekeys brings existing files in line with those rules, while rotate creates a new data key and reencrypts values. Key groups can require access across more than one group, useful when a single person or provider should not be enough.
The danger is that concise commands can make the surrounding policy look simpler than it is. Teams must decide who owns decryption identities, how CI receives them, which paths use which recipients, and how lost or compromised keys are removed. The documentation recommends removing a compromised recipient before rotating the data key, then rotating the actual passwords and tokens afterward. That sequence deserves a runbook, not memory.
Clear structure creates a real privacy tradeoff
Leaving keys unencrypted is the feature that makes structured diffs possible, but it can disclose meaningful metadata. Names such as stripe_live_key, customer identifiers, internal hostnames used as keys, or the shape of a sensitive deployment remain visible. SOPS can selectively encrypt or leave values clear through suffixes, regular expressions, and comments, yet these controls still need careful review. If the schema itself is confidential, encrypt the file as a binary blob or choose a different storage model.
The cryptography does not remove identity risk either. The security guide is direct that a compromised cloud identity can gain access to the relevant KMS key, while mishandled PGP private keys weaken the whole arrangement. Cloud KMS simplifies centralized permission control, but decryption then depends on correct provider credentials and service access. Age is simpler for offline use, but the team owns private-key distribution and recovery.
Configuration deserves defensive testing
Creation rules are powerful enough to cause serious mistakes. They are evaluated in order, with the first match selected. An open issue demonstrates two overlapping rules where only the first rule applies, leaving fields expected by the second rule in cleartext, and asks SOPS to warn users. Another open report says a shared rule containing forward slashes can fail on Windows because matching uses native path separators. The documentation also notes that config discovery starts from the current working directory rather than the encrypted file's directory.
These are not reasons to reject SOPS, but they change the rollout checklist. Add fixtures for every rule, assert that expected fields contain ENC[...], test from the same working directories CI uses, and run tests on Windows if developers use it. Avoid overlapping patterns. A lint step is cheaper than discovering a readable production value in Git history.
Batch automation has another small rough edge. A long-running open request asks for decrypting multiple input files into one YAML stream. Today, callers that want a glob must loop, use shell composition, or rely on an integration. The single-file interface stays predictable, but Kubernetes users applying many encrypted manifests will notice the omission.
Mature, active, and worthy of trust with guardrails
SOPS began at Mozilla in 2015 and became a CNCF Sandbox project in 2023. The repository was pushed on August 10, 2026, open issues were still being updated on August 11, and version 3.13.3 shipped on July 23. GitHub's open count combines issues and pull requests, so 437 is a work queue, not a defect count. The latest release publishes binaries and Debian and Alpine images, plus signed checksums, container signatures, provenance, and software bills of materials.
The documentation covers all major identities, editing operations, rule configuration, key management, publishing, and the threat model. Some history shows through, and a fresh issue criticizes the redesigned site's findability, but the material needed to operate the tool is present.
Use SOPS when encrypted files in Git are a conscious architectural choice. It offers a better review and merge experience than whole-file encryption, broad choice of identity backends, and a small operational footprint. Do not mistake that small footprint for automatic secret governance. With tested creation rules, protected identities, CI checks, and a written rotation process, SOPS remains the strongest general-purpose tool in this category.