API-Keys in Git-Repositories, Datenbankpasswörter in Deployment-Skripten, TLS-Zertifikate auf zehn verschiedenen Servern – der klassische Secrets-Wildwuchs in kleinen und mittleren IT-Teams ist nicht nur unübersichtlich, sondern ein handfestes Sicherheitsrisiko. Infisical löst dieses Problem mit einem modernen, zentralen Ansatz: Alle Secrets, Zertifikate und privilegierten Zugangsdaten landen verschlüsselt in einer einzigen Plattform, die du vollständig selbst betreibst. Mit 27.000+ GitHub-Stars, MIT-Lizenz und einer Release-Kadenz von mehreren Updates pro Woche ist Infisical die populärste selbst hostbare Alternative zu HashiCorp Vault – und dank nativer Integrationen für GitHub Actions, GitLab CI, Kubernetes und 12+ Sprach-SDKs lässt sie sich nahtlos in bestehende Workflows einbetten.

Voraussetzungen

Docker Engine 20.10+ und Docker Compose Plugin v2.0+ (docker compose, nicht das veraltete docker-compose) auf einem Linux-Host – eine Installationsanleitung findest du unter Docker und Docker Compose auf Linux installieren.
Linux-Host, VM oder NAS mit mindestens 2 CPU-Kerne, 4 GB RAM und 20 GB freiem Speicher (empfohlen: 4 Kerne, 8 GB RAM, 50+ GB SSD).
openssl auf dem Host für die Schlüsselgenerierung (in allen gängigen Linux-Distributionen vorinstalliert).
Öffentliche Domain mit DNS-Eintrag und ein Reverse-Proxy für HTTPS im Produktionsbetrieb (optional für lokale Tests).
SMTP-Zugangsdaten für E-Mail-Einladungen (optional, kann später nachgetragen werden).
Internetverbindung beim ersten Start – das Infisical-Image ist ca. 720 MB groß.

Schritt 1: Projektordner und Verzeichnisstruktur anlegen

Lege einen dedizierten Ordner für den Infisical-Stack an. Alle Konfigurationsdateien landen hier, Volumes werden von Docker intern verwaltet.

sudo mkdir -p /opt/infisical
cd /opt/infisical

Wenn du als unprivilegierter Benutzer arbeiten möchtest, kannst du den Ordner auch unter ~/infisical anlegen – die Befehle in dieser Anleitung funktionieren in beiden Varianten.

Verifizieren: Mit ls -la /opt/infisical prüfen, dass der Ordner existiert und der aktuelle Benutzer Schreibrechte hat. Erwartete Ausgabe: leeres Verzeichnis, Eigentümer ist dein Benutzer oder root.

Schritt 2: Kritische Secrets sicher generieren

Bevor du auch nur eine Konfigurationsdatei anlegst, generierst du die beiden Pflicht-Secrets. Der ENCRYPTION_KEY ist der wichtigste Wert im gesamten Setup: Er verschlüsselt alle Secrets in der Datenbank. Verlierst du ihn nach dem ersten Start, sind alle gespeicherten Daten unwiederbringlich verloren. Schreibe beide Werte sofort an einem sicheren Ort auf – zum Beispiel in deinen Passwortmanager.

# ENCRYPTION_KEY: 16-Byte-Hex-String (32 Zeichen)
openssl rand -hex 16

# AUTH_SECRET: 32-Byte-Base64-String
openssl rand -base64 32

Speichere die Ausgaben beider Befehle; du brauchst sie im nächsten Schritt für die .env-Datei. Die Befehle funktionieren auf Linux, macOS und Windows (WSL).

Verifizieren: Der erste Befehl liefert genau 32 Hexadezimalzeichen (z. B. a3f2e1c0b9d84712fe96a25c3b017e4d). Der zweite Befehl liefert einen Base64-String mit ca. 44 Zeichen. Sind die Ausgaben kürzer oder enthalten Fehlermeldungen, ist openssl nicht korrekt installiert.

Schritt 3: .env-Datei erstellen

Die .env-Datei enthält alle Umgebungsvariablen für Backend, PostgreSQL und Redis. Ersetze die Platzhalter durch deine zuvor generierten Werte. Wichtig: Ändere sicheres_db_passwort in beiden Zeilen (DB_CONNECTION_URI und POSTGRES_PASSWORD) auf denselben starken Wert ab.

# ============================================================
# Infisical – Umgebungsvariablen
# ACHTUNG: Diese Datei enthält kritische Secrets!
# Niemals in Git einchecken (.gitignore prüfen).
# ============================================================

