Guide: n8n-Workflow-Automatisierung im Produktionseinsatz

Guide: MinIO als S3-kompatibles Backup-Ziel

Selbst gehosteter, S3-kompatibler Objektspeicher für Backups: MinIO hinter einem Nginx-Proxy, dazu ein rclone-basierter Backup-Agent mit versionierten Buckets. Ihre Offsite-Backups ohne Cloud-Rechnung

Guide: MinIO als S3-kompatibles Backup-Ziel

Selbst gehosteter, S3-kompatibler Objektspeicher für Backups: MinIO hinter einem Nginx-Proxy, dazu ein rclone-basierter Backup-Agent mit versionierten Buckets. Ihre Offsite-Backups ohne Cloud-Rechnung

n8n im Queue-Modus mit Redis, PostgreSQL-Persistenz und sauberem Prozess-Supervising — das unspektakuläre, zuverlässige Setup, das Neustarts und Lastspitzen übersteht. Die Automatisierungsschicht hinter mehreren meiner eigenen Integrationen.

Was das ist

Ein Deployment-Guide mit lauffähigen Beispielen — kein herunterladbares Produkt. Alles unten ist die tatsächlich eingesetzte Konfiguration, gekürzt auf das, worauf es ankommt.

Deployment-Beispiel

services:
  n8n:
    image: n8nio/n8n:${N8N_VERSION:-2.37.11}
    container_name: n8n
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    volumes:
      - n8n_data:/home/node/.n8n
      - ./config/n8n:/home/node/.n8n/custom:ro
    ports:
      - ${N8N_PORT:-5678}:5678
    environment:
      - N8N_HOST=${N8N_HOST:-localhost}
      - N8N_PORT=5678
      - N8N_PROTOCOL=${N8N_PROTOCOL:-http}
      - NODE_ENV=production
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_USER=${POSTGRES_USER:-n8n}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD:?POSTGRES_PASSWORD is required}
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB:-n8n}
      - DB_POSTGRESDB_POOL_SIZE=${DB_POOL_SIZE:-3}
      - EXECUTIONS_DATA_PRUNE=${EXECUTIONS_DATA_PRUNE:-true}
      - EXECUTIONS_DATA_MAX_AGE=${EXECUTIONS_DATA_MAX_AGE:-336}
      - EXECUTIONS_DATA_PRUNE_TIMEOUT=${EXECUTIONS_DATA_PRUNE_TIMEOUT:-3600000}
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY:?N8N_ENCRYPTION_KEY is required}
      - N8N_USER_FOLDER=/home/node/.n8n
      - REDIS_ENABLED=${REDIS_ENABLED:-true}
      - REDIS_HOST=redis
      - REDIS_PORT=${REDIS_PORT:-6379}
      - REDIS_PASSWORD=${REDIS_PASSWORD:?REDIS_PASSWORD is required}
      - EXECUTIONS_MODE=${EXECUTIONS_MODE:-queue}
      - N8N_METRICS=${N8N_METRICS:-false}
    healthcheck:
      test:
        - CMD
        - wget
        - --spider
        - http://localhost:5678/healthz
      interval: 30s
      timeout: 10s
      retries: 3
    networks:
      - n8n_network

Auszug — n8n aus der Compose-Datei. Die übrigen Services (proxies, init jobs, exporters) folgen demselben Muster und binden ihre Konfiguration aus einem config/-Verzeichnis ein.

Wesentliche Umgebungsvariablen

Kopieren Sie .env.example zu .env und setzen Sie mindestens:

N8N_VERSION=latest
N8N_HOST=n8n.example.com
N8N_PORT=5678
N8N_PROTOCOL=https
N8N_ENCRYPTION_KEY=super_secret_encryption_key_here_32_bytes_long
N8N_METRICS=false

Produktions-Checkliste

• Starke, eindeutige Secrets in .env setzen — niemals die Beispielwerte übernehmen
• Image-Versionen pinnen und Upgrades zuerst auf einer Staging-Kopie testen
• Backups einrichten und einen Restore-Test durchführen, bevor man sich darauf verlässt
• Den Stack über TLS erreichen und Management-UIs auf VPN oder Allowlist beschränken
• Den Stack von Tag eins an in Monitoring und Alerting einbinden

Wie der Queue-Mode einen Workflow verarbeitet

