# Instalezi CLI-ul Doppler local
curl -Ls https://cli.doppler.com/install.sh | sh
# Te autentifici și configurezi proiectul
doppler login
doppler setup
# Rulezi aplicația injectând secretele direct în memorie
doppler run -- node server.jsAm lucrat acum doi ani la o aplicație cu vreo 15.000 de utilizatori activi și vreo 12 microservicii. La început, clasic: fiecare serviciu cu .env-ul lui, copiat prin SSH sau trimis pe Slack (știu, groaznic, dar toți am făcut asta la un moment dat). Evident, într-o vineri seară, un coleg a uitat să adauge o variabilă nouă de Stripe în producție. Rezultatul? Jumătate de oră de checkout-uri eșuate și panică generală. Atunci am zis gata.
De ce crapă abordarea clasică cu .env
Problema cu fișierele .env pe servere nu e doar securitatea, deși să ai chei private de AWS în plain text pe un VPS e de groază. Problema reală e sincronizarea. Când ai 5 developeri și 3 medii de rulare (dev, staging, prod), e absolut imposibil să ții totul aliniat manual.
Iar când vine vorba de rotația cheilor, e și mai rău. Schimbarea unei parole de bază de date înseamnă SSH pe 3 instanțe, modificat manual fișierul, restart la procese și speranța că nu crapă nimic pe parcurs. Dacă ai și serverless în ecuație (cum avem noi pe AWS Lambda), e un coșmar și mai mare să actualizezi zeci de funcții individual.
Doppler vs 1Password Secrets Automation
După incidentul cu Stripe, am testat mai multe soluții. Am rămas la Doppler pentru majoritatea proiectelor, iar pentru un client de tip enterprise am integrat 1Password Secrets Automation.
Doppler e genial pentru că e gândit nativ pentru developeri. Practic, înlocuiești clasicul npm start sau python main.py cu doppler run -- npm start. CLI-ul lor injectează variabilele direct în memorie, ca procese de mediu, fără să scrie nimic fizic pe disc. Am economisit cam 4 ore pe lună de om doar din eliminarea debugging-ului de tipul „la mine pe mașină merge, dar în staging nu”.
Trade-off-ul sincer: Doppler e un serviciu terț, pe bază de abonament. Dacă au ei downtime (s-a întâmplat o singură dată anul trecut, timp de vreo 10 minute), build-urile tale din CI/CD pot eșua dacă nu ai configurat corect fallback-ul local criptat pe care îl oferă CLI-ul lor.
La polul opus, 1Password Secrets Automation e excelent dacă firma folosește deja 1Password pentru parolele echipei. Totul e centralizat în seifurile existente. Totuși, integrarea e destul de greoaie pentru că trebuie să rulezi un "Connect Server" (un container de Docker în propria infrastructură) care face bridge între API-ul lor și aplicația ta. Pentru o echipă mică, e prea mult overhead de mentenanță.
Cum facem rotația cheilor fără downtime
Regula de aur pe care am învățat-o pe pielea mea după ce am blocat accesul la un API extern: nu schimba niciodată o cheie direct.
Rotația sigură se face mereu în trei pași:
- Generezi o cheie nouă în serviciul terț (acum ai două chei active în paralel).
- Actualizezi managerul de secrete (Doppler/1Password) și declanșezi un rolling restart la aplicație. Serviciul va începe să folosească noua cheie.
- Revoci cheia veche din dashboard-ul serviciului terț abia după 24 de ore, când te-ai asigurat din loguri că nu mai există niciun request care o folosește.
Voi cum gestionați secretele în echipă? Încă folosiți fișiere .env trimise pe Slack sau ați trecut la o soluție centralizată?