# --- Infisical Backend ---
NODE_ENV=production
ENCRYPTION_KEY=DEIN_GENERIERTER_HEX_KEY_HIER
AUTH_SECRET=DEIN_GENERIERTER_BASE64_SECRET_HIER

# Öffentliche URL der Instanz (mit Protokoll, ohne abschließenden Slash)
# Für lokale Tests: http://localhost:80
# Im Produktionsbetrieb: https://infisical.deine-domain.de
SITE_URL=http://localhost:80

# Datenbankverbindung (zeigt auf den db-Container im internen Netzwerk)
DB_CONNECTION_URI=postgresql://infisical:sicheres_db_passwort@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=sicheres_db_passwort
POSTGRES_DB=infisical

# --- Optional: SMTP für E-Mail-Einladungen ---
# SMTP_HOST=smtp.dein-anbieter.de
# SMTP_PORT=587
# SMTP_USER=dein-smtp-nutzer
# SMTP_PASSWORD=dein-smtp-passwort
# SMTP_FROM_ADDRESS=infisical@deine-domain.de

Schränke die Dateirechte ein, damit andere Systembenutzer den Inhalt nicht lesen können:

chmod 600 /opt/infisical/.env

Verifizieren: Mit ls -la /opt/infisical/.env prüfen – die Ausgabe muss -rw------- (600) für den Eigentümer zeigen. Überprüfe außerdem, dass ENCRYPTION_KEY und AUTH_SECRET keine Platzhalter mehr enthalten: grep -c "DEIN_" /opt/infisical/.env sollte 0 zurückgeben.

Schritt 4: compose.yaml erstellen

Die compose.yaml definiert alle drei Services sowie das interne Docker-Netzwerk. PostgreSQL und Redis sind absichtlich nicht nach außen exponiert – nur Port 80 (Backend) ist von außen erreichbar. Mehr zu Netzwerken und Volumes erklärt die Grundlagen-Anleitung Docker-Netzwerke und Volumes richtig nutzen.

services:
  backend:
    container_name: infisical-backend
    image: infisical/infisical:v0.160.12
    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

Ein Hinweis zur Versionspinnung: Diese Anleitung verwendet infisical/infisical:v0.160.12 statt :latest, um unerwartete Breaking-Changes bei automatischen Pulls zu verhindern. Für Redis verwenden wir redis:7-alpine statt des unversionierten redis-Tags aus dem offiziellen Beispiel – das erhöht die Reproduzierbarkeit des Setups erheblich.

Verifizieren: Überprüfe die Syntax der Datei mit docker compose config im Projektordner. Bei fehlerfreier YAML-Syntax gibt der Befehl die vollständig expandierte Konfiguration aus. Erscheinen Fehlermeldungen wie yaml: line X: ..., prüfe Einrückungen (nur Leerzeichen, keine Tabs).

Schritt 5: Stack starten und Datenbankmigrationen abwarten

Starte alle drei Container im Hintergrund:

cd /opt/infisical
docker compose up -d

Docker lädt zunächst die Images herunter (beim ersten Start ca. 800–900 MB gesamt), startet dann PostgreSQL, wartet bis der Healthcheck grünes Licht gibt, und startet erst danach das Infisical-Backend. Das Backend führt beim ersten Start automatisch alle Datenbankmigrationen durch – das kann 30–60 Sekunden dauern.

Beobachte den Start live in den Logs:

docker compose logs -f backend

Das Backend ist bereit, wenn in den Logs eine Zeile wie Listening on port 8080 oder Server started successfully erscheint.

Verifizieren: Führe nach ca. 60 Sekunden folgende Befehle aus:

# Alle Container-Status prüfen
docker compose ps

# API-Statusendpunkt abfragen
curl -s http://localhost:80/api/status

Erwartete Ausgabe von docker compose ps: Alle drei Container zeigen running, der db-Container zeigt zusätzlich (healthy). Erwartete Ausgabe von curl: {"date":"...","message":"OK"}. Erscheint stattdessen Connection refused, weitere 30 Sekunden warten und dann erneut prüfen oder docker compose logs backend auf Fehlermeldungen untersuchen.

Schritt 6: Ersten Administrator-Account anlegen

Öffne jetzt http://localhost:80 (bzw. die IP oder Domain deines Hosts) im Browser. Du wirst direkt zur Registrierungsseite weitergeleitet.

Der erste registrierte Benutzer wird automatisch zum Instance-Administrator – melde dich daher sofort nach dem Start an, bevor andere Benutzer Zugriff auf die Instanz haben. Vergib ein starkes Passwort und notiere die Zugangsdaten sicher.

