n8n Docker installieren: Docker-Compose-Anleitung 2026

Kurzantwort: n8n lässt sich mit Docker in wenigen Minuten lokal starten. Für einen dauerhaften Unternehmenseinsatz braucht die Installation zusätzlich persistente Daten, eine feste Verschlüsselung, PostgreSQL, HTTPS, einen Reverse Proxy, Backups, Updates, Monitoring und geregelte Zugriffe. Docker verpackt die Anwendung zuverlässig in Container. Den sicheren Betrieb und die Qualität der automatisierten Prozesse übernimmt Docker nicht automatisch.

Diese Anleitung zeigt dir zuerst einen schnellen Test mit dem offiziellen n8n-Docker-Image. Danach folgt eine belastbarere Docker-Compose-Konfiguration mit PostgreSQL sowie eine Checkliste für Sicherheit, Wartung und Skalierung. Zum Schluss erfährst du, wann n8n Docker gut passt und wann ein vollständiges Unternehmenssystem wie AI Cowork weniger internen Betriebsaufwand verursacht.

Stand der technischen Prüfung: 26. August 2026. n8n und seine Umgebungsvariablen entwickeln sich laufend weiter. Prüfe vor jeder Installation und jedem Update zusätzlich die verlinkte offizielle Dokumentation.

Was ist n8n Docker?

n8n ist eine Workflow-Automatisierungsplattform, die Anwendungen, APIs, Datenbanken und KI-Dienste miteinander verbindet. In einem visuellen Editor werden Trigger, Verarbeitungsschritte, Bedingungen und Aktionen zu Workflows zusammengestellt.

Docker führt n8n in einem Container aus. Der Container enthält Anwendung und benötigte Laufzeitkomponenten in einer reproduzierbaren Umgebung. Dadurch lässt sich dieselbe n8n-Version auf einem Notebook, einem Linux-Server oder einer virtuellen Maschine weitgehend konsistent bereitstellen.

Docker Compose beschreibt mehrere zusammengehörige Dienste in einer YAML-Datei. Für n8n kann eine Compose-Umgebung beispielsweise diese Komponenten enthalten:

• den n8n-Hauptprozess
• eine PostgreSQL-Datenbank
• persistente Volumes
• einen Reverse Proxy für HTTPS
• bei größerer Last Redis und zusätzliche Worker
• optional externe Task Runner und Monitoring

Was Docker löst und welche Aufgaben bleiben

n8n mit Docker installieren: Schneller lokaler Test

Für einen ersten Test genügt Docker Desktop oder Docker Engine mit funktionsfähigem Docker-Dienst. Der folgende Aufbau orientiert sich an der offiziellen n8n-Dokumentation. Er erstellt ein benanntes Volume und startet den Container auf Port 5678.

1. Docker und Compose prüfen

docker --version
docker compose version

Docker Compose V2 wird als docker compose mit Leerzeichen aufgerufen. Der ältere eigenständige Befehl docker-compose ist in vielen aktuellen Umgebungen nicht mehr die bevorzugte Variante.

2. Persistentes Volume anlegen

docker volume create n8n_data

Ohne ein persistentes Volume können Konfiguration und lokale Daten beim Entfernen des Containers verloren gehen.

3. n8n-Container starten

docker run -it --rm \
  --name n8n \
  -p 127.0.0.1:5678:5678 \
  -e GENERIC_TIMEZONE="Europe/Vienna" \
  -e TZ="Europe/Vienna" \
  -e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

Öffne anschließend http://localhost:5678. Die Bindung an 127.0.0.1 macht den Port nur auf dem lokalen Rechner erreichbar. Das ist für den Test sicherer als eine unbeschränkte Freigabe auf allen Netzwerkschnittstellen.

Seit n8n 2.0 ist die frühere Variable N8N_RUNNERS_ENABLED laut aktueller Dokumentation veraltet und für neue Installationen nicht mehr erforderlich. Kopiere ältere Compose-Beispiele deshalb nicht ungeprüft.

4. Container beenden

