# Cum rulezi aplicația local fără fișiere .env
doppler run -- npm run dev
# Cum injectezi secretele într-un Dockerfile la runtime (nu la build!)
# Folosești Doppler CLI ca entrypoint
FROM node:18
RUN (curl -Ls --tlsv1.2 --proto "=https" --retry 3 https://cli.doppler.com/install.sh || wget -qO- https://cli.doppler.com/install.sh) | sh
WORKDIR /app
COPY . .
ENTRYPOINT ["doppler", "run", "--"]
CMD ["node", "dist/index.js"]Am lucrat acum doi ani la un proiect cu vreo 12 microservicii și o echipă de 8 developeri. La început, totul era „simplu”: aveam un fișier .env.template în repo, îl copiai, puneai cheile de la Stripe sau AWS și aia era. Problema a apărut când am început să rotim cheile de API sau când un coleg nou avea nevoie de acces. Ne trezeam că stăm câte 30 de minute pe Slack dând copy-paste la valori, de parcă eram la piață, nu la o firmă de tech. Nu mai zic de riscul imens să dai un paste greșit în canalul public sau să uiți să cureți un buffer.
Cea mai mare greșeală pe care o văd și acum e stocarea secretelor în plain text în variabilele de CI/CD (GitHub Actions, GitLab CI). Da, sunt criptate „at rest”, dar mentenanța e un coșmar. Dacă ai 3 medii (dev, staging, prod), ajungi să gestionezi zeci de variabile manual. Am pățit-o la un deployment de vineri seară: am uitat să updatez o cheie de SendGrid în staging și am stat două ore să înțeleg de ce nu pleacă mailurile de test, deși codul era identic cu cel din local.
Doppler: de ce e „cheat code” pentru DX
După faza aia, am băgat Doppler. Ce mi-a plăcut la ei e simplitatea: instalezi un CLI, dai doppler login și apoi doppler setup. Din momentul ăla, nu mai ai niciun .env local. Rulezi doppler run -- npm start și variabilele sunt injectate direct în procesul aplicației. La proiectul de care ziceam, am economisit cam 30% din timpul de onboarding pentru colegii noi. În loc să-i explicăm unde sunt cheile de la Redis, îi dădeam acces la proiect în dashboard și gata.
Trade-off-ul e evident: dacă pică Doppler (rar, dar se poate întâmpla), build-urile tale din CI/CD s-ar putea să aibă probleme dacă nu ai un fallback. Plus că e încă un serviciu pe care plătești lunar. Pentru o echipă mică, merită fiecare cent doar pentru liniștea că nu ajung secretele pe GitHub din greșeală.
1Password Secrets Automation și mizele mari
Pe de altă parte, am folosit 1Password Secrets Automation la un client din zona de fintech unde securitatea era literă de lege. Acolo nu aveam voie cu „încă un tool de startup”. 1Password e tanc, dar e mult mai rigid. Trebuie să configurezi un „Connect Server” (un container care rulează în infrastructura ta) ca să poți extrage secretele programatic.
E mult mai safe pentru că secretele nu părăsesc perimetrul tău în plain text, dar setup-ul e mult mai greoi. Dacă Doppler e pentru viteză, 1Password e pentru compliance și audit. Dacă ești într-o corporație care oricum folosește 1Password pentru managerierea parolelor, e pasul logic, chiar dacă te vei lupta puțin cu CLI-ul lor care e mai puțin intuitiv decât cel de la Doppler.
Rotația secretelor și injectarea în producție
Cea mai mare problemă rămâne rotația. Majoritatea zic „rotim cheile la 90 de zile”, dar nimeni nu o face manual pentru că e periculos. Aici intervine magia acestor tool-uri. Poți schimba cheia de DB în dashboard și, cu un restart la pod-urile de Kubernetes, noua valoare e propagată peste tot.
Un sfat de „pățit”: nu injectați niciodată secretele la build-time în Docker images. E o gaură de securitate imensă pentru că oricine are acces la imagine poate să dea un docker inspect sau să vadă straturile imaginii și să scoată variabilele. Folosiți mereu injectarea la runtime, fie prin Doppler, fie prin servicii native ca AWS Secrets Manager sau HashiCorp Vault dacă aveți infrastructură complexă.
La final de zi, orice e mai bun decât un fișier .env uitat pe un server de staging cu permisiuni 777. Voi cum vă gestionați secretele când echipa trece de 5 oameni?