Nach der Registrierung führt ein Onboarding-Wizard durch die Anlage einer ersten Organisation und eines Projekts. Lege ein Testprojekt an und füge ein erstes Secret hinzu (z. B. TEST_KEY=HelloWorld), um die Verschlüsselungs-Pipeline zu testen.

Verifizieren: Nach dem Login zeigt die Web-UI das Infisical-Dashboard. Im Bereich „Admin Console" (über das Benutzermenü oben rechts erreichbar) sollte dein Benutzerkonto mit der Rolle „Instance Admin" angezeigt werden. Das zuvor angelegte Test-Secret erscheint im Projekt unter „Secrets".

Schritt 7: HTTPS und Reverse Proxy einrichten

Infisical selbst terminiert kein TLS. Für den Produktionsbetrieb schaltest du einen Reverse-Proxy vor, der HTTPS mit Let's-Encrypt-Zertifikaten übernimmt. Bewährt haben sich Caddy (automatisches HTTPS ohne manuelle Zertifikatsverwaltung), Traefik oder Nginx Proxy Manager.

Eine vollständige Anleitung für Caddy findest du unter Caddy als Reverse Proxy einrichten: Anfänger-Anleitung mit automatischem HTTPS, für Traefik unter Traefik als Docker-Reverse-Proxy mit automatischem HTTPS.

Nach der Einrichtung des Reverse Proxys musst du in der .env-Datei die SITE_URL auf deine HTTPS-Domain aktualisieren und den Stack neu starten:

# SITE_URL in .env anpassen:
# SITE_URL=https://infisical.deine-domain.de

# Backend neu starten, damit die neue SITE_URL aktiv wird
docker compose up -d --force-recreate backend

Verifizieren: Rufe https://infisical.deine-domain.de/api/status im Browser auf. Das Schloss-Symbol in der Adressleiste zeigt ein gültiges TLS-Zertifikat. Die API antwortet mit {"date":"...","message":"OK"}.

Schritt 8: Backups und Updates

PostgreSQL-Backup

Alle Secrets, Nutzer und Projektdaten liegen verschlüsselt in PostgreSQL. Richte regelmäßige Backups ein – ohne die Datenbank und den ENCRYPTION_KEY sind die Daten wertlos. Eine vollständige Anleitung zur Automatisierung findest du unter MySQL & PostgreSQL Backup automatisieren mit cron.

# 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

Datenbankmigrationen laufen bei Infisical automatisch beim Start des neuen Containers – dennoch ist ein Backup vor jedem Upgrade Pflicht, da Migrationen nicht ohne Weiteres rückgängig zu machen sind:

# 1. Backup erstellen (siehe oben)
# 2. Image-Tag in compose.yaml anpassen (z.B. v0.160.12 -> v0.161.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

Verifizieren: Nach dem Upgrade docker compose ps ausführen – alle Container zeigen running. curl -s http://localhost:80/api/status liefert wieder {"date":"...","message":"OK"}. Im Browser unter „Admin Console" die aktuelle Versionsnummer prüfen.

Eckdaten im Überblick

Eigenschaft	Wert
Image	infisical/infisical:v0.160.12 (Multi-Arch: 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 (vollständig Open Source)
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" in den Backend-Logs: PostgreSQL war beim Start des Backends noch nicht vollständig bereit. Lösung: start_period im Healthcheck der db-Service auf 15s oder 30s erhöhen und mit docker compose up -d --force-recreate neu starten. Außerdem sicherstellen, dass DB_CONNECTION_URI auf den Container-Namen db zeigt und Benutzername/Passwort mit POSTGRES_USER und POSTGRES_PASSWORD übereinstimmen.
ENCRYPTION_KEY verloren oder nach dem ersten Start geändert: Alle verschlüsselten Secrets sind permanent unlesbar. Es gibt keinen Wiederherstellungsweg. Einzige Option: Stack komplett neu aufsetzen und Secrets manuell neu eintragen. Deshalb den Schlüssel vor dem Start generieren und sicher extern aufbewahren.
Web-UI lädt, aber Login schlägt fehl oder OAuth-Callback-Fehler: Ursache ist fast immer eine falsch konfigurierte SITE_URL. Der Wert muss exakt der öffentlich erreichbaren URL entsprechen, inkl. Protokoll und ohne abschließenden Slash. Nach Änderung docker compose up -d --force-recreate backend ausführen.
PostgreSQL oder Redis von außen erreichbar: Prüfe, ob ports-Einträge für db oder redis in der compose.yaml vorhanden sind und entferne diese sofort. Redis läuft mit ALLOW_EMPTY_PASSWORD=yes – ein öffentlich erreichbarer Redis ohne Authentifizierung ist ein gravierendes Sicherheitsrisiko.
„port is already allocated" beim Start: Port 80 wird bereits von einem anderen Dienst genutzt. Ändere das Port-Mapping in compose.yaml auf einen freien Port, z. B. 8080:8080, und passe SITE_URL entsprechend an.
Breaking-Changes nach docker compose pull: Der :latest-Tag zieht automatisch die neueste Version. Immer eine konkrete Versionsnummer verwenden und das Changelog vor Updates lesen.
Datenbank-Migrations-Fehler beim Upgrade: Vor jedem Upgrade ein pg_dump-Backup erstellen. Schlägt die Migration fehl, das Backup einspielen (docker exec -i infisical-db psql -U infisical infisical < backup.sql) und das Issue im Infisical-GitHub-Repository melden.

Häufige Fragen

Wie generiere ich sichere Werte für ENCRYPTION_KEY und AUTH_SECRET?

Auf Linux, macOS oder in WSL unter Windows: 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). Beide Werte sofort in einem Passwortmanager ablegen und nie unverschlüsselt speichern.