Da der Beispielcontainer interaktiv läuft, beendest du ihn mit Ctrl + C. Das Volume bleibt bestehen. Für einen dauerhaften Server ist Docker Compose übersichtlicher.

n8n mit Docker Compose und PostgreSQL installieren

n8n verwendet standardmäßig SQLite. Für lokale Tests oder kleine Einzelinstanzen kann das ausreichend sein. Bei einer produktiven Team- oder Unternehmensinstallation ist PostgreSQL meist die robustere Grundlage. n8n unterstützt PostgreSQL offiziell und nutzt es auch für skalierte Queue-Mode-Architekturen.

Das folgende Beispiel ist ein solider Ausgangspunkt für eine einzelne n8n-Instanz mit PostgreSQL. Es ersetzt keine individuelle Sicherheits- und Infrastrukturplanung.

1. Projektverzeichnis erstellen

mkdir n8n-docker
cd n8n-docker

Lege in diesem Verzeichnis eine .env-Datei und eine compose.yml an. Die .env-Datei darf nicht in ein öffentliches Git-Repository gelangen.

2. Umgebungsvariablen in der .env-Datei

N8N_VERSION=HIER_AKTUELLE_STABILE_VERSION_EINTRAGEN
N8N_HOST=n8n.example.com
N8N_ENCRYPTION_KEY=HIER_LANGEN_ZUFAELLIGEN_SCHLUESSEL_EINTRAGEN

POSTGRES_DB=n8n
POSTGRES_USER=n8n
POSTGRES_PASSWORD=HIER_LANGES_ZUFAELLIGES_PASSWORT_EINTRAGEN

Ersetze alle Platzhalter. Trage bei N8N_VERSION eine geprüfte, konkrete stabile Version ein. So bleibt ein Update eine bewusste Entscheidung. Einen zufälligen Schlüssel kannst du beispielsweise mit openssl rand -hex 32 erzeugen.

Der Wert von N8N_ENCRYPTION_KEY ist besonders wichtig. n8n verschlüsselt damit gespeicherte Zugangsdaten. Verliert eine wiederhergestellte Instanz diesen Schlüssel, kann sie die vorhandenen Credentials nicht mehr entschlüsseln.

3. compose.yml erstellen

name: n8n

services:
  postgres:
    image: postgres:18
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      PGDATA: /var/lib/postgresql/data
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 10
    networks:
      - backend

  n8n:
    image: docker.n8n.io/n8nio/n8n:${N8N_VERSION}
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_PORT: 5432
      DB_POSTGRESDB_DATABASE: ${POSTGRES_DB}
      DB_POSTGRESDB_USER: ${POSTGRES_USER}
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
      DB_POSTGRESDB_SCHEMA: public

      N8N_HOST: ${N8N_HOST}
      N8N_PORT: 5678
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://${N8N_HOST}/
      N8N_EDITOR_BASE_URL: https://${N8N_HOST}/
      N8N_PROXY_HOPS: 1

      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS: "true"
      GENERIC_TIMEZONE: Europe/Vienna
      TZ: Europe/Vienna

      EXECUTIONS_DATA_PRUNE: "true"
      EXECUTIONS_DATA_MAX_AGE: 168
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy
    networks:
      - backend

volumes:
  n8n_data:
  postgres_data:

networks:
  backend:

Das Beispiel bindet n8n nur an die lokale Adresse des Servers. Es geht davon aus, dass ein Reverse Proxy auf demselben Host HTTPS entgegennimmt und an 127.0.0.1:5678 weiterleitet. PostgreSQL erhält keinen öffentlich erreichbaren Port.

Die offizielle n8n-Dokumentation nutzt bei PostgreSQL 18 ausdrücklich PGDATA: /var/lib/postgresql/data. PostgreSQL 18 hat sein Standardverzeichnis geändert. Entferne diese Zeile bei der gezeigten Volume-Struktur nicht. Bei einer bestehenden älteren PostgreSQL-Version ist ein Major-Upgrade ein eigenes Datenbankprojekt mit Backup und geprüftem Migrationsweg.

4. Konfiguration prüfen und starten

docker compose config
docker compose pull
docker compose up -d
docker compose ps

