Decide secrets management: encrypted-in-repo vs out-of-band

[koinsaari]

Summary

The repo has .env, netbird/config.yaml, and netbird/dashboard.env all gitignored and maintained by hand on the host. There's no source of truth for what values are live, and a fresh-host rebuild requires reconstructing them from memory / scattered notes.

Context

Two reasonable patterns for a single-host, single-operator setup:

1. Out-of-band, manual: secrets live in a password manager (Proton Pass note holding the full .env contents). Fresh host = copy-paste from the note. Zero tooling. The repo and the secrets never meet.
2. Encrypted in git (SOPS + age): secrets live in the repo as secrets/*.sops files, encrypted with an age key. The age key lives on the host (and as a DR copy in the password manager). Fresh host = git clone && sops -d > .env. Slight tooling, but git log becomes the audit trail and CI can decrypt for deploys.

Option 2 is the prerequisite for the deploy workflow being able to provision a fresh host without manual paste-from-vault. Option 1 keeps the moving-parts count minimum.

Scope

• Pick one
• If SOPS:
  • Add .sops.yaml, secrets/ dir, encrypt .env + netbird/config.yaml + dashboard.env
  • Update README.md deploy steps
  • Update deploy.sh (or equivalent) to decrypt at deploy time
  • Document age key DR copy location
• If password-manager note:
  • Document the note path in README.md so future-me knows where to look
  • Keep .example files as the schema reference

Acceptance criteria

• Decision recorded in docs/ with rationale
• Fresh-host deploy procedure validated end-to-end (might pair with Verify setup.sh works on a fresh VPS #3)

Notes

Decision affects the deploy workflow's design. Worth resolving before that workflow is built, even if implementation is deferred. If undecided, default to the password-manager note (less rope) and revisit when the deploy workflow forces the question.