Wer den Pfad versteht, versteht die Stellschrauben. Ein Trigger feuert im Hauptprozess, der die Ausführung als Job serialisiert und auf Redis legt. Ein freier Worker greift den Job, lädt die Workflow-Definition aus PostgreSQL, führt jeden Knoten aus und schreibt die Ausführungsdaten (Schritte, Ein- und Ausgabe, Timing) zurück in die Datenbank. Die UI führt nie Ihre Logik aus — sie liest nur den Status aus PostgreSQL und legt neue Jobs auf die Queue. Deshalb verlangsamt ein schwerer Workflow nichts außer seiner eigenen Ausführung, warum ein abgestürzter Worker nur den Job verliert, den er hielt (Redis liefert erneut aus), und warum der Durchsatz mit Worker-Anzahl mal Konkurrenz pro Worker skaliert — nicht mit einer größeren Maschine.

Worker dimensionieren ohne Raten

Starten Sie mit einem Worker bei Standard-Konkurrenz und beobachten Sie zwei Zahlen: die Queue-Tiefe (Jobs, die in Redis warten) und die Dauer-Perzentile der Ausführungen. Eine Queue-Tiefe, die zwischen Spitzen auf null zurückgeht, heißt: alles gut. Eine Tiefe, die während der Geschäftszeiten monoton steigt, ist ein Dimensionierungs-Signal — dann kommt ein zweiter Worker dran, statt die Konkurrenz über das hinaus zu erhöhen, was Postgres und die Upstream-APIs verkraften. Jeder Worker ist ein Node-Prozess, die Speicherrechnung ist also linear und vorhersehbar: etwa das Basis-Image plus die Daten, die Ihre größten Workflows im Hauptspeicher halten.

Secrets-Hygiene

Die Compose-Datei verlangt drei Secrets, bevor sie überhaupt startet — das ist die Untergrenze, nicht die Decke. Jedes mit openssl rand -base64 32 generieren, nie eines über Services wiederverwenden, und in der .env mit 600-Rechten halten, die der Stack liest, kein Backup-Job aber sollte. Der Encryption-Key verlangt Sonderbehandlung: Er ist das einzige Secret, dessen Verlust Daten zerstört statt nur Zugriff — er gehört also in den Passwort-Manager und in eine kalte Kopie, nicht nur auf den Server. Redis- und Postgres-Passwörter jährlich rotieren — ein fünfminütiger Compose-Restart schlägt jede Erklärung nach einem Leak.

FAQ

Warum Queue-Mode statt dem n8n-Standard? Im Standardmodus teilen sich Web-UI und jede Workflow-Ausführung einen Prozess — ein schwerer Workflow kann den Editor einfrieren. Der Queue-Mode legt Ausführungen auf Redis und lässt separate Worker-Prozesse sie abarbeiten: Die UI bleibt unter Last bedienbar, und mehr Kapazität bedeutet mehr Worker, kein größerer Server.

Warum PostgreSQL statt dem Standard-SQLite? SQLite erlaubt genau einen Schreiber gleichzeitig — das kollidiert mit mehreren Workern, die zugleich Ausführungsdaten schreiben. PostgreSQL verkraftet die parallelen Schreibzugriffe, bringt Point-in-Time-Recovery-Werkzeuge mit und macht Backups auf Datenbankebene zum gelösten Problem.

Was ist N8N_ENCRYPTION_KEY und warum ist er Pflicht? n8n verschlüsselt gespeicherte Credentials mit diesem Schlüssel; er ist kein Passwort, sondern die Wurzel des Credential-Tresors. Die Compose-Datei verweigert den Start ohne ihn (die :?-Syntax), weil ein Start mit Zufallsschlüssel zuvor gespeicherte Credentials unlesbar machen würde. Sichern — wer ihn verliert, verliert alle Credentials.

Wie verhindert man, dass Ausführungsdaten die Platte füllen? Execution-Pruning ist mit EXECUTIONS_DATA_PRUNE und EXECUTIONS_DATA_MAX_AGE von 336 Stunden — zwei Wochen — aktiv. Erfolgsdaten älter als das werden automatisch gelöscht; Fehlerdaten gehören in ein Monitoring-System, nicht auf Dauer in n8n.

Ein Guide, kein Produkt. Diese Seite ist Deployment-Dokumentation mit lauffähigen Beispielen — kein Zip, kein Download, kein Supportvertrag. Sie adaptieren die Muster auf Ihre eigene Umgebung, und das Ergebnis gehört Ihnen.

Wenn Sie das produktionsreif in Ihrer Infrastruktur wollen: Das vermittle ich im eintägigen Workshop n8n-Automatisierung — Details auf der Consulting-Seite.