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

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/infisicalAlternativ 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 32Der 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.deSchränken Sie die Dateirechte ein:
$ chmod 600 /opt/infisical/.envls -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: bridgeAnders 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 -dDas 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 backendDas 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/statusdocker 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.

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.

Legen Sie unter „Secrets Management“ ein Testprojekt an und in „Development“ ein Secret wie TEST_KEY=HelloWorld.


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 backendhttps://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.gzUpgrade 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 backendBestehende 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-sidecarnicht mehr. Nur eigene Setups, die diese Datei aufrufen oder einbinden, müssen vor dem Update angepasst werden. - Neue optionale Variablen:
DISABLE_UPDATE_CHECK=trueschaltet die Versionsprüfung ab,KMS_ROOT_KEY_RETENTION_DAYSregelt, 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
| 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_periodimdb-Healthcheck auf30serhöhen, neu starten und prüfen, obDB_CONNECTION_URIaufdbzeigt und zuPOSTGRES_USER/POSTGRES_PASSWORDpasst.- 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_URLnicht exakt mit der öffentlichen URL überein (Protokoll, kein Slash am Ende). Danachdocker compose up -d --force-recreate backend.- PostgreSQL oder Redis von außen erreichbar
Entfernen Sie
ports-Einträge beidbundredis. 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 undSITE_URLanpassen.- Breaking-Changes nach
docker compose pull: Mit:latestkommt 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
- Docker und Docker Compose auf Linux installieren (Ubuntu/Debian)
- Docker Compose: Multi-Container-Stacks aufbauen
- Traefik als Docker-Reverse-Proxy mit automatischem HTTPS
- Caddy als Reverse Proxy: Anfänger-Anleitung mit automatischem HTTPS
- MySQL & PostgreSQL Backup automatisieren mit cron
- Vaultwarden produktiv betreiben: Argon2-Admin-Token, Fail2Ban und sicheres Backup
- Gitleaks mit Docker installieren: schneller Secret-Scanner für Git-Repositories
- 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


