Von dotenv zu dotenvx – der Config-Manager der nächsten Generation

• Seit dem ersten Commit von dotenv im Juli 2013 hat es sich in 11 Jahren zu einem der weltweit meistgenutzten Pakete entwickelt
• Es hat eine ähnliche Stellung erreicht wie unverzichtbare Software wie TypeScript und ESLint

Die Probleme von dotenv

• Risiko, dass .env-Dateien offengelegt werden
• Multi-Environment-Setups sind schwer zu verwalten
• Fehlende Konsistenz zwischen Plattformen

Die Lösung: dotenvx

• Funktioniert auf allen Plattformen identisch
• Unterstützung für mehrere Umgebungen
• Verschlüsselung von Umgebungsvariablen-Dateien

Läuft überall

• Funktioniert in allen Sprachen, Frameworks und auf allen Plattformen gleich
• Mit dotenvx run -- your-cmd lassen sich Umgebungsvariablen zur Laufzeit injizieren
• .env-Parsing-Engine, Variablen-Erweiterung und Command Substitution verhalten sich überall identisch
• Installation auf verschiedene Arten möglich, darunter npm, brew, curl, docker und windows

  $ echo "HELLO=World" > .env  
  $ echo "console.log('Hello ' + process.env.HELLO)" > index.js  
  $ node index.js  # ohne dotenvx  
  Hello undefined  
  $ dotenvx run -- node index.js  # mit dotenvx  
  Hello World  
  

Unterstützung für mehrere Umgebungen

• Nach dem Erstellen einer .env.production-Datei kann sie mit der Option -f geladen werden
• Mit mehreren -f-Flags lassen sich Multi-Environment-Konfigurationen aufbauen

  $ echo "HELLO=production" > .env.production  
  $ dotenvx run -f .env.production -- node index.js  
  [dotenvx][info] loading env (1) from .env.production  
  Hello production  
  

Verschlüsselung

• Mit dem Befehl dotenvx encrypt wird einer .env-Datei Verschlüsselung hinzugefügt
• Verwendet Public-Key-Kryptografie
• Selbst wenn die .env-Datei offengelegt wird, ist eine Entschlüsselung ohne DOTENV_PRIVATE_KEY nicht möglich
• In Open-Source-Projekten können neue Konfigurationen hinzugefügt werden, ohne vorherige Secrets zu entschlüsseln

  $ dotenvx encrypt  
  ✔ encrypted (.env)  
  

Release von Version 1.0.0

• Die Veröffentlichung von dotenvx 1.0.0 wurde angekündigt
• Viele Entwickler dürften es als Config-Management-Tool der nächsten Generation nutzen können

---

Meinung von GN⁺

• dotenvx bietet Sicherheit und Komfort zugleich
• Die einfache Verwaltung mehrerer Umgebungen ist für Entwickler besonders nützlich
• Die Verschlüsselungsfunktion ist besonders hilfreich für sicherheitssensible Projekte
• Die Funktionen von dotenvx sorgen in verschiedenen Sprachen und auf unterschiedlichen Plattformen für Konsistenz und steigern so die Entwicklungseffizienz

[yangeok]

Im Programm muss man also nicht mehr zwischen Produktiv- und Entwicklungsmodus unterscheiden, sondern kann das direkt im Ausführungsskript deklarieren.

[GN⁺]

Hacker-News-Kommentare

• Es ist besser, keine Geheimnisse über Umgebungsvariablen weiterzugeben. Umgebungsvariablen können leicht offengelegt werden. Stattdessen sollte man Geheimnisse innerhalb des Prozesses aus einem Vault oder dem Dateisystem lesen.

• Der Grund für die Verwendung von .env-Dateien ist, dass sie einfach und klar sind. Wenn man sicherere und leistungsfähigere Konfigurationsmethoden nutzen will, muss man die Dokumentation lesen.

• Ich habe angefangen, bei der Arbeit Mise zu verwenden. Ich habe es noch nicht viel genutzt, aber es sieht vielversprechend aus. Es erledigt Aufgaben wie das Initialisieren lokaler Testdatenbanken und das Ausführen von Linting-Skripten und verwaltet außerdem Umgebungsvariablen und virtuelle Umgebungen.

• Da das Offenlegen von Geheimnissen ein großes Problem ist, ist es klug, Geheimnisse bei der Verwendung von dotenvx zu verschlüsseln. Ein Tool, das unverschlüsselte Geheimnisse nicht unterstützt, ist sicherer.

• Es ist ähnlich wie Sops, hat aber standardmäßig keine Verschlüsselungsfunktion. Sops lässt sich leicht in AWS und bestehende Schlüsselverwaltungslösungen integrieren und war nach meiner Erfahrung in zwei Unternehmen über fünf Jahre hinweg sehr gut.

• Es ist bequem, Geheimnisse verschlüsselt zu committen, aber wenn jemand Zugriff auf den Verschlüsselungsschlüssel hat, können alle Geheimnisse offengelegt werden. Es ist sicherer, sie im Secret Manager einer Cloud-Umgebung zu hinterlegen und danach nicht mehr anzufassen.

• Umgebungsvariablen werden zu breit geteilt, und Dateien hängen von lokalen Berechtigungen ab. Wir brauchen eine neue Methode, um Geheimnisse zwischen Prozessen zu übertragen. Zum Beispiel, indem man Geheimnisse über einen Unix-Socket so weitergibt, dass sie nur einmal gelesen werden können.

• Es braucht eine Dokumentation dazu, wie man .env-Dateien korrekt in einen Vault legt. Wenn der Vault durch ein Passwort geschützt ist, entsteht das Problem, dass man im Klartext festhalten muss, wie die Anwendung das Vault-Passwort lesen kann.

• Ich möchte alle Umgebungsvariablen in einer einzigen Datei im TOML-Format verwalten. Dadurch würden Aktualisierung, Vergleich und Teilen einfacher. Aber es ist schwierig, die Konsistenz der Umgebungsnamen aufrechtzuerhalten. Das entsteht oft durch schnelle Entscheidungen oder akute Notwendigkeiten, und man scheut sich davor, es zu korrigieren.