Zum Hauptinhalt springen
S-EDV news
← Alle Anleitungen
📘 Anleitung Sicherheit & Datenschutz 12.08.2026 · 10 min Lesezeit Geprüft 22.10.2026

Infisical mit Docker installieren: Open-Source-Plattform für Secrets Management

Infisical selbst hosten: Secrets Management mit Docker Compose, PostgreSQL und Redis. Die Anleitung zeigt Installation und Ersteinrichtung von v0.167.0, den sicheren Umgang mit ENCRYPTION_KEY, Backups und Updates.

Werbung Mit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Mehr dazu

Titelbild: Infisical mit Docker installieren, Secrets, Teams, Rechte

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.

Voraussetzungen

  • Docker Engine 20.10+ und Docker Compose Plugin v2.0+ auf einem Linux-Host, siehe Docker und Docker Compose auf Linux installieren.
  • 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.

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

Alternativ funktioniert ~/infisical; passen Sie dann die Pfade in den Befehlen an.

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.

# ENCRYPTION_KEY: 16-Byte-Hex-String (32 Zeichen)
$ openssl rand -hex 16
# AUTH_SECRET: 32-Byte-Base64-String
$ openssl rand -base64 32

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.

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

# --- Infisical Backend ---
NODE_ENV=production
ENCRYPTION_KEY=IHR_GENERIERTER_HEX_KEY_HIER
AUTH_SECRET=IHR_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.ihre-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.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:

$ chmod 600 /opt/infisical/.env

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.

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:

$ cd /opt/infisical
$ docker compose up -d

Das Backend startet erst, wenn der Healthcheck der Datenbank besteht, und spielt dann die Migrationen ein.

Den Start verfolgen Sie im Log:

$ 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.

Führen Sie nach etwa 90 Sekunden aus:

# Alle Container-Status prüfen
$ docker compose ps
# API-Statusendpunkt abfragen
$ 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
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
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
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
Server Console: Signup mode „Disabled“ nach der Ersteinrichtung.

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 und Traefik als Docker-Reverse-Proxy mit automatischem HTTPS.

Stellen Sie danach SITE_URL in der .env auf die HTTPS-Domain um:

# 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

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.

# 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:

# 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.

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

EigenschaftWert
Imageinfisical/infisical:v0.167.0 (amd64/arm64)
Begleit-Imagespostgres:14-alpine, redis:7-alpine
Öffentlicher Port80 → intern 8080 (für Produktion: Reverse Proxy auf 443)
Interne Ports (nicht exponieren)5432 (PostgreSQL), 6379 (Redis)
Volumespg_data (Secrets, Nutzer, Konfig), redis_data (Cache/Job-Queue)
LizenzMIT für den Kern, Enterprise-Funktionen im Ordner ee/ unter eigener Lizenz
Mindestanforderungen2 CPU, 4 GB RAM, 20 GB Speicher
Empfohlen (Produktion)4 CPU, 8 GB RAM, 50+ GB SSD
ARM-SupportJa (linux/arm64 nativ, z. B. Raspberry Pi 4/5, Apple Silicon)
UmgebungsvariablePflichtBeschreibung
ENCRYPTION_KEYJa16-Byte-Hex; verschlüsselt alle Secrets at rest: NIEMALS nach Erststart ändern
AUTH_SECRETJa32-Byte-Base64; JWT-Signing-Secret für Session-Tokens
SITE_URLJaAbsolute URL inkl. Protokoll (für Callbacks und OAuth)
DB_CONNECTION_URIJaPostgreSQL-Verbindungsstring; Nutzer benötigt vollständige Rechte
REDIS_URLJaRedis-Verbindungsstring; für TLS rediss:// statt redis://
NODE_ENVJaMuss „production“ sein
HOSTNeinStandard: localhost; für externen Zugriff auf 0.0.0.0 setzen
SMTP_HOST/PORT/USER/…NeinE-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 und binden Sie die Sicherung in eine 3-2-1-Backup-Strategie ein.

Weiterführende Anleitungen und Quellen

  1. Docker und Docker Compose auf Linux installieren (Ubuntu/Debian)
  2. Docker Compose: Multi-Container-Stacks aufbauen
  3. Traefik als Docker-Reverse-Proxy mit automatischem HTTPS
  4. Caddy als Reverse Proxy: Anfänger-Anleitung mit automatischem HTTPS
  5. MySQL & PostgreSQL Backup automatisieren mit cron
  6. Vaultwarden produktiv betreiben: Argon2-Admin-Token, Fail2Ban und sicheres Backup
  7. Gitleaks mit Docker installieren: schneller Secret-Scanner für Git-Repositories
  8. Single Sign-On für den Self-Hosted-Stack: Authentik vs. Authelia mit Traefik Forward-Auth

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