# Injectare secrete la runtime fără fișiere pe disc
# Varianta 1: Doppler CLI
doppler run -- node dist/server.js
# Varianta 2: 1Password CLI (folosește un template fără valori sensibile)
# Fișierul env.template conține: DATABASE_URL="op://Production/db/connection_string"
op run --env-file=env.template -- node dist/server.js
# Sincronizare directă în GitHub Actions (Doppler)
# doppler setup --no-interactive --project my-app --config prdAcum vreo doi ani, un junior din echipă a comis din greșeală un fișier .env de producție într-un repo privat. Nimic dramatic la prima vedere, până când repo-ul a fost forcat de un contractor extern. În mai puțin de 24 de ore ne-am trezit cu cheia de Stripe folosită din India și serverele de AWS blocate pentru trafic suspect. Atunci am decis că e momentul să eliminăm complet fișierele .env stocate ca fișiere fizice pe servere sau în CI/CD.
În postarea asta vreau să compar două soluții pe care le-am folosit intensiv în producție — Doppler și 1Password Secrets Automation — și cum gestionăm azi rotația cheilor fără downtime.
Doppler: DX impecabil, dar dependență de SaaS
Am introdus Doppler pe un proiect cu 15 microservicii și vreo 40k utilizatori activi. Înainte, dacă schimbam un secret de SendGrid, trebuia să intru în 15 pipeline-uri de GitHub Actions și pe 3 servere de staging să dau update manual. Salvam un fișier, uitam de altul.
Cu Doppler, injectezi secretele direct în proces la runtime, fără să le scrii pe disc. Au un CLI extrem de rapid și integrări native cu Vercel, AWS ECS și GitHub Actions. Sincronizează instant toate mediile (dev, staging, prod) și ai audit log complet pe orice schimbare.
Trade-off-ul? E un SaaS extern dedicat. Dacă pică API-ul Doppler exact când faci un autoscaling pe Kubernetes, te bazezi pe caching-ul făcut de CLI-ul lor local. Dacă ai infrastructură air-gapped sau cerințe enterprise hiper-stricte, s-ar putea să te lovești de reticența echipei de securitate.
1Password Secrets Automation: Ieftin dacă ai abonament, dar cu overhead
La alt client care plătea deja abonament de 1Password Business, managementul n-a vrut să mai adauge încă un vendor pe listă. Așa că am configurat 1Password Connect Server — un container Docker pe care îl rulezi tu în infrastructură — și am folosit CLI-ul lor în pipeline-uri.
Marele avantaj e că nu plătești nimic în plus dacă ești deja în ecosistemul lor, iar datele rămân criptate în seiful vostru existent. Permisiunile se gestionează la nivel de seif (Vault), exact cum ești obișnuit din interfața lor web.
Trade-off-ul e că setup-ul inițial e mult mai clunky decât la Doppler. Trebuie să administrezi tu containerul de Connect, să gestionezi jetoanele de acces și să configurezi manual maparea variabilelor. Pentru proiecte mici, mi se pare un overhead de infrastructură inutil.
Injecție la runtime și rotație fără downtime
Regula noastră de aur acum e simplă: nicio cheie secretă nu atinge discul în plain text. În producție, injectăm totul direct în memorie la pornirea procesului Node.js sau Go.
Când vine vorba de rotația cheilor (de exemplu, database credentials sau API keys), procesul pe care îl aplicăm are trei pași:
- Generăm o cheie nouă în serviciul țintă (ex: Stripe), păstrând-o pe cea veche activă (dual-key window).
- Actualizăm valoarea în Doppler sau 1Password.
- Dăm un rolling restart la containere. Aplicația preia automat noua cheie din memorie, iar după ce verificăm logurile că totul e stabil, revocăm cheia veche.
Prin abordarea asta am eliminat complet incidentele legate de leak-uri pe Git și am economisit cam 4 ore pe lună pe care le pierdeam cu debug-ul de configurări greșite între medii.
Voi ce folosiți în producție pentru secrets? Păstrați vechiul Vault de la HashiCorp sau ați trecut pe soluții SaaS mai ușoare?