[Feature]: Support SOPS-encrypted secret files as a secrets source

[yosimasu]

Before submitting

• I have searched existing feature requests and discussions to confirm this has not been requested

Problem or motivation

Many teams already manage their secrets with SOPS, keeping encrypted secrets.enc.yaml / .enc.env files committed to the repo and decrypted at use-time via age / KMS / PGP. This gives them version history, PR review of secret changes, and a single source of truth shared across the team.

Today Devsy's secrets live only on the local machine (OS keyring or the age-encrypted secrets.enc in the Devsy config dir). To use them in Devsy, a team member has to re-enter each secret with devsy secrets set, which means the values are duplicated outside the team's existing SOPS workflow and drift over time. I'd like Devsy to be able to consume a SOPS-encrypted file directly as a secrets source, so the repo stays the source of truth and nothing has to be re-keyed by hand.

Proposed solution

Add SOPS as a first-class secrets source that Devsy decrypts and injects, reusing the existing env / mount injection paths.

Rough shape (open to alternatives):

• A new source/backend, e.g. devsy secrets add --sops ./secrets.enc.yaml (or a sops: entry referenced from config.yaml), that records a reference to the file rather than copying the plaintext.
• At workspace start, Devsy runs SOPS decryption and injects the resulting keys as type=env and/or writes them as type=mount files under /run/secrets/…, exactly like existing secrets — same masking in logs, same encrypted agent tunnel, same tmpfs handling.
• Decryption key material comes from the environment SOPS already understands (SOPS_AGE_KEY_FILE / SOPS_AGE_KEY, ~/.config/sops/age/keys.txt, cloud KMS via ambient creds). Devsy shouldn't need to store the decryption key itself.
• Natural synergy: Devsy's file backend already uses age, and SOPS supports age too — so an existing age identity could be reused.

Alternatives considered

• Decrypt-then-import manually (sops -d file | ... piped into devsy secrets set): works today but re-duplicates the values, loses the git-as-source-of-truth benefit, and has to be redone on every change.
• Just use the existing age file backend: encrypts at rest locally, but the encrypted file isn't the team's repo-committed SOPS file, so it doesn't integrate with an existing SOPS/GitOps workflow.
• A generic "external command" secrets source (run an arbitrary decrypt command): more flexible but less safe/ergonomic than first-class SOPS support; could be a superset if preferred.
• How others handle it: tools like direnv (sops exec-env), Docker Compose + sops, and Kubernetes sops/ksops all treat a committed SOPS file as the canonical secrets source.

Area

• CLI
• Providers (secrets)
• Dev containers

Acceptance criteria

• User can register a SOPS-encrypted file as a secrets source (e.g. devsy secrets add --sops ./secrets.enc.yaml) without the plaintext being copied into Devsy's store
• On workspace start, keys from the decrypted file are injected as env and/or mount secrets, with the same log masking and tmpfs behavior as native secrets
• age, KMS, and PGP-encrypted SOPS files are supported via the standard SOPS key discovery (env vars / key file / ambient cloud creds)
• A decrypt failure (missing key, bad file) fails the workspace start with a clear, non-leaking error
• Documented under the secrets docs

Additional context

SOPS: https://github.com/getsops/sops — Related to Devsy's existing age-encrypted file backend, which could share the age identity.