Mit docker compose config erkennst du viele YAML- und Variablenfehler vor dem Start. Die Logs des n8n-Dienstes kannst du so verfolgen:

docker compose logs -f n8n

HTTPS und Reverse Proxy richtig konfigurieren

Eine produktive n8n-Instanz sollte über eine eigene Domain und HTTPS erreichbar sein. Der Reverse Proxy übernimmt TLS-Zertifikat, Weiterleitung und gegebenenfalls zusätzliche Schutzregeln. Geeignet sind beispielsweise Caddy, Nginx oder Traefik.

Vor dem Start müssen diese Punkte stimmen:

1. Der DNS-Eintrag der Domain zeigt auf den Server.
2. Die Firewall gibt nur die wirklich benötigten Ports frei, üblicherweise 80 und 443.
3. Port 5678 ist nicht ungeschützt aus dem Internet erreichbar.
4. N8N_HOST enthält die öffentliche Domain.
5. WEBHOOK_URL und N8N_EDITOR_BASE_URL verwenden die öffentliche HTTPS-Adresse.
6. N8N_PROXY_HOPS entspricht der Zahl vertrauenswürdiger Reverse Proxies vor n8n.

Minimales Nginx-Beispiel

location / {
  proxy_pass http://127.0.0.1:5678;
  proxy_http_version 1.1;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
}

Das Beispiel zeigt nur die Weiterleitung. Zertifikatsverwaltung, sichere TLS-Konfiguration, Rate Limits und Header müssen zur jeweiligen Serverumgebung passen.

Persistente Daten: Was muss gesichert werden?

Ein Container kann jederzeit neu erstellt werden. Geschäftsdaten und Schlüssel dürfen deshalb nicht ausschließlich im beschreibbaren Container-Dateisystem liegen.

PostgreSQL-Datenbank

PostgreSQL speichert Workflows, Ausführungen, Nutzerinformationen und verschlüsselte Credentials. Das Volume postgres_data hält diese Daten über Container-Neustarts hinaus persistent.

n8n-Verzeichnis

Auch bei PostgreSQL empfiehlt n8n weiterhin ein persistentes Volume für /home/node/.n8n. Dort können unter anderem Instanzinformationen, Logs und weitere lokale Assets liegen. Ein fest gesetzter N8N_ENCRYPTION_KEY erleichtert einen kontrollierten Restore auf einer neuen Instanz.

Binärdaten aus Workflows

Dateien, Bilder und andere Binärdaten benötigen eine eigene Planung. Speicherart und Aufbewahrungszeit hängen von n8n-Version, Betriebsmodus und Lizenz ab. Im Queue Mode unterstützt n8n keine Binärdatenablage im gemeinsam genutzten Dateisystem. Für externe S3-Speicherung gelten zusätzliche Produkt- und Lizenzvoraussetzungen.

Konfiguration und Schlüssel

Sichere zusätzlich die Compose-Datei, Proxy-Konfiguration, Versionsangaben und alle benötigten Secrets in einem geeigneten Passwort- oder Secret-Management. Secrets gehören weder in Screenshots noch in unverschlüsselte Support-Tickets.

n8n Docker sichern und wiederherstellen

Ein Backup ist erst belastbar, wenn die Wiederherstellung getestet wurde. Plane für n8n mindestens Datenbank, n8n-Volume, Verschlüsselungsschlüssel und Infrastrukturkonfiguration ein.

Beispiel für einen PostgreSQL-Dump

docker compose exec -T postgres \
  pg_dump -U n8n -d n8n \
  > n8n-postgres-backup.sql

Speichere den Dump anschließend verschlüsselt und getrennt vom Produktivserver. In einer echten Umgebung sollten Dateiname, Zeitstempel, Aufbewahrung und Offsite-Kopie automatisiert werden. Prüfe, ob die Werte für Benutzer und Datenbank zu deiner .env-Datei passen.

Restore-Test