Kann ich Infisical auf einem Raspberry Pi oder Apple-Silicon-Mac betreiben?

Ja. Das offizielle Image unterstützt linux/arm64 nativ, sodass es auf Raspberry Pi 4/5 (mit mindestens 4 GB RAM), Apple-Silicon-Macs und AWS-Graviton-Instanzen läuft. Ältere Raspberry-Pi-Modelle mit 2 GB RAM werden unter Last instabil.

Wie integriere ich Infisical in GitHub Actions oder GitLab CI?

Infisical stellt offizielle Integrationen für GitHub Actions, GitLab CI, Jenkins, CircleCI und Bitbucket bereit. Du erstellst in der Web-UI einen „Machine Identity"-Token für deine CI/CD-Pipeline, hinterlegst ihn als Repository-Secret, und rufst in deiner Pipeline infisical secrets auf, um Secrets zur Laufzeit zu injizieren – ohne sie je im Repository zu speichern.

Wie sichere ich die PostgreSQL-Datenbank regelmäßig?

Mit diesem Befehl erstellst du ein komprimiertes Backup: docker exec infisical-db pg_dump -U infisical -d infisical | gzip > backup_$(date +%Y%m%d).sql.gz. Wichtig: Das Datenbank-Backup ist ohne den ENCRYPTION_KEY wertlos. Bewahre beide Artefakte sicher und getrennt auf.

Wie führe ich ein Upgrade auf eine neue Version durch?

Erstelle ein Datenbank-Backup, passe den Image-Tag in der compose.yaml an, führe docker compose pull backend und anschließend docker compose up -d aus. Datenbankmigrationen laufen automatisch beim ersten Start des neuen Containers ab.

Welche SSO-Optionen unterstützt Infisical?

Infisical unterstützt SSO via SAML 2.0, LDAP/Active Directory, OIDC sowie Social Logins (GitHub, GitLab, Google). Für Kubernetes-Umgebungen stehen außerdem ein Secrets Operator und ein CSI Driver zur Verfügung.

Fazit

Infisical ist in weniger als 30 Minuten auf jedem Docker-fähigen Linux-Host einsatzbereit und bietet sofort eine vollwertige Secrets-Management-Plattform mit Web-UI, CI/CD-Integrationen und SDK-Unterstützung für alle gängigen Sprachen. Der entscheidende Unterschied zu einer einfachen Passwortdatenbank: Infisical ist als zentraler Verteiler für Secrets gebaut – Applikationen lesen Credentials zur Laufzeit aus, anstatt sie in Konfigurationsdateien oder Repositories zu speichern.

Die beiden kritischen Aspekte, die du von Anfang an richtig machen musst: den ENCRYPTION_KEY sicher generieren und extern aufbewahren, sowie regelmäßige PostgreSQL-Backups einrichten. Wer diese Hausaufgaben erledigt, bekommt eine robuste, produktionstaugliche Plattform, die HashiCorp Vault für die meisten KMU-Anwendungsfälle vollständig ersetzen kann – ohne Lizenzkosten und ohne Cloud-Abhängigkeit.

Für Umgebungen mit höheren Sicherheitsanforderungen empfiehlt sich zusätzlich das Absichern des Hosts nach dem Linux-Server-Härte-Prinzip mit UFW und Fail2ban sowie die Einbindung in eine zentrale Backup-Strategie nach dem 3-2-1-Backup-Prinzip.

Weiterführende Anleitungen und Quellen

Offizielle Quellen: Infisical Self-Hosting Docs (Docker Compose) · GitHub: Infisical/infisical · Infisical Umgebungsvariablen-Referenz