davidnussio/envsecSicheres CLI-Tool zur Verwaltung von Umgebungsgeheimnissen unter Verwendung nativer Betriebssystem-Anmeldeinformationsspeicher (macOS Keychain, Linux Secret Service, Windows Credential Manager)
Sichere Verwaltung von Umgebungsgeheimnissen mit nativen Betriebssystem-Schlüsselspeichern.
myapp.dev, stripe-api.prod, work.staging)cmd speichern und erneut ausführen (durchsuchen, auflisten, ausführen, löschen).env-Dateien exportieren (mit Generierungsverfolgung über audit)eval $(envsec env)).env-Dateien laden (mit Konflikterkennung)envsec tui) zur Verwaltung von Geheimnissen ohne BefehlsauswendiglernenDieses Monorepo enthält die folgenden Pakete:
Für den programmatischen Zugriff auf Geheimnisse aus Node.js oder Bun verwenden Sie @envsec/sdk:```bash
npm install @envsec/sdk
Bitte fügen Sie den zu übersetzenden Markdown-Inhalt ein.```typescript
import { loadSecrets } from "@envsec/sdk";
// Load and inject into process.env
await loadSecrets({ context: "myapp.dev", inject: true });
// Or use the client for full control
import { EnvsecClient } from "@envsec/sdk";
const client = await EnvsecClient.create({ context: "myapp.dev" });
const apiKey = await client.get("api.key");
await client.close();
Siehe die vollständige SDK-Dokumentation für alle APIs, Multi-Kontext-Unterstützung und Optionen.
Keine zusätzlichen Abhängigkeiten. Verwendet die eingebaute Schlüsselbundverwaltung über das security CLI-Tool.
Erfordert libsecret-tools (stellt den Befehl secret-tool bereit), der über D-Bus mit GNOME Keyring, KDE Wallet oder jedem Anbieter der Secret Service API kommuniziert.```bash
sudo apt install libsecret-tools
sudo dnf install libsecret
sudo pacman -S libsecret
Eine laufende D-Bus-Sitzung und ein Keyring-Daemon (z. B. `gnome-keyring-daemon`) müssen aktiv sein. Die meisten Desktop-Umgebungen erledigen dies automatisch.
### Windows
Keine zusätzlichen Abhängigkeiten. Verwendet den integrierten Windows Credential Manager über `cmdkey` und PowerShell.
## Installation
### Homebrew (macOS / Linux)```bash
brew tap davidnussio/homebrew-tap
brew install envsec
npm install -g envsec
### npx (keine Installation)```bash
npx envsec
mise use -g npm:envsec
## Verwendung
Die meisten Befehle benötigen einen mit `--context` (oder `-c`) angegebenen Kontext.
Ein Kontext ist eine frei wählbare Bezeichnung zum Gruppieren von Geheimnissen – z. B. `myapp.dev`, `stripe-api.prod`, `work.staging`.
### Globale Optionen
Diese Optionen stehen für alle Befehle zur Verfügung:
- `--context`, `-c` — Name des Kontexts (z. B. `myapp.dev`, `stripe-api.prod`). Liest auch die Umgebungsvariable `ENVSEC_CONTEXT`
- `--debug`, `-d` — Debug-Logging aktivieren
- `--json` — Ausgabe im JSON-Format für Skripte
- `--db` — Pfad zur SQLite-Datenbankdatei (Standard: `~/.envsec/store.sqlite`). Liest auch die Umgebungsvariable `ENVSEC_DB`
### Benutzerdefinierter Datenbankpfad
Standardmäßig werden Metadaten unter `~/.envsec/store.sqlite` gespeichert. Sie können dies mit `--db` oder der Umgebungsvariable `ENVSEC_DB` überschreiben:```bash
# Use a project-local database
envsec --db ./local-store.sqlite -c myapp.dev list
# Or via environment variable
export ENVSEC_DB=/shared/team/envsec.sqlite
envsec -c myapp.dev list
Das --db Flag hat Vorrang vor ENVSEC_DB. Anwendungsfälle umfassen projektspezifische Datenbanken, teamweit geteilte Datenbanken auf Netzlaufwerken und CI/CD mit flüchtigem Speicher.
Speichern Sie ein Geheimnis im OS-Anmeldeinformationsspeicher.
<key> — Name des Geheimnisschlüssels (z.B. api.key, db.password)--value, -v — Zu speichernder Wert (weglassen für interaktive maskierte Eingabeaufforderung)--expires, -e — Ablaufdauer (z.B. 30m, 2h, 7d, 4w, 3mo, 1y)```bashenvsec -c myapp.dev add api.key --value "sk-abc123"
envsec -c myapp.dev add api.key -v "sk-abc123"
envsec -c myapp.dev add api.key
envsec -c myapp.dev add api.key -v "sk-abc123" --expires 30d
envsec -c myapp.dev add api.key -v "sk-abc123" -e 6mo
### Ein Geheimnis abrufen
Ruft einen Geheimniswert aus dem OS-Anmeldedatenspeicher ab.
- `<key>` — Schlüsselname des Geheimnisses zum Abrufen
- `--quiet`, `-q` — Nur den Rohwert ausgeben (keine Warnungen oder zusätzliche Ausgabe)
- `--json` — Ausgabe im JSON-Format (enthält Kontext, Schlüssel, Wert, expires_at)```bash
envsec -c myapp.dev get api.key
# Print only the raw value (no warnings or extra output)
envsec -c myapp.dev get api.key --quiet
envsec -c myapp.dev get api.key -q
Entfernen Sie ein Geheimnis aus dem OS-Anmeldeinformationsspeicher.
<key> — Name des Geheimnisschlüssels zum Löschen (optional, wenn --all verwendet wird)--yes, -y — Bestätigungsaufforderung überspringen--all — Alle Geheimnisse im Kontext löschen```bash
envsec -c myapp.dev delete api.keyenvsec -c myapp.dev del api.key
### Ein Secret umbenennen
Benennen Sie einen Secret-Schlüssel innerhalb desselben Kontextes um. Der Wert und die Ablaufmetadaten bleiben erhalten.
- `<alter-schlüssel>` — Aktueller Name des Secret-Schlüssels
- `<neuer-schlüssel>` — Neuer Name des Secret-Schlüssels
- `--force`, `-f` — Überschreibt das Ziel, falls es bereits existiert```bash
# Rename a key
envsec -c myapp.dev rename old.key new.key
# Overwrite target if it already exists
envsec -c myapp.dev rename old.key existing.key --force
Listet alle geheimen Schlüssel und Metadaten in einem Kontext auf.
--json — Ausgabe im JSON-Format```bash
envsec -c myapp.dev list### Alle Kontexte auflisten
Listet alle verfügbaren Kontexte mit Geheimnisanzahlen auf.
- `--json` — Ausgabe im JSON-Format```bash
# Without --context, lists all available contexts with secret counts
envsec list
Durchsuchen Sie Geheimnisse oder Kontexte mithilfe von Glob-Mustern.
<pattern> — Glob-Muster zum Durchsuchen (z.B. api.*, myapp.*)--json — Ausgabe im JSON-Format```bashenvsec -c myapp.dev search "api.*"
envsec search "myapp.*"
### Geheimnisse zwischen Kontexten verschieben
Verschiebt Geheimnisse von einem Kontext in einen anderen. Die Quell-Geheimnisse werden nach dem Verschieben entfernt.
- `<pattern>` — Glob-Muster oder exakter Schlüssel zum Verschieben (optional, wenn `--all` verwendet wird)
- `--to`, `-t` — Zielkontext, in den Geheimnisse verschoben werden sollen
- `--all` — Alle Geheimnisse aus dem Quellkontext verschieben
- `--force`, `-f` — Vorhandene Geheimnisse im Zielkontext überschreiben
- `--yes`, `-y` — Bestätigungsaufforderung überspringen```bash
# Move a single secret
envsec -c myapp.dev move api.token --to myapp.prod
# Move secrets matching a glob pattern
envsec -c myapp.dev move "redis.*" --to myapp.prod -y
# Move all secrets from one context to another
envsec -c myapp.dev move --all --to myapp.prod -y
# Overwrite existing secrets in the target context
envsec -c myapp.dev move "redis.*" --to myapp.prod --force -y
Kopiert Geheimnisse von einem Kontext in einen anderen. Die Quellgeheimnisse bleiben unverändert.
<pattern> — Glob-Muster oder genauer Schlüssel zum Kopieren (optional, wenn --all verwendet wird)--to, -t — Zielkontext, in den Geheimnisse kopiert werden sollen--all — Alle Geheimnisse aus dem Quellkontext kopieren--force, -f — Vorhandene Geheimnisse im Zielkontext überschreiben--yes, -y — Bestätigungsaufforderung überspringen```bashenvsec -c myapp.dev copy api.token --to myapp.staging
envsec -c myapp.dev copy "redis.*" --to myapp.staging -y
envsec -c myapp.dev copy --all --to myapp.staging -y
envsec -c myapp.dev copy "redis.*" --to myapp.staging --force -y
### Einen Befehl mit Geheimnissen ausführen
Führen Sie einen Befehl mit geheimen Werten aus, die über Platzhalter interpoliert oder als Umgebungsvariablen injiziert werden.
- `<command>` — Befehl, der ausgeführt werden soll. Verwenden Sie `{key}`-Platzhalter für die Interpolation von Geheimnissen
- `--inject`, `-i` — Alle Kontext-Geheimnisse als Umgebungsvariablen injizieren (`KEY.NAME` → `KEY_NAME`)
- `--save`, `-s` — Diesen Befehl für die spätere Verwendung speichern
- `--name`, `-n` — Name für den gespeicherten Befehl (wird interaktiv abgefragt, wenn es mit `--save` weggelassen wird)```bash
# Placeholders {key} are resolved with secret values before execution
envsec -c myapp.dev run 'curl {api.url} -H "Authorization: Bearer {api.token}"'
# Any {dotted.key} in the command string is replaced with its value
envsec -c myapp.prod run 'psql {db.connection_string}'
# Inject ALL context secrets as environment variables (KEY.NAME → KEY_NAME)
envsec -c myapp.dev run --inject 'node server.js'
envsec -c myapp.dev run -i 'docker compose up'
# Combine --inject with placeholders
envsec -c myapp.dev run --inject 'curl {api.url} -H "Authorization: Bearer $API_TOKEN"'
# Save the command for later use with --save (-s) and --name (-n)
envsec -c myapp.dev run --save --name deploy 'kubectl apply -f - <<< {k8s.manifest}'
# If you use --save without --name, you'll be prompted interactively
envsec -c myapp.dev run --save 'psql {db.connection_string}'
Wenn ein Platzhalter auf ein nicht vorhandenes Geheimnis verweist, wird der Befehl nicht ausgeführt und Sie sehen eine klare Fehlermeldung:``` ❌ Missing secrets in context "myapp.dev":
Add them with: envsec -c myapp.dev add
### Gespeicherte Befehle
Gespeicherte Befehle befinden sich im Unterbefehl `cmd`, um sie von geheimen Operationen getrennt zu halten.
#### cmd list
Alle gespeicherten Befehle auflisten.```bash
envsec cmd list
Führt einen gespeicherten Befehl aus (verwendet den Kontext, mit dem er gespeichert wurde).
<name> — Name des auszuführenden gespeicherten Befehls--override-context, -o — Überschreibt den gespeicherten Kontext zur Ausführungszeit--quiet, -q — Unterdrückt informative Ausgaben (gibt nur Befehlsergebnisse aus)--inject, -i — Injiziert alle Kontext-Geheimnisse als Umgebungsvariablen```bash
envsec cmd run deployenvsec cmd run deploy --quiet envsec cmd run deploy -q
envsec cmd run deploy --override-context myapp.prod envsec cmd run deploy -o myapp.prod
envsec cmd run deploy --inject envsec cmd run deploy -i
#### cmd search
Durchsucht gespeicherte Befehle nach Namen oder Befehlstext.
- `<pattern>` — Suchmuster
- `--name`, `-n` — Durchsucht nur Befehlsnamen
- `--command`, `-m` — Durchsucht nur Befehlstexte```bash
envsec cmd search psql
# Search only by name
envsec cmd search deploy -n
# Search only by command string
envsec cmd search kubectl -m
Lösche einen gespeicherten Befehl.
<name> — Name des zu löschenden Befehls```bash
envsec cmd delete deploy### Generate a .env file
Alle Geheimnisse aus einem Kontext in eine `.env`-Datei exportieren.
- `--output`, `-o` — Ausgabedateipfad (Standard: `.env`)```bash
# Creates .env with all secrets from the context
envsec -c myapp.dev env-file
# Specify a custom output path
envsec -c myapp.dev env-file --output .env.local
Keys are converted to UPPER_SNAKE_CASE (e.g. api.token → API_TOKEN).
Export-Anweisungen zur Verwendung mit eval oder Shell-Sourcing ausgeben.
--shell, -s — Ziel-Shell-Syntax: bash (Standard), zsh, fish, powershell--unset, -u — Statt Export Unset/Remove-Befehle ausgeben```basheval $(envsec -c myapp.dev env)
envsec -c myapp.dev env --shell fish envsec -c myapp.dev env --shell powershell
eval $(envsec -c myapp.dev env --unset)
envsec -c myapp.dev env --unset --shell fish
Unterstützte Shells: `bash` (Standard), `zsh`, `fish`, `powershell`. Schlüssel werden in `UPPER_SNAKE_CASE` konvertiert (z. B. `api.token` → `API_TOKEN`). Die Ausgabe erfolgt nach stdout, sodass sie an `eval` weitergeleitet oder direkt mit `source` eingelesen werden kann — es wird keine Datei auf die Festplatte geschrieben.
### Starten einer geheimnisbezogenen Shell-Sitzung
Erzeugt eine interaktive Subshell, in die alle Geheimnisse aus dem Kontext als Umgebungsvariablen injiziert werden. Wenn Sie `exit` ausführen, sind die Geheimnisse verschwunden — keine Bereinigung erforderlich.
- `--shell`, `-s` — Zu startende Shell (`bash`, `zsh`, `fish`, `powershell`). Standard: automatische Erkennung
- `--no-inherit` — Übergeordnete Umgebungsvariablen nicht übernehmen
- `--quiet`, `-q` — Start-/Beendigungsbanner unterdrücken```bash
envsec -c myapp.dev shell
(envsec:myapp.dev) ~ $ echo $DATABASE_URL postgres://user:pass@localhost/mydb
(envsec:myapp.dev) ~ $ exit → Exiting envsec shell — secrets cleared.
## Kurzbefehle```bash
# Force a specific shell
envsec -c myapp.dev shell --shell zsh
# Only envsec secrets in env (no parent variables, except PATH)
envsec -c myapp.dev shell --no-inherit
# Suppress the startup/exit banner
envsec -c myapp.dev shell --quiet
Die Variable ENVSEC_CONTEXT wird immer innerhalb der Sitzung gesetzt, sodass Sie sie in Skripten oder Prompt-Anpassungen
referenzieren können.
Importieren Sie Geheimnisse aus einer .env-Datei in einen Kontext.
--input, -i — Eingabe .env Dateipfad (Standard: .env)--force, -f — Vorhandene Geheimnisse ohne Nachfrage überschreiben--batch, -b — Batch-Modus: Datenbankpersistenz verschieben, bis alle Geheimnisse importiert sind```bashenvsec -c myapp.dev load
envsec -c myapp.dev load --input .env.local
envsec -c myapp.dev load --force
Schlüssel werden von `UPPER_SNAKE_CASE` in `dotted.lowercase` umgewandelt (z.B. `API_TOKEN` → `api.token`). Falls ein Schlüssel bereits existiert, wird er mit einer Warnung übersprungen, es sei denn, `--force` (`-f`) wird angegeben.
### Geheimnisse teilen (GPG-verschlüsselt)
Verschlüsselt alle Geheimnisse aus einem Kontext für ein Teammitglied mittels GPG.
- `--encrypt-to` — GPG-Empfängerschlüssel (E-Mail, Schlüssel-ID oder Fingerabdruck), für den verschlüsselt werden soll
- `--output`, `-o` — Ausgabedateipfad (Standard: stdout). Verwenden Sie `-` explizit für stdout
- `--json` — JSON-Format innerhalb der verschlüsselten Nutzlast verwenden (Standard: `.env`-Format)```bash
# Encrypt all secrets from a context for a team member
envsec -c myapp.dev share --encrypt-to [email protected]
# Save encrypted output to a file
envsec -c myapp.dev share --encrypt-to [email protected] -o secrets.enc
# Use JSON format inside the encrypted payload
envsec -c myapp.dev --json share --encrypt-to [email protected] -o secrets.enc
Der Empfänger kann mit gpg --decrypt secrets.enc entschlüsseln und das Ergebnis in envsec load weiterleiten. Standardmäßig verwendet die verschlüsselte Nutzlast das .env-Format (KEY="value"); mit --json verwendet sie ein strukturiertes JSON-Objekt. Erfordert, dass GPG installiert ist und sich der öffentliche Schlüssel des Empfängers in Ihrem Schlüsselbund befindet.
Überprüfen Sie auf abgelaufene oder ablaufende Geheimnisse und nachverfolgte .env-Dateiexporte.
--within, -w — Zeigt Geheimnisse an, die innerhalb dieser Dauer ablaufen (Standard: 30d). Verwenden Sie 0d, um nur bereits abgelaufene anzuzeigen--json — Ausgabe im JSON-Format```bashenvsec -c myapp.dev audit
envsec -c myapp.dev audit --within 7d
envsec -c myapp.dev audit --within 0d
envsec audit
envsec -c myapp.dev audit --json
Geheimnisse mit einer über `envsec add` festgelegten `--expires`-Dauer werden in den Metadaten nachverfolgt. Der Befehl `audit` durchsucht nach Geheimnissen, die bereits abgelaufen sind oder innerhalb des angegebenen Zeitfensters ablaufen. Die Befehle `get` und `list` zeigen ebenfalls Ablaufwarnungen inline an.
Der Befehl `audit` verfolgt auch generierte `.env`-Dateien. Jedes Mal, wenn `env-file` verwendet wird, werden der Ausgabepfad, der Kontext und der Zeitstempel aufgezeichnet. Die Audit-Ausgabe enthält einen zweiten Abschnitt, der diese Dateien auflistet. Wenn eine nachverfolgte `.env`-Datei nicht mehr auf der Festplatte vorhanden ist, entfernt audit sie automatisch aus den Metadaten und meldet die Bereinigung.
### Ein zufälliges Geheimnis generieren
Generieren Sie ein kryptografisch sicheres zufälliges Geheimnis, optional mit Speicherung.
- `<key>` — Name des Geheimnisschlüssels (optional; weglassen für eigenständige Passwortgenerierung)
- `--length`, `-l` — Länge des generierten Geheimnisses (Standard: `32`)
- `--prefix`, `-p` — Präfix, das dem generierten Geheimnis vorangestellt wird (z.B. `sk_`)
- `--expires`, `-e` — Ablaufdauer (z.B. `30m`, `2h`, `7d`, `4w`, `3mo`, `1y`)
- `--alphanumeric`, `-a` — Nur alphanumerische Zeichen verwenden `[a-zA-Z0-9]` (Standard)
- `--special`, `-s` — Häufige Sonderzeichen einbeziehen `[a-zA-Z0-9!@#$%^&*]`
- `--all-chars`, `-A` — Alle druckbaren ASCII-Zeichen für maximale Entropie verwenden```bash
# Generate and store a 32-char alphanumeric secret
envsec -c myapp.dev secret api.key
# Custom length and prefix
envsec -c myapp.dev secret api.key --prefix "sk_" --length 48
# Character sets:
# --alphanumeric (-a) [a-zA-Z0-9] (default)
# --special (-s) [a-zA-Z0-9] + !@#$%^&*
# --all-chars (-A) all printable ASCII
envsec -c myapp.dev secret db.password --special --length 64
# With expiry
envsec -c myapp.dev secret api.key --prefix "sk_" -l 48 --expires 90d
# Standalone password generator (no store, just print)
envsec secret --length 32
envsec secret --special --length 64 --prefix "pk_"
Wenn sowohl Kontext als auch Schlüssel angegeben werden, wird der generierte Wert gespeichert und ausgegeben. Ohne beides wird der rohe Wert nach stdout ausgegeben — nützlich zum Weiterleiten an pbcopy, xclip oder andere Tools.
envsec enthält eine Vollbild-Terminal-Benutzeroberfläche zum interaktiven Verwalten von Geheimnissen — kein Auswendiglernen von Befehlen erforderlich.```bash
envsec tui
envsec -c myapp.dev tui
Die TUI bietet acht über das Hauptmenü erreichbare Bildschirme:
- **Kontexte** — alle Kontexte durchsuchen, aktiven Kontext mit `s` setzen, Kontext mit `x` löschen, Geheimnisanzahl anzeigen, gesamte Kontexte löschen
- **Geheimnisse** — Geheimnisse in einer Tabelle auflisten, Werte anzeigen, Geheimnisse hinzufügen oder löschen
- **Geheimnis hinzufügen** — interaktives Formular mit maskierter Eingabe und optionaler Ablaufdauer
- **Suche** — Glob-Muster-Suche über Geheimnisse oder Kontexte
- **Gespeicherte Befehle** — gespeicherte Befehlsvorlagen auflisten, anzeigen und löschen
- **Prüfung** — nach abgelaufenen/ablaufenden Geheimnissen suchen, exportierte `.env`-Dateien überprüfen
- **.env importieren** — Geheimnisse aus einer `.env`-Datei in den aktuellen Kontext laden
- **.env exportieren** — Geheimnisse in eine `.env`-Datei exportieren (für die Prüfung nachverfolgt)
Tastaturkürzel:
| Taste | Aktion |
|-------|--------|
| `↑` / `↓` | Navigieren Sie durch Menüpunkte und Tabellenzeilen |
| `Enter` | Auswählen / bestätigen |
| `c` | Kontextansicht öffnen (Hauptmenü) |
| `s` | Ausgewählten als aktiven Kontext setzen (Kontextansicht) |
| `x` | Aktiven Kontext löschen (Kontextansicht) |
| `a` | Neues Geheimnis hinzufügen (Geheimnisansicht) |
| `d` | Ausgewähltes Element löschen |
| `r` | Geheimniswert anzeigen (Detailansicht) |
| `Esc` | Zurück / abbrechen |
| `q` | TUI beenden |
### Diagnose für Ihr Setup
Führen Sie Gesundheitschecks aus, um Ihre envsec-Installation zu überprüfen.
- `--json` — Ausgabe im JSON-Format für Skripte```bash
# Run all health checks
envsec doctor
# JSON output for scripting
envsec --json doctor
Der Befehl doctor überprüft, ob Ihre envsec-Installation korrekt funktioniert. Er prüft:
ENVSEC_DB, ENVSEC_CONTEXT)envsec unterstützt dynamische Tab-Vervollständigung für bash, zsh und fish. Vervollständigungen sind kontextbewusst: Sie schlagen Ihre tatsächlichen Kontextnamen, Secret-Schlüssel und gespeicherten Befehlsnamen in Echtzeit vor, indem sie die Metadaten-Datenbank abfragen.```bash
eval "$(envsec --completions bash)"
eval "$(envsec --completions zsh)"
envsec --completions fish | source
Was dynamisch vervollständigt wird:
- `--context` / `-c` — listet alle Ihre Kontexte auf
- Secret-Key-Argumente (`get`, `add`, `delete`) — listet Schlüssel für den aktuellen Kontext
- `cmd run` / `cmd delete` — listet gespeicherte Befehlsnamen
- `--override-context` / `-o` — listet Kontexte für `cmd run`
- Unterbefehle, Flags und statische Auswahlen (Shells usw.) werden ebenfalls vervollständigt
## Vergleich
Wie schlägt sich envsec im Vergleich zu anderen Tools zur Verwaltung von Umgebungsgeheimnissen?
| Feature | envsec | dotenv / dotenvx | 1Password CLI (`op`) |
|---|---|---|---|
| Geheimnisspeicherung | Betriebssystem-Anmeldeinformationsspeicher (Keychain, Secret Service, Credential Manager) | `.env`-Dateien auf der Festplatte (dotenvx fügt Verschlüsselung hinzu) | 1Password Cloud Vault |
| Verschlüsselung im Ruhezustand | An das Betriebssystem delegiert (Keychain, GNOME Keyring, DPAPI) | Keine (dotenv) / ECIES pro Datei (dotenvx) | AES-256 in der 1Password Cloud |
| Geheimnisse auf der Festplatte | Niemals — Werte gehen direkt in den OS-Anmeldeinformationsspeicher | Immer — `.env`-Dateien sind standardmäßig Klartext | Niemals lokal (werden zur Laufzeit aus der Cloud abgerufen) |
| Offline-Zugriff | Vollständig — Geheimnisse sind lokal im OS-Speicher | Vollständig — Dateien sind lokal | Erfordert Netzwerk (zwischengespeicherte Elemente offline in der App verfügbar) |
| Konto / Abonnement | Keines — kostenlos, Open Source, keine Registrierung | Kostenlos (dotenv) / kostenlos Open Source (dotenvx) | Bezahltes Abonnement (ab ca. 3 €/Monat für Einzelpersonen, ca. 8 €/Benutzer/Monat für Unternehmen) |
| Plattformübergreifend | macOS, Linux, Windows | Jede Plattform mit Node.js / jeder Runtime (dotenvx) | macOS, Linux, Windows |
| Kontext-/Umgebungsorganisation | Kontexte (z. B. `myapp.dev`, `stripe.prod`) | Separate `.env`-Dateien pro Umgebung | Tresore und Elemente |
| Befehle mit Geheimnissen ausführen | `envsec run` — Platzhalter-Interpolation + `--inject` Umgebungsvariablen | `dotenvx run -- cmd` — fügt aus verschlüsselter `.env` ein | `op run -- cmd` — fügt über Secret-Referenzen ein |
| Export in `.env`-Datei | `envsec env-file` (für Prüfung nachverfolgt) | Natives Format — `.env`-Dateien sind die Quelle der Wahrheit | `op inject --out-file` |
| Import aus `.env`-Datei | `envsec load` (mit Konflikterkennung) | N/V — `.env` ist der primäre Speicher | Manuelle Elementerstellung |
| Shell-Umgebungs-Export | `eval $(envsec env)` — bash, zsh, fish, powershell | `dotenvx run` oder `node -r dotenv/config` | `op run --env-file` |
| Interaktive Shell-Sitzung | `envsec shell` — eingeschränkte Subshell mit automatischer Bereinigung | Nicht integriert | Nicht integriert |
| Geheimnissuche | Glob-Muster auf Schlüsseln und Kontexten | Nicht integriert | `op item list --tags/--category` Filterung |
| Ablauf-/Rotationsprüfung | `envsec audit` — abgelaufene, ablaufende, verfolgte `.env`-Dateien | Nicht integriert | Watchtower (in der App, nicht CLI) |
| Gespeicherte Befehle | `envsec cmd` — speichern, auflisten, suchen, ausführen, löschen | Nicht integriert | Nicht integriert |
| Geheimnisse verschieben/kopieren | `envsec move` und `envsec copy` zwischen Kontexten | Manuelles Kopieren von Dateien | `op item move` zwischen Tresoren |
| Geheimnisse umbenennen | `envsec rename` (bewahrt Wert und Metadaten) | Manuelle Bearbeitung der `.env`-Datei | `op item edit` |
| GPG-verschlüsselte Freigabe | `envsec share --encrypt-to` | Verschlüsselte `.env`-Dateien in Git committet (dotenvx) | Integrierte Tresorfreigabe, Team-Bereitstellung |
| Interaktives TUI | `envsec tui` — Vollbild-Terminal-UI | Nicht integriert | Nicht integriert |
| Gesundheitsdiagnose | `envsec doctor` — überprüft Plattform, Keychain, DB-Integrität | Nicht integriert | Nicht integriert |
| Shell-Vervollständigungen | Dynamisch (Kontexte, Schlüssel, Befehle) für bash, zsh, fish | Nicht integriert | Statische Vervollständigungen für bash, zsh, fish, powershell |
| SDK / programmatischer Zugriff | `@envsec/sdk` für Node.js / Bun | `require('dotenv').config()` — Kernanwendungsfall | 1Password SDKs (Node.js, Python, Go, usw.) |
| Team / Mehrbenutzer | GPG-Freigabe (manuell) | Git-basierte Freigabe mit verschlüsselter `.env` (dotenvx) | Integrierte Teamverwaltung, RBAC, Audit-Logs |
<!-- | CI/CD-Integration | Standard-CLI — funktioniert überall, wo Node.js läuft | `dotenvx run` in jeder CI-Pipeline | Service-Konten, native CI/CD-Integrationen | -->
| Biometrische Authentifizierung | Erbt OS-Biometrie (z. B. macOS Keychain-Entsperrung) | Keine | Fingerabdruck / Touch ID über App-Integration |
| Metadaten-Tracking | SQLite (Schlüsselnamen, Zeitstempel — niemals Werte) | Keine | Cloud-basierte Elementhistorie und Audit-Logs |
Kurz gesagt: dotenv ist der einfachste Ansatz (Dateien auf der Festplatte), die 1Password CLI ist die funktionsreichste für Teams mit Cloud-Synchronisation und RBAC, und envsec liegt dazwischen — bietet OS-native Verschlüsselung ohne Konten, keine Cloud-Abhängigkeiten und einen entwicklerorientierten Arbeitsablauf, der über das hinausgeht, was `.env`-Dateien leisten können.
## So funktioniert es
Geheimnisse werden im nativen OS-Anmeldeinformationsspeicher gespeichert. Das Backend wird automatisch basierend auf der Plattform ausgewählt:
| OS | Backend | Tool / API |
|---------|--------------------------------|-------------------------------------|
| macOS | Keychain | `security` CLI |
| Linux | Secret Service API (D-Bus) | `secret-tool` (libsecret) |
| Windows | Credential Manager | `cmdkey` + PowerShell (advapi32) |
Metadaten (Schlüsselnamen, Zeitstempel) werden in einer SQLite-Datenbank unter `~/.envsec/store.sqlite` gespeichert (konfigurierbar über `--db` oder `ENVSEC_DB`). Schlüssel müssen mindestens einen Punkt als Trennzeichen enthalten (z. B. `service.account`), was der Service/Account-Struktur des Anmeldeinformationsspeichers entspricht.
## Sicherheit
envsec basiert auf einem einfachen Prinzip: Ihre Geheimnisse gehören in Ihr Betriebssystem, nicht in Punktdateien. Jede Designentscheidung beginnt mit dieser Grundlage.
### Wie envsec Ihre Geheimnisse schützt
**OS-native Verschlüsselung, keine eigene Kryptografie.** Geheimniswerte werden direkt in macOS Keychain, GNOME Keyring / KDE Wallet oder Windows Credential Manager gespeichert. envsec erfindet keine eigene Verschlüsselung — es delegiert an die kampferprobten Anmeldeinformationsspeicher, die Ihr Betriebssystem bereits bereitstellt, geschützt durch Ihre Benutzersitzung und (auf macOS) die Login-Keychain.
**Vollständige Unicode-Unterstützung.** Geheimniswerte können beliebige Unicode-Zeichen enthalten, einschließlich Emojis und akzentuierter Buchstaben. Werte werden base64-kodiert, bevor sie im OS-Anmeldeinformationsspeicher gespeichert werden, um plattformspezifische Kodierungsspielereien zu vermeiden (z. B. macOS `security` CLI hex-kodiert nicht-ASCII-Ausgabe). Legacy-Klartext-Geheimnisse werden aus Gründen der Rückwärtskompatibilität transparent gelesen.
**Geheimnisse berühren niemals als Klartext die Festplatte.** Werte gehen direkt von Ihrem Terminal in den OS-Anmeldeinformationsspeicher. Sie werden niemals in Konfigurationsdateien, Protokolle oder temporären Speicher geschrieben.
**Keine Geheimnisse in der Terminalausgabe.** Die Befehle `list` und `search` zeigen nur Schlüsselnamen an — Werte werden nie ausgegeben. Dadurch bleiben Geheimnisse außerhalb von Scrollback-Puffern, Bildschirmaufnahmen und dem Blickfeld von Mitlesern.
**Sichere Befehlsausführung.** Der Befehl `run` injiziert Geheimnisse als Umgebungsvariablen des untergeordneten Prozesses, anstatt sie in die Befehlszeichenfolge zu interpolieren. Dadurch erscheinen Geheimniswerte nicht in der `ps`-Ausgabe oder der Shell-Historie. Wenn ein referenziertes Geheimnis fehlt, wird der Befehl vollständig blockiert — keine teilweise Ausführung mit unvollständigen Anmeldeinformationen.
**Eingabevalidierung und Injektionsprävention.** Kontextnamen werden gegen eine strenge Positivliste (alphanumerisch, Punkte, Bindestriche, Unterstriche) mit Pfad-Traversal- und Prototype-Pollution-Prüfungen validiert. Alle SQLite-Abfragen verwenden vorbereitete Anweisungen mit Bindungsparametern, um SQL-Injection zu verhindern. PowerShell-Argumente unter Windows werden escaped, um Command-Injection zu verhindern.
**Restriktive Dateiberechtigungen.** Das Metadatenverzeichnis (`~/.envsec/`) wird mit `0700`-Berechtigungen und die SQLite-Datenbank mit `0600` erstellt, wodurch der Zugriff auf den besitzenden Benutzer beschränkt wird.
### Bekannte Einschränkungen und Verbesserungsmöglichkeiten
Wir glauben an Offenheit darüber, was envsec noch nicht abdeckt. Dies sind echte Kompromisse, keine Fehler — und wenn Sie sie verstehen, können Sie fundierte Entscheidungen treffen.
**Metadaten sind sichtbar.** Die SQLite-Datenbank unter `~/.envsec/store.sqlite` speichert Schlüsselnamen, Kontextnamen und Zeitstempel — niemals Geheimniswerte, aber genug, um preiszugeben, *welche* Geheimnisse existieren. Gespeicherte Befehlsvorlagen (mit `{key}`-Platzhaltern) werden ebenfalls dort gespeichert. Wenn die Vertraulichkeit von Metadaten für Sie wichtig ist, stellen Sie sicher, dass Ihr Home-Verzeichnis auf einem verschlüsselten Volume liegt.
**`env-file`-Exporte sind Klartext.** Der Befehl `env-file` schreibt Geheimniswerte in eine `.env`-Datei auf der Festplatte. Dies ist von Natur aus sensibel — behandeln Sie die Ausgabedatei entsprechend und committen Sie sie niemals in die Versionskontrolle. Betrachten Sie es als Komfortbrücke, nicht als Speichermechanismus.
**Shell-Ausführung birgt inhärentes Risiko.** Der Befehl `run` übergibt Ihre Befehlsvorlage an `/bin/sh` (oder `cmd.exe` unter Windows). Wenn die Vorlage selbst aus einer nicht vertrauenswürdigen Quelle stammt, ist Shell-Injection möglich. Führen Sie nur Befehlsvorlagen aus, die Sie selbst geschrieben haben oder denen Sie vertrauen.
**Keine kontextübergreifende Zugriffskontrolle.** Jeder Prozess, der als Ihr OS-Benutzer läuft, kann alle Geheimnisse in allen Kontexten lesen. envsec verlässt sich auf die OS-basierte Benutzerisolierung — es fügt keine eigene Autorisierungsebene zwischen Kontexten hinzu.
**Linux-Headless-Umgebungen.** Unter Linux ist envsec auf eine aktive D-Bus-Sitzung und einen Keyring-Daemon (z. B. `gnome-keyring-daemon`) angewiesen. In Containern oder Headless-Servern ohne grafische Sitzung ist der Keyring möglicherweise nicht verfügbar oder speichert Geheimnisse mit schwächerem Schutz.
**Verschlüsselung hängt von Ihrem Betriebssystem ab.** envsec fügt keine zusätzliche Ruhezustandsverschlüsselung hinzu, die über das hinausgeht, was der native Anmeldeinformationsspeicher bietet. Auf Systemen ohne vollständige Festplattenverschlüsselung könnte ein Angreifer mit physischem Zugriff möglicherweise Geheimnisse aus der Keychain extrahieren. Wir empfehlen die Aktivierung der vollständigen Festplattenverschlüsselung (FileVault, LUKS, BitLocker) für den stärksten Schutz.
## Entwicklung
### Voraussetzungen
- Node.js >= 22
- pnpm
### Einrichtung```bash
git clone https://github.com/davidnussio/envsec.git
cd envsec
pnpm install
pnpm run build
packages/
cli/ → envsec CLI (published as envsec)
sdk/ → Node.js/Bun SDK (published as @envsec/sdk)
core/ → Core engine, shared by CLI and SDK (published as @envsec/core)
tui/ → Interactive terminal UI (published as @envsec/tui)
apps/
website/ → Documentation website
### Allgemeine Befehle```bash
# Build all packages
pnpm run build
# Lint and format check (all packages)
pnpm run check
# Auto-fix lint and formatting
pnpm run fix
# Release (build + changeset publish)
pnpm run release
Erstellen Sie einen temporären Alias, um den lokalen Build so zu verwenden, als wäre er global installiert:```bash
alias envsec="node $(pwd)/packages/cli/dist/main.js"
alias envsec "node (pwd)/packages/cli/dist/main.js"
### Lokales Testen von Shell-Vervollständigungen
Nach dem Erstellen und Einrichten des Alias laden Sie die Vervollständigungen in Ihrer aktuellen Sitzung:```bash
# Bash
alias envsec="node $(pwd)/packages/cli/dist/main.js"
eval "$(envsec --completions bash)"
# Zsh
alias envsec="node $(pwd)/packages/cli/dist/main.js"
eval "$(envsec --completions zsh)"
# Fish
alias envsec "node (pwd)/packages/cli/dist/main.js"
envsec --completions fish | source
Drücken Sie dann TAB nach envsec -c , um Ihre Kontexte anzuzeigen, oder nach envsec -c myapp.dev get , um geheime Schlüssel zu sehen.
pnpm run build
bash packages/cli/test/e2e-test.sh
pwsh packages/cli/test/e2e-test.ps1
CI läuft automatisch bei Push/PR auf `main` über GitHub Actions und führt dabei `e2e-test.sh` auf macOS und Ubuntu und `e2e-test.ps1` auf Windows aus.
## Lizenz
| Paket | Beschreibung | npm |
|---|
envsec | CLI-Tool zur Verwaltung von Geheimnissen |  |
@envsec/sdk | Node.js / Bun SDK zum programmatischen Laden von Geheimnissen |  |
@envsec/core | Kern-Engine – Adapter für Betriebssystem-Schlüsselspeicher + Metadaten-DB |  |
@envsec/tui | Interaktive Terminal-Benutzeroberfläche für die Geheimnisverwaltung |  |