1. Neue, isolierte Testumgebung bereitstellen.
2. Dieselbe oder eine kompatible n8n- und PostgreSQL-Version verwenden.
3. Datenbank und n8n-Volume wiederherstellen.
4. Den ursprünglichen N8N_ENCRYPTION_KEY einspielen.
5. Anmeldung, Credentials, Webhooks und ausgewählte Workflows testen.
6. Ergebnis und Wiederherstellungsdauer dokumentieren.

Ein JSON-Export einzelner Workflows ist eine sinnvolle zusätzliche Sicherung, ersetzt aber kein vollständiges Instanz-Backup.

n8n Docker sicher betreiben

n8n verarbeitet häufig E-Mails, Kundendaten, Zugangsdaten und interne Dokumente. Die Plattform besitzt deshalb weitreichende Berechtigungen. Ein kompromittierter Workflow kann mehrere verbundene Systeme betreffen.

Sicherheitscheck für Self-Hosting

• HTTPS erzwingen: Editor und Webhooks nur über gültige TLS-Verbindungen veröffentlichen.
• Firewall begrenzen: PostgreSQL, Redis und Port 5678 nicht öffentlich freigeben.
• Zugriffe minimieren: Nur benötigte Personen, Credentials und Systemrechte einrichten.
• Zwei-Faktor-Authentifizierung nutzen: Konten mit administrativen Rechten zusätzlich schützen.
• Secrets trennen: Schlüssel nicht in Workflows, Compose-Dateien oder Repositories fest eintragen.
• Community Nodes prüfen: Herkunft, Wartung, Berechtigungen und Code-Risiko vor Installation bewerten.
• Riskante Nodes begrenzen: Datei-, Shell-, Code- und Datenbankzugriffe nur für begründete Anwendungsfälle erlauben.
• Webhooks schützen: Authentifizierung, Signaturen, Rate Limits und Eingabevalidierung einplanen.
• Ausführungsdaten begrenzen: Fehler- und Produktionsdaten nur so lange speichern wie erforderlich.
• Updates überwachen: Sicherheitsmeldungen und Release Notes regelmäßig prüfen.
• Security Audit ausführen: n8n kann ungeschützte Webhooks, riskante Nodes, veraltete Instanzen und weitere Auffälligkeiten melden.

Der Audit lässt sich in einer Compose-Installation beispielsweise im Container starten:

docker compose exec n8n n8n audit

Das Ergebnis ist ein Prüfhinweis und keine vollständige Sicherheitsfreigabe. Netzwerk, Betriebssystem, Reverse Proxy, Datenbank, Backup, Identitätsmanagement und verbundene Anwendungen gehören ebenfalls in das Sicherheitskonzept.

n8n Docker aktualisieren

Automatische Updates auf eine ungeprüfte Version können produktive Workflows unterbrechen. Eine feste Versionsnummer in der .env-Datei macht den Wechsel nachvollziehbar.

1. Release Notes und mögliche Breaking Changes lesen.
2. Datenbank, n8n-Volume, Schlüssel und Konfiguration sichern.
3. Neue Version zuerst in einer Testumgebung starten.
4. Kritische Workflows, Webhooks und Credentials prüfen.
5. N8N_VERSION in der Produktivkonfiguration ändern.
6. Neues Image laden und Container kontrolliert neu erstellen.
7. Logs, Fehlerquote und Laufzeiten beobachten.

docker compose pull
docker compose up -d
docker compose logs --since=10m n8n

Ein Rollback kann eine Wiederherstellung der Datenbank erfordern, wenn die neue Version Migrationen ausgeführt hat. Das bloße Starten des alten Images ist dann möglicherweise nicht ausreichend.

n8n mit Docker skalieren: Queue Mode und Worker

Bei steigender Ausführungslast kann n8n im Queue Mode betrieben werden. Die Hauptinstanz nimmt Trigger und Webhooks an. Redis verwaltet die Warteschlange, während Worker die eigentlichen Workflow-Ausführungen übernehmen. Alle Komponenten greifen auf dieselbe PostgreSQL-Datenbank zu.

Für Queue Mode sind unter anderem erforderlich:

