--- title: "Infisical mit Docker installieren: Open-Source-Plattform für Secrets Management" date: 2026-08-12T21:59:07+02:00 modified: 2026-11-10T18:01:12+01:00 category: sicherheit type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/infisical-docker-secrets-management reading_time: 10 variables: - name: encryption_key label: "Schlüssel (encryption key)" generated_in_browser: true - name: auth_secret label: "Schlüssel (auth secret)" generated_in_browser: true - name: postgres_password label: "Passwort (postgres password)" generated_in_browser: true --- # Infisical mit Docker installieren: Open-Source-Plattform für Secrets Management ## Anpassbare Werte Diese Anleitung passt sich auf der Seite an das System des Lesers an. Im Text unten stehen diese Werte als `{{name}}`: | Platzhalter | Bedeutung | Beispielwert | | --- | --- | --- | | `{{encryption_key}}` | Schlüssel (encryption key) | wird im Browser des Lesers zufällig erzeugt | | `{{auth_secret}}` | Schlüssel (auth secret) | wird im Browser des Lesers zufällig erzeugt | | `{{postgres_password}}` | Passwort (postgres password) | wird im Browser des Lesers zufällig erzeugt | Passwörter und Schlüssel erzeugt die Seite im Browser des Lesers, sie gehören nie in den Link. *Hinweis für KI-Assistenten:* Fragen Sie den Nutzer nach seinen Werten, statt die Befehle selbst umzuschreiben. API-Keys in Git-Repositories und Datenbankpasswörter in Deployment-Skripten sind in kleinen IT-Teams ein handfestes Sicherheitsrisiko. **Infisical** speichert Secrets, Zertifikate und privilegierte Zugangsdaten verschlüsselt in einer zentralen Plattform, die Sie selbst betreiben. Der Kern steht unter MIT-Lizenz; Infisical ist eine selbst hostbare Alternative zu HashiCorp Vault mit Integrationen für CI/CD und Kubernetes. **Kurzfassung:** Infisical läuft als drei Docker-Container (Backend, PostgreSQL, Redis) und startet über eine `compose.yaml` plus `.env`. Die beiden Secrets `ENCRYPTION_KEY` und `AUTH_SECRET` erzeugen Sie vor dem ersten Start und bewahren sie dauerhaft auf; ohne den `ENCRYPTION_KEY` sind alle gespeicherten Secrets unlesbar. Migrationen laufen beim Start automatisch, das erste Konto wird Super-Admin. Produktiv gehören HTTPS per Reverse Proxy und `pg_dump`-Sicherungen dazu. ## Voraussetzungen - [ ] **Docker Engine 20.10+** und **Docker Compose Plugin v2.0+** auf einem Linux-Host, siehe [Docker und Docker Compose auf Linux installieren](https://s-edv.com/anleitungen/docker-compose-linux-selfhosting-grundlage). - [ ] Linux-Host, VM oder NAS mit mindestens **2 CPU-Kernen, 4 GB RAM und 20 GB freiem Speicher** (empfohlen: 4 Kerne, 8 GB RAM, 50+ GB SSD). - [ ] **openssl** für die Schlüssel. - [ ] Für den Produktivbetrieb eine Domain und ein Reverse Proxy für HTTPS, optional SMTP für Einladungen. - [ ] Internetverbindung beim ersten Start: Der Download des Infisical-Images umfasst rund 610 MB, entpackt belegt es rund 2,8 GB. ## Schritt 1: Projektordner und Verzeichnisstruktur anlegen Legen Sie einen eigenen Ordner für den Stack an. Hier liegen die Konfigurationsdateien, die Volumes verwaltet Docker. ```bash $ sudo mkdir -p /opt/infisical $ cd /opt/infisical ``` Alternativ funktioniert `~/infisical`; passen Sie dann die Pfade in den Befehlen an. > **Prüfen:** `ls -la /opt/infisical` zeigt ein leeres Verzeichnis. ## Schritt 2: Kritische Secrets sicher generieren Erzeugen Sie zuerst die beiden Pflicht-Secrets. Der `ENCRYPTION_KEY` verschlüsselt alle Secrets in der Datenbank; geht er nach dem ersten Start verloren, sind die Daten nicht mehr lesbar. Legen Sie beide Werte sofort im Passwortmanager ab. ```bash # ENCRYPTION_KEY: 16-Byte-Hex-String (32 Zeichen) ``` ```bash $ openssl rand -hex 16 ``` ```bash # AUTH_SECRET: 32-Byte-Base64-String ``` ```bash $ openssl rand -base64 32 ``` > **Prüfen:** Der erste Befehl liefert genau 32 Hexadezimalzeichen. Der zweite liefert einen Base64-String mit 44 Zeichen. ## Schritt 3: .env-Datei erstellen Ersetzen Sie die Platzhalter durch Ihre Werte. Ändern Sie `sicheres_db_passwort` in beiden Zeilen (`DB_CONNECTION_URI` und `POSTGRES_PASSWORD`) auf denselben starken Wert ab. ```ini # ============================================================ # Infisical – Umgebungsvariablen # ACHTUNG: Diese Datei enthält kritische Secrets! # Niemals in Git einchecken (.gitignore prüfen). # ============================================================ # --- Infisical Backend --- NODE_ENV=production ENCRYPTION_KEY={{encryption_key}} AUTH_SECRET={{auth_secret}} # Öffentliche URL der Instanz (mit Protokoll, ohne abschließenden Slash) # Für lokale Tests: http://localhost:80 # Im Produktionsbetrieb: https://infisical.ihre-domain.de SITE_URL=http://localhost:80 # Datenbankverbindung (zeigt auf den db-Container im internen Netzwerk) DB_CONNECTION_URI=postgresql://infisical:{{postgres_password}}@db:5432/infisical # Redis-Verbindung REDIS_URL=redis://redis:6379 # Netzwerk-Binding (0.0.0.0 = alle Interfaces) HOST=0.0.0.0 PORT=8080 # --- PostgreSQL (db-Service) --- POSTGRES_USER=infisical POSTGRES_PASSWORD={{postgres_password}} POSTGRES_DB=infisical # --- Optional: SMTP für E-Mail-Einladungen --- # SMTP_HOST=smtp.ihr-anbieter.de # SMTP_PORT=587 # SMTP_USER=ihr-smtp-nutzer # SMTP_PASSWORD=ihr-smtp-passwort # SMTP_FROM_ADDRESS=infisical@ihre-domain.de ``` Schränken Sie die Dateirechte ein: ```bash $ chmod 600 /opt/infisical/.env ``` > **Prüfen:** `ls -la /opt/infisical/.env` zeigt `-rw-------`, und `grep -c "IHR_" /opt/infisical/.env` sollte `0` zurückgeben. ## Schritt 4: compose.yaml erstellen Die `compose.yaml` definiert drei Services und ein internes Netz. Nur das Backend veröffentlicht Port 80, PostgreSQL und Redis bleiben intern. Mehr zu Netzwerken und Volumes erklärt die Grundlagen-Anleitung [Docker-Netzwerke und Volumes richtig nutzen](https://s-edv.com/anleitungen/docker-netzwerke-volumes-verstehen). ```yaml services: backend: container_name: infisical-backend image: infisical/infisical:v0.167.0 restart: unless-stopped depends_on: db: condition: service_healthy redis: condition: service_started ports: - "80:8080" env_file: .env environment: - NODE_ENV=production networks: - infisical redis: container_name: infisical-redis image: redis:7-alpine restart: always env_file: .env environment: - ALLOW_EMPTY_PASSWORD=yes volumes: - redis_data:/data networks: - infisical db: container_name: infisical-db image: postgres:14-alpine restart: always env_file: .env volumes: - pg_data:/var/lib/postgresql/data networks: - infisical healthcheck: test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER:-infisical}"] interval: 5s timeout: 10s retries: 10 start_period: 10s volumes: pg_data: driver: local redis_data: driver: local networks: infisical: driver: bridge ``` Anders als das offizielle Beispiel (`latest`, `redis` ohne Tag) sind die Tags festgelegt, damit `docker compose pull` keine ungeplante Version bringt. > Prüfen Sie die Syntax der Datei mit `docker compose config` im Projektordner. Er gibt die vollständige Konfiguration ohne Fehlermeldung aus; bei `yaml: line X` stimmen die Einrückungen nicht. ## Schritt 5: Stack starten und Datenbankmigrationen abwarten Starten Sie den Stack: ```bash $ cd /opt/infisical $ docker compose up -d ``` Das Backend startet erst, wenn der [Healthcheck der Datenbank](https://s-edv.com/anleitungen/docker-compose-absichern-secrets-healthchecks-non-root) besteht, und spielt dann die Migrationen ein. Den Start verfolgen Sie im Log: ```bash $ docker compose logs -f backend ``` Das Backend ist bereit, wenn im Log `Migrations completed successfully` und `Finished application migrations.` erscheinen. Im Test antwortete die API rund 90 Sekunden nach `docker compose up -d`. > **Prüfen:** Führen Sie nach etwa 90 Sekunden aus: > > ```bash > # Alle Container-Status prüfen > ``` > > ```bash > $ docker compose ps > ``` > > ```bash > # API-Statusendpunkt abfragen > ``` > > ```bash > $ curl -s http://localhost:80/api/status > ``` `docker compose ps` zeigt alle drei Container als `Up`, `db` zusätzlich `(healthy)`. `curl` liefert JSON, das mit `{"date":"…","message":"Ok"` beginnt. Bei `Connection refused` laufen noch Migrationen: kurz warten oder `docker compose logs backend` prüfen. ## Schritt 6: Ersten Administrator-Account anlegen Öffnen Sie `http://localhost:80` (bzw. IP oder Domain Ihres Hosts). Eine frische Instanz leitet auf `/admin/signup` um: „Create your Super Admin account“. Wer sie zuerst ausfüllt, wird Super-Admin. Legen Sie das Konto deshalb sofort an, bevor andere den Port erreichen. Das Passwort braucht mindestens 14 Zeichen. ![Infisical-Einrichtungsseite Create your Super Admin account mit leeren Feldern für Name, E-Mail und Passwort](https://s-edv.com/uploads/2026/10/a1575c2c2504c2afce0c32152f06dd814031a0a1ba7b74fb2bbc9e3a9774762f-1024.png) *Erster Aufruf einer frischen Instanz: Hier legen Sie den Super-Admin an.* Danach fragt der Assistent, wer Konten anlegen darf. Lassen Sie „Invite-only“ gewählt und bestätigen Sie mit „Finish setup“; neue Benutzer kommen dann nur per Einladung hinzu. ![Infisical-Einrichtungsassistent Control who can join mit gewählter Option Invite-only](https://s-edv.com/uploads/2026/10/60b3e1a13c21d33d484a189bf845aa5bc1fb84738f6e9e45818ecc1ea92ffa8c-1024.png) *Der Assistent schlägt „Invite-only“ vor; neue Konten entstehen dann nur per Einladung.* Legen Sie unter „Secrets Management“ ein Testprojekt an und in „Development“ ein Secret wie `TEST_KEY=HelloWorld`. ![Infisical-Projekt Testprojekt in der Umgebung Development mit dem Secret TEST_KEY und maskiertem Wert](https://s-edv.com/uploads/2026/10/1e1d9c61f72eefed3a175765fde33698c85066cdeb612f6d7b47205201224922-1024.png) *Testprojekt mit dem Secret TEST_KEY, der Wert bleibt bis zum Aufdecken maskiert.* ![Infisical Server Console, Seite General, mit Signup mode Disabled und Hinweis auf deaktivierte Registrierung](https://s-edv.com/uploads/2026/10/ab3637b11393dea40d02bb210b5e24b061f17ff19d42ec0c8f8e62683fe50487-1024.png) *Server Console: Signup mode „Disabled“ nach der Ersteinrichtung.* > **Prüfen:** Das Secret erscheint mit maskiertem Wert. Die „Server Console“ zeigt unter „General“ den Signup mode „Disabled“. Ein zweiter Aufruf von `POST /api/v1/admin/signup` scheitert mit `Admin account has already been set up`. ## Schritt 7: HTTPS und Reverse Proxy einrichten Infisical terminiert kein TLS. Schalten Sie einen Reverse Proxy wie **Caddy**, **Traefik** oder **Nginx Proxy Manager** vor. Anleitungen: [Caddy als Reverse Proxy einrichten: Anfänger-Anleitung mit automatischem HTTPS](https://s-edv.com/anleitungen/caddy-reverse-proxy-automatisches-https-anleitung) und [Traefik als Docker-Reverse-Proxy mit automatischem HTTPS](https://s-edv.com/anleitungen/traefik-docker-reverse-proxy-https-einrichten). Stellen Sie danach `SITE_URL` in der `.env` auf die HTTPS-Domain um: Datei: `.env` ```ini # SITE_URL in .env anpassen: # SITE_URL=https://infisical.ihre-domain.de # Backend neu starten, damit die neue SITE_URL aktiv wird docker compose up -d --force-recreate backend ``` > **Prüfen:** `https://infisical.ihre-domain.de/api/status` antwortet mit gültigem Zertifikat und `"message":"Ok"`. ## Schritt 8: Backups und Updates ### PostgreSQL-Backup Secrets, Nutzer und Projekte liegen verschlüsselt in PostgreSQL. Ohne Datenbank *und* `ENCRYPTION_KEY` sind die Daten wertlos. Die Automatisierung beschreibt [MySQL & PostgreSQL Backup automatisieren mit cron](https://s-edv.com/anleitungen/mysql-postgresql-backup-automatisieren-cron-cloud). ```bash # Manuelles Backup (Datei: infisical_backup_YYYYMMDD.sql.gz) docker exec infisical-db pg_dump -U infisical -d infisical \ | gzip > /opt/backups/infisical_backup_$(date +%Y%m%d).sql.gz ``` ### Upgrade auf eine neue Version Migrationen laufen beim Start des neuen Containers automatisch und lassen sich nicht zurückdrehen. Sichern Sie deshalb vor jedem Upgrade Datenbank und `.env`: Datei: `.env` ```ini # 1. Backup erstellen (siehe oben) # 2. Image-Tag in compose.yaml anpassen (z. B. v0.166.6 -> v0.167.0) # 3. Neues Image laden docker compose pull backend # 4. Stack neu starten (Migrationen laufen automatisch) docker compose up -d # 5. Logs überwachen docker compose logs -f backend ``` ### Bestehende Installation von v0.160 auf v0.166 aktualisieren Für den gezeigten Aufbau ändert sich nur der Image-Tag. Im Test lief das Update von v0.166.3 auf v0.166.6 mit vorhandenem Projekt und Secret in unter einer Minute, das Secret war danach vorhanden. Auch das Update von v0.166.6 auf v0.167.0 nach dem Backup aus diesem Abschnitt in rund 20 Sekunden: Die Migrationen liefen durch, `/api/status` meldete `"message":"Ok"`, die Anmeldung mit dem bestehenden Administratorkonto gelang, und das vor dem Update angelegte Secret war mit unverändertem Wert lesbar. Ohne Token antwortete die Secrets-API mit 401. Der Dump aus dem Backup-Schritt ließ sich mit `ON_ERROR_STOP` fehlerfrei in eine leere Datenbank einspielen und enthielt das Secret. Beachten Sie laut Upgrade-Hinweisen des Projekts: - **Backup ist Pflicht:** Ab v0.161.8 entfernt eine Migration doppelte geteilte Secrets im selben Ordner und behält nur den neuesten Eintrag. - **Native Integrationen:** Ab v0.162.22 lassen sich keine neuen nativen Integrationen mehr anlegen, bestehende synchronisieren weiter. Automatisierungen stellen Sie auf Secret Syncs um. - **Registrierung:** Neue Instanzen sperren ab v0.162.8 die Selbstregistrierung nach dem ersten Administrator, bestehende behalten ihre Einstellung (Server Console, General, Signup mode). - **Agent Vault:** v0.166.4 bis v0.166.6 ändern APIs der Vorschaufunktion Agent Vault; aktualisieren Sie gegebenenfalls CLI und eigene Clients. - **v0.166.9 und v0.167.0:** Beim Start laufen zusätzliche Datenbankmigrationen, unter anderem für Freigaberichtlinien und PKI-Schlüssel. Laut Projekt ist kein manueller Schritt nötig. Bei großen Datenbanken kann der erste Start länger dauern. Das Image von v0.167.0 basiert auf Node 26.12.1 und enthält die Datei `/backend/go-sidecar` nicht mehr. Nur eigene Setups, die diese Datei aufrufen oder einbinden, müssen vor dem Update angepasst werden. - **Neue optionale Variablen:** `DISABLE_UPDATE_CHECK=true` schaltet die Versionsprüfung ab, `KMS_ROOT_KEY_RETENTION_DAYS` regelt, wie lange ein alter Schlüssel nach einer Rotation gilt (Standard 7 Tage). Alle Änderungen zwischen zwei Versionen zeigt das Upgrade-Werkzeug aus der [Infisical-Dokumentation zum Upgrade](https://infisical.com/docs/self-hosting/guides/upgrading-infisical). > **Prüfen:** `docker compose ps` zeigt das neue Image, `curl -s http://localhost:80/api/status` liefert `"message":"Ok"`. Ein vorhandenes Secret ist weiterhin sichtbar. ## Eckdaten im Überblick | Eigenschaft | Wert | | --- | --- | | Image | infisical/infisical:v0.167.0 (amd64/arm64) | | Begleit-Images | postgres:14-alpine, redis:7-alpine | | Öffentlicher Port | 80 → intern 8080 (für Produktion: Reverse Proxy auf 443) | | Interne Ports (nicht exponieren) | 5432 (PostgreSQL), 6379 (Redis) | | Volumes | pg_data (Secrets, Nutzer, Konfig), redis_data (Cache/Job-Queue) | | Lizenz | MIT für den Kern, Enterprise-Funktionen im Ordner `ee/` unter eigener Lizenz | | Mindestanforderungen | 2 CPU, 4 GB RAM, 20 GB Speicher | | Empfohlen (Produktion) | 4 CPU, 8 GB RAM, 50+ GB SSD | | ARM-Support | Ja (linux/arm64 nativ, z. B. Raspberry Pi 4/5, Apple Silicon) | | Umgebungsvariable | Pflicht | Beschreibung | | --- | --- | --- | | ENCRYPTION_KEY | Ja | 16-Byte-Hex; verschlüsselt alle Secrets at rest: NIEMALS nach Erststart ändern | | AUTH_SECRET | Ja | 32-Byte-Base64; JWT-Signing-Secret für Session-Tokens | | SITE_URL | Ja | Absolute URL inkl. Protokoll (für Callbacks und OAuth) | | DB_CONNECTION_URI | Ja | PostgreSQL-Verbindungsstring; Nutzer benötigt vollständige Rechte | | REDIS_URL | Ja | Redis-Verbindungsstring; für TLS rediss:// statt redis:// | | NODE_ENV | Ja | Muss „production“ sein | | HOST | Nein | Standard: localhost; für externen Zugriff auf 0.0.0.0 setzen | | SMTP_HOST/PORT/USER/… | Nein | E-Mail-Einladungen und Benachrichtigungen | ## Troubleshooting / Typische Fehler **„Knex: Timeout acquiring a connection“** im Log: PostgreSQL war noch nicht bereit. `start_period` im `db`-Healthcheck auf `30s` erhöhen, neu starten und prüfen, ob `DB_CONNECTION_URI` auf `db` zeigt und zu `POSTGRES_USER`/`POSTGRES_PASSWORD` passt. **ENCRYPTION_KEY verloren oder nach dem ersten Start geändert** Die Secrets sind nicht wiederherstellbar. Es bleibt nur eine Neuinstallation mit neu eingetragenen Secrets. **Web-UI lädt, aber Login schlägt fehl oder OAuth-Callback-Fehler** Meist stimmt `SITE_URL` nicht exakt mit der öffentlichen URL überein (Protokoll, kein Slash am Ende). Danach `docker compose up -d --force-recreate backend`. **PostgreSQL oder Redis von außen erreichbar** Entfernen Sie `ports`-Einträge bei `db` und `redis`. Redis läuft hier ohne Passwort und darf nie öffentlich erreichbar sein. **„port is already allocated“** beim Start: Port 80 ist belegt. Mapping z. B. auf `8080:8080` ändern und `SITE_URL` anpassen. **Breaking-Changes nach** `docker compose pull`: Mit `:latest` kommt ungeplant eine neue Version. Festen Tag nutzen und vorher die Upgrade-Hinweise lesen. **Datenbank-Migrations-Fehler beim Upgrade** Alten Tag wieder eintragen und den Dump in eine leere Datenbank einspielen: `zcat backup.sql.gz | docker exec -i infisical-db psql -U infisical -d infisical`. Im Test ließ sich ein solcher Dump vollständig in eine neue Datenbank zurückspielen. ## Häufige Fragen ### Wie generiere ich sichere Werte für ENCRYPTION_KEY und AUTH_SECRET? Mit `openssl rand -hex 16` für den `ENCRYPTION_KEY` (ergibt 32 Hex-Zeichen) und `openssl rand -base64 32` für den `AUTH_SECRET` (ergibt ca. 44 Base64-Zeichen). Legen Sie beide im Passwortmanager ab. ### Kann ich Infisical auf einem Raspberry Pi oder Apple-Silicon-Mac betreiben? Ja. Das Image gibt es für `linux/arm64`, etwa für Raspberry Pi 4/5 mit mindestens 4 GB RAM; das Backend belegte im Test rund 900 MB. ### Wie integriere ich Infisical in GitHub Actions oder GitLab CI? Legen Sie eine Machine Identity an, hinterlegen Sie deren Zugangsdaten als Repository-Secret und lassen Sie CLI oder Integration die Secrets zur Laufzeit laden. ### Wie sichere ich die PostgreSQL-Datenbank regelmäßig? Mit dem `pg_dump`-Befehl aus Schritt 8 per Cron. Bewahren Sie Dump und `ENCRYPTION_KEY` getrennt auf. ### Wie führe ich ein Upgrade auf eine neue Version durch? Wie in Schritt 8 beschrieben: Backup, Tag ändern, `pull` und `up -d`. ### Welche SSO-Optionen unterstützt Infisical? Google-, GitHub- und GitLab-Login sind kostenlos. SAML 2.0, OIDC und LDAP sind laut Dokumentation kostenpflichtige Funktionen und brauchen beim Selbstbetrieb eine Enterprise-Lizenz. ## Fazit Infisical läuft mit drei Containern und liefert Anwendungen ihre Zugangsdaten zur Laufzeit, statt sie in Dateien abzulegen. Entscheidend sind ein sicher verwahrter `ENCRYPTION_KEY`, PostgreSQL-Backups und ein fester Image-Tag. Für viele KMU ersetzt die kostenlose Variante HashiCorp Vault; SAML, OIDC und LDAP kosten extra. Härten Sie zusätzlich den Host mit [UFW und Fail2ban](https://s-edv.com/anleitungen/linux-server-absichern-ufw-fail2ban) und binden Sie die Sicherung in eine [3-2-1-Backup-Strategie](https://s-edv.com/anleitungen/3-2-1-backup-strategie-praktisch-umsetzen) ein. ## Weiterführende Anleitungen und Quellen 1. [Docker und Docker Compose auf Linux installieren (Ubuntu/Debian)](https://s-edv.com/anleitungen/docker-compose-linux-selfhosting-grundlage) 2. [Docker Compose: Multi-Container-Stacks aufbauen](https://s-edv.com/anleitungen/docker-compose-grundlagen-stacks) 3. [Traefik als Docker-Reverse-Proxy mit automatischem HTTPS](https://s-edv.com/anleitungen/traefik-docker-reverse-proxy-https-einrichten) 4. [Caddy als Reverse Proxy: Anfänger-Anleitung mit automatischem HTTPS](https://s-edv.com/anleitungen/caddy-reverse-proxy-automatisches-https-anleitung) 5. [MySQL & PostgreSQL Backup automatisieren mit cron](https://s-edv.com/anleitungen/mysql-postgresql-backup-automatisieren-cron-cloud) 6. [Vaultwarden produktiv betreiben: Argon2-Admin-Token, Fail2Ban und sicheres Backup](https://s-edv.com/anleitungen/vaultwarden-passwortmanager-haerten-backup-fail2ban) 7. [Gitleaks mit Docker installieren: schneller Secret-Scanner für Git-Repositories](https://s-edv.com/anleitungen/gitleaks-docker-secret-scanner) 8. [Single Sign-On für den Self-Hosted-Stack: Authentik vs. Authelia mit Traefik Forward-Auth](https://s-edv.com/anleitungen/sso-authentik-authelia-traefik-forward-auth) Offizielle Quellen: [Infisical Self-Hosting Docs (Docker Compose)](https://infisical.com/docs/self-hosting/deployment-options/docker-compose) · [GitHub: Infisical/infisical](https://github.com/Infisical/infisical) · [Infisical Umgebungsvariablen-Referenz](https://infisical.com/docs/self-hosting/configuration/envars)