Turn on the server (optional) phase 3¶

You want the server when you want a record of reads, coordination for automated credential rotation, or lower-latency access than a git fetch. You do not need it for anything else.

# the server holds no keys and no secrets; it needs the repo and a signing key
docker run --read-only --user 65534 \
  -e SECRETSMGR_ORG=acme \
  -e SECRETSMGR_REPO=git@git.example.com:acme/secrets.git \
  -e SECRETSMGR_AUDIT_SINK=... \
  ghcr.io/<you>/secretsmgr-server:1.0

Then point clients at it:

secretsmgr configure --mode server --server https://secrets.example.com

That is the entire migration. No re-encryption, no export, nothing about the repository changes. Switching back is the same command with --mode serverless.

Operational notes worth knowing:

• One server serves one organization. It refuses to start otherwise. If you run several organizations, run several containers behind one load balancer. The server is stateless and tiny, so this is cheap, and it keeps two trust boundaries from sharing a process.
• Redeploy it regularly, daily if you can. Nothing on it is worth keeping, so a rebuild evicts anything that should not be there.
• Ship the audit log off the box to somewhere append-only. A log that only exists on the machine being attacked is not evidence.
• If it goes down, switch clients to serverless mode and keep working. You lose read auditing and rotation until it is back. Practise this once so you are not learning it during an outage.