• PostgreSQL als gemeinsame Datenbank
• Redis als Queue-Broker
• identischer N8N_ENCRYPTION_KEY auf Hauptinstanz und Workern
• EXECUTIONS_MODE=queue für beteiligte n8n-Prozesse
• separate Worker-Container
• geeignete Speicherung für Binärdaten
• Health Checks, Monitoring und kontrolliertes Herunterfahren

Queue Mode erhöht Skalierbarkeit und zugleich die Zahl der zu betreibenden Komponenten. Für wenige, kurze Workflows ist diese Architektur meist unnötig. Bei kritischen oder stark schwankenden Lasten sollte sie geplant, getestet und überwacht werden.

Häufige Fehler bei n8n Docker und ihre Lösung

n8n ist unter der Domain erreichbar, Webhooks funktionieren nicht

Häufig stimmen WEBHOOK_URL, N8N_HOST, Protokoll oder Proxy-Header nicht. Prüfe die öffentliche HTTPS-Adresse und die Weiterleitung des Reverse Proxys.

Nach einem Neustart sind Workflows verschwunden

Meist fehlt ein persistentes Volume oder es wurde ein anderes Volume eingebunden. Prüfe Compose-Datei und vorhandene Volumes, bevor du neue Daten anlegst.

Credentials lassen sich nach dem Restore nicht verwenden

Die wiederhergestellte Instanz besitzt wahrscheinlich einen anderen Verschlüsselungsschlüssel. Verwende den ursprünglichen N8N_ENCRYPTION_KEY und behandle ihn wie ein kritisches Backup-Geheimnis.

PostgreSQL startet nach einem Versionswechsel nicht

Ein Major-Upgrade kann ein neues Datenformat verwenden. Ein Image-Tag-Wechsel migriert den Datenbestand nicht automatisch. Nutze das offizielle PostgreSQL-Upgrade-Verfahren und ein geprüftes Backup.

Der Container startet ständig neu

Prüfe docker compose logs n8n und docker compose logs postgres. Typische Ursachen sind ungültige Variablen, Datenbankfehler, Dateiberechtigungen oder zu wenig Arbeitsspeicher.

Der Server wird mit Ausführungsdaten immer voller

Aktiviere eine passende Datenbereinigung und kontrolliere Binärdaten, Logs sowie Datenbankgröße. Aufbewahrungszeiten sollten zum betrieblichen und rechtlichen Bedarf passen.

Ist n8n Docker für Unternehmen wirklich kostenlos?

Die n8n Community Edition kann selbst gehostet werden. Trotzdem entstehen Kosten für Server, Speicher, Domains, Backups, Monitoring, Updates, Entwicklung, Fehlerbehebung und Bereitschaft. Je nach benötigten Funktionen kommen kostenpflichtige n8n-Pläne hinzu. Bestimmte Funktionen für Zusammenarbeit, SSO, Umgebungen, Source Control, externe Secrets, Log Streaming oder externe Binärdatenspeicherung sind laut aktueller Produktübersicht an Business- oder Enterprise-Angebote gebunden.

Für eine realistische Kalkulation gehören folgende Positionen zusammen:

• Infrastruktur und Datentransfer
• n8n-Lizenz für benötigte Funktionen
• Arbeitszeit für Workflow-Entwicklung
• Serverbetrieb, Patches und Monitoring
• Backups und Restore-Tests
• Tests nach Updates von n8n und verbundenen APIs
• Dokumentation, Rechte und Vertretungsregelung
• Fehlerfolgen in angebundenen Systemen

Gerade im Mittelstand wird die interne Betriebszeit häufig unterschätzt. Ein günstiger Server kann sinnvoll sein. Der größere Aufwand entsteht oft durch Pflege und Verantwortung über mehrere Jahre.

n8n Docker oder AI Cowork: Welche Lösung passt?

n8n ist stark, wenn ein technisches Team Integrationen visuell modellieren und selbst betreiben möchte. Viele Unternehmen suchen jedoch eine einfachere Arbeitsoberfläche, über die Mitarbeitende E-Mails, Angebote, Aufgaben, Dokumente oder CRM-Vorgänge an spezialisierte KI-Mitarbeiter übergeben können.

