Optional Infisical integration for self-host secrets management

[JSONbored]

Context

The self-host stack's only secrets mechanism today is a plaintext .env file consumed via Docker Compose's env_file:/environment: blocks — no rotation, no audit trail, no RBAC, and (until the native Docker Compose secrets: migration lands) values are visible in docker inspect/process-env dumps. That native secrets: migration (file-mounted secrets, not exposed via docker inspect) is the immediate, zero-dependency hardening step and is being done separately/first — this issue is the follow-on for operators who want real secrets-manager-grade rotation/audit/RBAC on top of that.

Infisical is the best fit among the options considered (Doppler, 1Password, Bitwarden Secrets Manager, HashiCorp Vault): it has a genuinely open-source, self-hostable server (not just a SaaS CLI), matching gittensory's self-host-first ethos — an operator who's already self-hosting gittensory can self-host Infisical too, point at Infisical Cloud instead, or skip it entirely and keep using .env/Docker secrets.

Requirements

1. Make this strictly optional and additive — the default path (.env + Docker Compose secrets:) must keep working unchanged for every operator who doesn't opt in. No new mandatory dependency.
2. Wire Infisical via its infisical run -- <start command> wrapper at the deploy-script level (injects secrets as env vars at process launch) rather than touching application code — this is Infisical's own intended integration shape and requires zero changes to how src/ reads env.SOMETHING.
3. Gate the wrapper behind an explicit opt-in (e.g. a flag/var in the deploy script, checked before deciding whether to prefix the start command with infisical run --).
4. Document self-host setup end-to-end: pointing at Infisical Cloud vs. a self-hosted Infisical instance, project/environment mapping, and how this interacts with the existing .env/Docker secrets (Infisical-sourced vars should take priority when both are present, or the docs should say explicitly not to mix them).

Deliverables

• Deploy script support for an optional infisical run -- wrapper, opt-in only.
• Self-host docs: setup walkthrough (cloud and self-hosted Infisical), and explicit guidance on not mixing it with plain .env for the same variables.
• Verified end-to-end against a real Infisical project (secrets actually resolve into the running container).

Expected outcomes

Self-host operators who want secrets rotation, audit logging, and RBAC can opt into Infisical without gittensory forcing that dependency — or the signup/trust relationship with a third party — on operators who are happy with the hardened .env/Docker-secrets default.

Cross-reference (added 2026-07-12)

See also #4922 (ORB: centralized custody for AI-provider keys, in ORB Cloud Readiness) and #5225 (AMS: centralized secrets custody across hosted tenants, in the new AMS Cloud Readiness milestone). All three are converging on the same underlying secrets-management question from different angles (self-host opt-in vs. centralized hosted custody) — whoever designs the centralized approach should read this issue's self-host Infisical plan first to avoid two divergent secrets-handling stories.

[linear-code]

JSO-3675