Env Example Checker · Config
Erfassen Sie die Umgebungsvariablen, die in Ihrer .env.example fehlen.
Fügen Sie Ihren Code und Ihre .env.example ein, um die Umgebungsvariablen zu finden, die Ihr Code liest, die Beispieldatei aber auslässt — sowie Schlüssel, die von nichts gelesen werden — vollständig in Ihrem Browser.
Env Example Checker Playground
Processed entirely in your browser — contents are never uploaded.
Tip: press Esc to release focus.
No share links on this tool — inputs may be secrets.
Load an example or paste your own code and .env.example, then check to see which variables drifted.
Die Lücke
.env.example weicht immer ab.
Eine neue Variable landet im Code und in Ihrer lokalen .env — und die .env.example, die Datei, die tatsächlich ins Repository eingecheckt und von jedem Teammitglied kopiert wird, bleibt stillschweigend zurück. .env wird von Git ignoriert, sodass nichts Sie warnt. Diese Abweichung der Umgebungsvariablen zwischen Code und Konfiguration bleibt unsichtbar, bis jemand das Projekt klont und die Anwendung an einem fehlenden Schlüssel abstürzt, oder fehlende Umgebungsvariablen eine CI-Pipeline lahmlegen, weil eine benötigte Variable nie dokumentiert wurde.
Dies mit bloßem Auge über eine weitläufige Codebasis hinweg zu prüfen, ist genau die Art von mechanischem Abgleich, den ein Werkzeug erledigen sollte. Dieser Checker liest in beide Richtungen zugleich: Er listet die Variablen auf, die Ihr Code verwendet, die Beispieldatei aber auslässt — jene, die einen frischen Checkout zerschießen — und die Schlüssel, die die Beispieldatei noch deklariert, die aber von nichts gelesen werden, damit Sie die veralteten mit Zuversicht entfernen können.
Möchten Sie es zuerst sehen? Springen Sie zu den beiden Eingaben oder probieren Sie das Live-Playground oben aus.
Die Pipeline
So funktioniert es.
Fünf deterministische Schritte gleichen Ihren Code mit Ihrer Beispieldatei ab — jedes Mal vollständig in Ihrem Browser-Tab.
-
Den Code durchsuchen.
Ihr Quellcode wird auf jeden Lesezugriff auf Umgebungsvariablen durchforstet — process.env, os.environ, $NAME und den Rest.
-
Die Beispieldatei parsen.
Ihre .env.example wird als KEY=value-Zeilen gelesen, wobei Kommentare und Leerzeilen übersprungen werden, und in eine Schlüsselmenge überführt.
-
Die beiden Mengen abgleichen.
Die im Code verwendeten Namen werden mit den in der Beispieldatei deklarierten Schlüsseln verglichen, in beide Richtungen zugleich.
-
Die Lücken aufzeigen.
Verwendete, aber nicht deklarierte Variablen werden als fehlend markiert; deklarierte, aber nicht gelesene Schlüssel werden als ungenutzt markiert.
-
Beheben & erneut prüfen.
Fügen Sie die fehlenden Schlüssel zu Ihrer Beispieldatei hinzu, entfernen Sie die veralteten und führen Sie die Prüfung erneut aus, bis der Bericht sauber ist.
Die Eingaben
Zwei Eingaben, beide vertraut.
Der Checker liest genau zwei Dinge: Ihren Anwendungscode und Ihre .env.example. Wenn Sie schon einmal eines von beiden geschrieben haben, werden Sie sich gleich heimisch fühlen.
Der Code
Jeder Quellcode, der Umgebungsvariablen liest. Der Scanner erkennt process.env.NAME und import.meta.env.NAME in Node / Vite, os.environ["NAME"] / os.getenv("NAME") in Python, os.Getenv("NAME") in Go sowie schlichtes $NAME in der Shell.
// server.ts
const port = process.env.PORT ?? '3000';
const dbUrl = process.env.DATABASE_URL;
const apiKey = process.env["STRIPE_SECRET_KEY"];
if (!dbUrl) {
throw new Error('DATABASE_URL is required');
}Die .env.example
Standardmäßige dotenv-Zeilen — KEY=value pro Zeile, wobei #-Kommentare und Leerzeilen ignoriert werden. Für den Abgleich sind nur die Schlüsselnamen relevant, Platzhalterwerte sind also in Ordnung. Dies ist die Datei, die Ihre Teammitglieder in eine echte .env kopieren.
# .env.example
PORT=3000
DATABASE_URL=postgres://localhost:5432/app
# STRIPE_SECRET_KEY is used in server.ts but
# was never added here — the checker flags it.
# Declared below but nothing reads it — flagged as unused.
LEGACY_FEATURE_FLAG=falseDemnächst verfügbar
Lassen Sie den Build bei Abweichungen scheitern.
Der Browser-Checker ist Schritt eins. Eine sofort einsatzbereite CLI führt denselben Abgleich über Ihr Repository in der CI aus, sodass ein vergessener Eintrag in der .env.example den Build scheitern lässt, statt das erste git clone eines Teammitglieds zu zerschießen.
Eine hauseigene GitHub Action, die die CLI umschließt, ist begleitend dazu geplant. Beide sind demnächst verfügbar — der Checker im Browser oben funktioniert schon heute.
# Coming soon — the same check in CI
$ envcheck ./src --example .env.example
✗ Missing from .env.example (1)
STRIPE_SECRET_KEY used in src/server.ts
! Unused in .env.example (1)
LEGACY_FEATURE_FLAG
1 missing, 1 unusedEin Hinweis zum Umfang
So funktioniert die Erkennung: Der Checker erkennt Lesezugriffe auf Umgebungsvariablen anhand ihrer gängigen, wörtlichen Zugriffsmuster — process.env.NAME, os.environ["NAME"], $NAME und dergleichen. Namen, die zur Laufzeit dynamisch gebildet werden (zum Beispiel process.env[someVariable]), lassen sich nicht statisch auflösen und erscheinen daher nicht in der Menge der verwendeten Variablen. Behandeln Sie einen sauberen Bericht als starke Bestätigung, dass Ihre dokumentierte Konfiguration zu Ihrem Code passt — und überfliegen Sie dennoch alle dynamisch berechneten Zugriffe von Hand.
FAQ
Fragen, beantwortet.
Tippen Sie auf eine Frage, um die Antwort aufzuklappen.
Was macht der Env Example Checker?
Er vergleicht die Umgebungsvariablen, die Ihr Code tatsächlich liest, mit den Schlüsseln, die in Ihrer .env.example deklariert sind. Fügen Sie beides ein, drücken Sie auf „Check", und es werden zwei Lücken gemeldet: Variablen, die im Code verwendet werden, aber in der Beispieldatei fehlen (jene, die einer neuen Entwicklerin oder einem frischen Deployment zum Verhängnis werden), und Schlüssel, die in der Beispieldatei deklariert sind, aber von nichts gelesen werden (veraltete Einträge, die sich zu entfernen lohnen). Alles wird in Ihrem Browser berechnet.
Verlassen mein Code oder meine .env.example jemals meinen Browser?
Nein. Der Checker läuft zu 100 % clientseitig. Ihr Quellcode und Ihre Beispieldatei werden in Ihrem Browser-Tab geparst und verglichen — nichts wird auf einen Server hochgeladen, und es gibt weder Konto noch Anmeldung. Sie können bedenkenlos internen Code und Konfigurationsschlüssel einfügen.
Welche Sprachen und Zugriffsmuster erkennt er?
Er erkennt die gängigen Arten, auf die Code Umgebungsvariablen liest, über die populären Ökosysteme hinweg — process.env.NAME und process.env["NAME"] in Node und TypeScript, import.meta.env.NAME in Vite, Deno.env.get("NAME") in Deno, os.environ["NAME"] / os.getenv("NAME") in Python, ENV["NAME"] / ENV.fetch("NAME") in Ruby, os.Getenv("NAME") in Go, System.getenv("NAME") in Java sowie getenv / $_ENV["NAME"] in PHP. Die .env.example-Seite wird als standardmäßige KEY=value-Zeilen geparst, wobei Kommentare und Leerzeilen ignoriert werden.
Warum weicht .env.example überhaupt vom Code ab?
Eine neue Variable wird dem Code und der lokalen .env hinzugefügt, aber die .env.example — die Datei, die ins Repository eingecheckt und von Teammitgliedern kopiert wird — wird vergessen. Die Abweichung bleibt unsichtbar, bis jemand das Projekt klont, die Beispieldatei kopiert und die Anwendung an einem fehlenden Schlüssel abstürzt, oder bis ein Deployment scheitert, weil eine benötigte Variable nie dokumentiert wurde. Dieses Werkzeug deckt diese Abweichung auf, bevor sie ausgeliefert wird.
Kann es erkennen, welche fehlenden Variablen erforderlich und welche optional sind?
Es meldet jede Variable, die der Code liest und die die Beispieldatei nicht deklariert; ob eine bestimmte Variable zwingend erforderlich ist, kann nur Ihr Code beurteilen (ein Standardwert als Rückfalloption kann sie optional machen). Behandeln Sie die Liste der fehlenden Variablen als die Menge, die zu prüfen und zu dokumentieren ist — fügen Sie jede mit einem sicheren Platzhalter oder einem Kommentar, der sie als optional kennzeichnet, in die .env.example ein.
Wie finde ich Umgebungsvariablen, die im Code verwendet werden, aber in der .env.example fehlen?
Fügen Sie Ihren Quellcode in das Code-Panel und Ihre .env.example in das Template-Panel ein und drücken Sie dann auf „Check". Der Checker durchsucht den Code nach allen Referenzen auf Umgebungsvariablen — process.env.X, os.getenv("X"), import.meta.env.X und ähnliche Muster — und vergleicht diese Menge mit den Schlüsseln in Ihrer .env.example, wobei jede Variable aufgelistet wird, die der Code liest, die Beispieldatei aber nicht deklariert.
Wie finde ich ungenutzte Schlüssel in meiner .env.example-Datei?
Der Checker führt den Abgleich gleichzeitig in beide Richtungen durch. Neben dem Bericht über fehlende Schlüssel listet er außerdem jeden Schlüssel auf, den Ihre .env.example deklariert, der aber im eingefügten Code nicht vorkommt, damit Sie veraltete oder übrig gebliebene Variablen gefahrlos entfernen und das Template schlank und korrekt halten können.
Wie verhindere ich, dass fehlende Umgebungsvariablen CI oder Deployments lahmlegen?
Führen Sie diesen Checker vor dem Commit aus, damit jede Variable, die Ihr Code liest, die Beispieldatei aber auslässt, frühzeitig erkannt wird. Wenn Sie die .env.example mit dem Code synchron halten, erhalten CI-Pipelines und Teammitglieder ein vollständiges Template, was bedeutet, dass die Anwendung schon zur Konfigurationszeit schnell fehlschlägt, statt zur Laufzeit mit dem Fehler einer undefinierten Variable abzustürzen. Eine CLI-Version für automatisierte Prüfungen in der CI ist geplant.
Was ist der Unterschied zwischen dem Vergleich zweier .env-Dateien und der Prüfung gegen den Code?
Der Vergleich von .env mit .env.example stellt zwei Konfigurationsdateien einander gegenüber — er weiß nur, welche Schlüssel jede Datei deklariert. Dieser Checker liest stattdessen den tatsächlichen Quellcode, um zu erfahren, welche Variablen wirklich verwendet werden, sodass er Variablen erkennt, die der Code benötigt, die aber in jeder Konfigurationsdatei fehlen, und Beispielschlüssel markiert, die der Code nie berührt. Genau diese Unterscheidung macht ihn nützlich, um die Abweichung von Umgebungsvariablen zwischen Code und Konfiguration aufzuspüren — nicht nur zwischen zwei Konfigurationsdateien.
Ist dies ein offizielles Werkzeug für irgendein Framework?
Nein. Dies ist ein unabhängiges Community-Werkzeug und steht in keiner Verbindung zu und wird von keinem Framework, keiner Laufzeitumgebung und keiner dotenv-Bibliothek unterstützt. Es bildet die weit verbreitete .env / .env.example-Konvention und gängige Muster für den Zugriff auf Umgebungsvariablen nur ab, um zu beschreiben, was es prüft.
More free, private DevOps tools.
Der Env Example Checker ist eines der Werkzeuge in OpsCanopy — einem wachsenden Schirm aus browserbasierten Validatoren, Konvertern und Testern, die niemals einen Server berühren.
Neu bei Docker? Zum Docker-Guide →
29 kostenlose Tools, jedes einzelne offlinefähig — opscanopy.com funktioniert ohne Registrierung, und nichts wird hochgeladen.
Validieren Sie Konfiguration und Pipelines? Kombinieren Sie dies mit dem GitHub Actions Validator, um Workflow-Probleme vor dem Push zu erkennen, oder durchstöbern Sie das vollständige Werkzeugverzeichnis.
Steht in keiner Verbindung zu und wird von keinem Framework, keiner Laufzeitumgebung und keiner dotenv-Bibliothek unterstützt. Die .env / .env.example-Konvention und die Muster für den Zugriff auf Umgebungsvariablen werden nur referenziert, um zu beschreiben, was dieses Werkzeug prüft.