n8n Docker passt gut, wenn

• Docker-, Server- und Sicherheitskompetenz intern vorhanden ist
• ein technisches Team Workflows selbst entwickeln und warten möchte
• klare, regelbasierte Integrationen im Mittelpunkt stehen
• Monitoring, Backup und Störungsbehebung organisatorisch geregelt sind
• die benötigten Governance-Funktionen zum gewählten n8n-Angebot passen

AI Cowork passt besser, wenn

• Fachabteilungen über eine einfache Oberfläche mit KI arbeiten sollen
• E-Mails, Meetings, Angebote, Aufgaben, CRM und Firmenwissen zusammengehören
• spezialisierte KI-Mitarbeiter statt einzelner Automatisierungsabläufe benötigt werden
• kritische Aktionen vor der Ausführung geprüft und freigegeben werden sollen
• das Unternehmen ein eigenes, modular erweiterbares System ohne laufende AI-Cowork-Lizenz möchte

Vom n8n-Prototyp zum kontrollierten KI-System

Ein bestehender n8n-Prototyp muss nicht verworfen werden. Er liefert wertvolle Erkenntnisse über Datenquellen, APIs und Prozessschritte. Vor dem Übergang in einen dauerhaft genutzten Unternehmensprozess empfehle ich fünf Prüfungen:

1. Prozess prüfen: Welche Aufgabe wird wirklich entlastet und wie wird der Erfolg gemessen?
2. Schnittstellen inventarisieren: Welche Systeme, Credentials und Datenarten sind beteiligt?
3. Risiken markieren: Welche Schritte verändern Kundendaten, versenden Nachrichten oder erzeugen finanzielle Folgen?
4. Freigaben festlegen: Welche Aktionen darf das System vorbereiten und wer genehmigt die Ausführung?
5. Betrieb entscheiden: Wer verantwortet Updates, Monitoring, Fehlerbehebung, Dokumentation und Vertretung?

Auf dieser Basis kann ein stabiler API-Schritt weiterhin genutzt, überarbeitet oder in einen spezialisierten KI-Mitarbeiter integriert werden. Der technische Workflow wird damit Teil eines geregelten Gesamtsystems.

Fazit: n8n Docker ist schnell installiert, der Betrieb entscheidet

Mit Docker lässt sich n8n sauber und reproduzierbar installieren. Ein lokaler Test benötigt nur ein Volume, das offizielle Image und Port 5678. Für den produktiven Einsatz gehören PostgreSQL, ein fester Verschlüsselungsschlüssel, HTTPS, Reverse Proxy, Backups, Updates, Monitoring und eine klare Verantwortlichkeit dazu.

Technische Teams erhalten mit n8n Docker eine flexible Grundlage für APIs und regelbasierte Workflows. Unternehmen ohne eigene Betriebs- und Automatisierungskompetenz sollten den Gesamtaufwand realistisch kalkulieren. Häufig ist ein individuell aufgebautes System mit fertigen Rollen, Firmenwissen und Freigaben schneller im Alltag nutzbar.

Starte deshalb mit einem klaren Anwendungsfall. Miss Zeitersparnis, Fehlerquote, Wartungsaufwand und Akzeptanz. Danach lässt sich fundiert entscheiden, ob n8n Docker intern betrieben oder der Prozess als virtueller KI-Mitarbeiter in AI Cowork umgesetzt wird.

Häufige Fragen zu n8n Docker

Quellen und weiterführende Informationen

• n8n-Dokumentation: Installation mit Docker
• n8n-Dokumentation: Installation mit Docker Compose
• Offizielle n8n-Hosting-Beispiele für Docker Compose
• n8n-Dokumentation: Queue Mode und Worker
• n8n-Dokumentation: Security Audit
• n8n-Dokumentation: Externe Speicherung von Binärdaten
• Docker-Dokumentation: Docker Compose
• n8n: Aktuelle Pläne und Funktionsübersicht

Über den Autor

Peter Krause

KI-Berater, Buchautor & Gründer

Über Peter Krause LinkedIn KI-Buch