n8n-Self-Hosting-Leitfaden: Docker, Kubernetes und Bare Metal in Produktion

Ich fahre n8n selbst gehostet seit 2022 über drei verschiedene Topologien: ein Single-VPS-Docker-Compose-Setup, einen kleinen Kubernetes-Cluster mit Queue-Mode und eine Bare-systemd-Installation auf einer gehärteten Debian-Box. Jede hat ihren Platz, und die falsche Wahl kostet Wochenenden. Dieser n8n-Self-Hosting-Leitfaden ist die Version, die ich am Anfang gebraucht hätte — geschrieben für Teams, die produktive Stabilität wollen, nicht eine Demo.

Kurzes Fazit vorweg: Docker Compose fahren, solange Sie physisch können. Kubernetes nur, wenn Sie es ohnehin für andere Services betreiben oder wirklich nördlich von 50.000 Executions pro Tag liegen. Der Bare-systemd-Pfad existiert für Leute wie mich, die minimalistische Stacks mögen und jedes bewegliche Teil verstehen wollen. Alle drei funktionieren. Der falsche Pfad fühlt sich wie ein zweiter Job an.

Wenn Sie noch zwischen Plattformen wählen: Make.com vs. n8n für produktive Workloads zuerst lesen. Wenn Sie von Zapier migrieren: Zapier zu n8n migrieren deckt die Mechanik. Deutschsprachig: n8n selbst hosten Anleitung ist der DACH-fokussierte Schwesterartikel.

Warum n8n selbst hosten

n8n Cloud ist ok. Für viele Teams geht die Rechnung ab einem bestimmten Volumen nicht mehr auf, und Self-Hosting bringt Kontrolle zurück. Meine Gründe, grob nach Häufigkeit der Entscheidung:

Datensouveränität und Compliance. Wenn Ihre Workflows PII, Finanzdaten oder Gesundheitsdaten berühren, weitet das Ausliefern jedes Execution-Payloads an einen SaaS-Multi-Tenant-Stack Ihren SOC2-Audit-Scope unnötig aus. DSGVO ist nicht abstrakt: Sie brauchen eine AVV für jeden externen Prozessor in der Kette, und Self-Hosting kollabiert diese Liste. Gleiche Logik bei HIPAA und PCI.

Kosten bei Volumen. n8n Cloud überquert die Self-Host-ROI-Linie irgendwo zwischen 10.000 und 20.000 Executions pro Monat, je nach Plan. Ein Hetzner CX32 VPS für rund acht Dollar monatlich fährt problemlos 100.000 Executions, wenn Ihre Workflows nicht CPU-heavy sind. Der Abstand wächst mit dem Volumen.

Custom-Nodes ohne Grenzen. Selbst gehostetes n8n lässt Sie Community-Nodes und eigene TypeScript-Nodes ins Data-Directory fallen, ohne zu fragen. Keine Allowlist-Gatekeeping.

Air-gapped und VPN-only-Integrationen. Viele interne Systeme sind nur aus dem Firmennetz erreichbar. Eine selbst gehostete n8n-Instanz im selben privaten Subnetz ruft sie direkt auf. Cloud kann das nicht.

Workflows in Git versionieren. Selbst gehostetes n8n kann Workflows als JSON exportieren und in ein Repo syncen — echtes Code-Review, PR-History, Rollback. So arbeiten seriöse Teams mit Automatisierung.

Entscheidung: Docker Compose vs. Kubernetes vs. Bare

Vor jeder Installation: den richtigen Pfad picken.

Docker Compose wählen, wenn Sie Solo-Engineer, kleines Team oder Consultancy sind, die Workflows für Kunden fährt. Ein Host, eine docker-compose.yml, langweilig und zuverlässig.

Kubernetes wählen, wenn Sie bereits einen Cluster für andere Services betreiben. Nicht Kubernetes nur für n8n hochziehen. Der Ops-Overhead lohnt sich unter grob 50.000 Executions pro Tag nicht.

Bare systemd + Node wählen, wenn Sie absolut minimale bewegliche Teile wollen, bereits eine gehärtete Debian- oder Ubuntu-Box für andere Services fahren oder lernen und jede Schicht sehen wollen. Ich fahre das auf meinem persönlichen VPS — aus denselben Gründen, aus denen ich systemd-Services für KI-Server bevorzuge.

Pfad 1: Docker-Compose-Produktions-Setup

Die langweilige Antwort, was sie für die meisten Leser zur richtigen macht. Ich fahre dieses Layout seit achtzehn Monaten unverändert.

Verzeichnis-Layout

sudo mkdir -p /opt/n8n/{data,db,files,caddy}
sudo chown -R 1000:1000 /opt/n8n/data /opt/n8n/files
cd /opt/n8n

Das data-Verzeichnis hält n8ns Workflow-Daten, installierte Community-Nodes und Credentials. db ist das Postgres-Volume. files ist für Binärdaten, die Workflows lesen oder schreiben. caddy hält Reverse-Proxy-Config und TLS-Zertifikate.

docker-compose.yml

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

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: redis-server --requirepass ${REDIS_PASSWORD}
    healthcheck:
      test: ["CMD", "redis-cli", "-a", "${REDIS_PASSWORD}", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5

  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: ${POSTGRES_DB}
      DB_POSTGRESDB_USER: ${POSTGRES_USER}
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_HOST: ${N8N_HOST}
      N8N_PROTOCOL: https
      N8N_PORT: 5678
      WEBHOOK_URL: https://${N8N_HOST}/
      GENERIC_TIMEZONE: ${GENERIC_TIMEZONE}
      EXECUTIONS_MODE: queue
      QUEUE_BULL_REDIS_HOST: redis
      QUEUE_BULL_REDIS_PASSWORD: ${REDIS_PASSWORD}
      EXECUTIONS_DATA_SAVE_ON_SUCCESS: none
      EXECUTIONS_DATA_MAX_AGE: 720
      N8N_LOG_LEVEL: info
      N8N_METRICS: "true"
    volumes:
      - ./data:/home/node/.n8n
      - ./files:/files
    ports:
      - "127.0.0.1:5678:5678"

  worker:
    image: n8nio/n8n:latest
    restart: unless-stopped
    command: worker
    depends_on:
      - n8n
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: ${POSTGRES_DB}
      DB_POSTGRESDB_USER: ${POSTGRES_USER}
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      EXECUTIONS_MODE: queue
      QUEUE_BULL_REDIS_HOST: redis
      QUEUE_BULL_REDIS_PASSWORD: ${REDIS_PASSWORD}
    volumes:
      - ./data:/home/node/.n8n
      - ./files:/files

  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile:ro
      - ./caddy/data:/data
      - ./caddy/config:/config
    depends_on:
      - n8n

.env-Datei

# /opt/n8n/.env
POSTGRES_USER=n8n
POSTGRES_PASSWORD=$(openssl rand -hex 24)
POSTGRES_DB=n8n
REDIS_PASSWORD=$(openssl rand -hex 24)
N8N_ENCRYPTION_KEY=$(openssl rand -hex 32)
N8N_HOST=n8n.example.com
GENERIC_TIMEZONE=Europe/Madrid

Echte Werte mit openssl rand erzeugen. Der N8N_ENCRYPTION_KEY ist das eine Secret, bei dessen Verlust jedes gespeicherte Credential dauerhaft unwiederbringbar wird. Am selben Tag im Password Manager sichern, an dem Sie ihn generieren.

Caddyfile

n8n.example.com {
    reverse_proxy n8n:5678
    encode gzip
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options nosniff
        Referrer-Policy strict-origin-when-cross-origin
    }
}

Hochfahren

docker compose pull
docker compose up -d
docker compose logs -f n8n

Auf die Editor is now accessible via-Zeile warten. Host aufrufen, Owner-Account erstellen — produktives n8n läuft.

Pfad 2: Kubernetes-Deployment

Diesen Pfad nur, wenn Sie bereits einen Cluster betreiben. Minimal viable Produktions-Layout braucht: Namespace, Secret für den Encryption-Key, ConfigMap für Nicht-Secret-Env, Deployment für den n8n-Hauptprozess, Deployment für Workers, StatefulSet oder externes Managed Postgres, Redis und Ingress mit cert-manager für TLS.

Namespace und Secrets

kubectl create namespace n8n
kubectl -n n8n create secret generic n8n-secrets \
  --from-literal=N8N_ENCRYPTION_KEY=$(openssl rand -hex 32) \
  --from-literal=DB_POSTGRESDB_PASSWORD=$(openssl rand -hex 24) \
  --from-literal=REDIS_PASSWORD=$(openssl rand -hex 24)

n8n-Deployment (Haupt)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: n8n
  namespace: n8n
spec:
  replicas: 1
  selector:
    matchLabels:
      app: n8n
  template:
    metadata:
      labels:
        app: n8n
    spec:
      containers:
        - name: n8n
          image: n8nio/n8n:latest
          ports:
            - containerPort: 5678
          envFrom:
            - configMapRef:
                name: n8n-config
            - secretRef:
                name: n8n-secrets
          volumeMounts:
            - name: data
              mountPath: /home/node/.n8n
          readinessProbe:
            httpGet:
              path: /healthz
              port: 5678
            initialDelaySeconds: 10
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /healthz
              port: 5678
            initialDelaySeconds: 30
            periodSeconds: 30
          resources:
            requests: { cpu: 500m, memory: 512Mi }
            limits: { cpu: 2, memory: 2Gi }
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: n8n-data

Der Haupt-Pod handhabt UI, API und Webhook-Traffic. Auf replicas: 1 lassen. Nur Workers skalieren horizontal.

Worker-Deployment mit HPA

apiVersion: apps/v1
kind: Deployment
metadata:
  name: n8n-worker
  namespace: n8n
spec:
  replicas: 2
  selector:
    matchLabels:
      app: n8n-worker
  template:
    metadata:
      labels:
        app: n8n-worker
    spec:
      containers:
        - name: worker
          image: n8nio/n8n:latest
          args: ["worker"]
          envFrom:
            - configMapRef:
                name: n8n-config
            - secretRef:
                name: n8n-secrets
          resources:
            requests: { cpu: 500m, memory: 512Mi }
            limits: { cpu: 2, memory: 2Gi }
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: n8n-worker
  namespace: n8n
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: n8n-worker
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target: { type: Utilization, averageUtilization: 70 }

Datenbank und Redis

Postgres: wenn möglich Managed-Service nutzen. RDS, Cloud SQL und Hetzner Managed Postgres funktionieren. Alternative: Postgres-StatefulSet mit PVC — auch ok, aber ein zusätzliches Backup-Objekt. Redis kann als einfaches Deployment mit ClusterIP-Service laufen, weil Queue-State aus der DB recoverbar ist, falls Redis verloren geht.

Ingress mit cert-manager

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: n8n
  namespace: n8n
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/proxy-body-size: 64m
spec:
  ingressClassName: nginx
  tls:
    - hosts: [n8n.example.com]
      secretName: n8n-tls
  rules:
    - host: n8n.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service: { name: n8n, port: { number: 5678 } }

Helm-Alternative

Die Community-Helm-Chart 8gears/n8n ist in Ordnung, wenn Sie keine Manifests selbst schreiben wollen. Ich bevorzuge explizites YAML, weil ich es in sechs Monaten lesen und verstehen kann. Ihre Wahl.

Pfad 3: Bare systemd + Node

Minimal-Stack. Kein Docker, kein Kubernetes. Nur Node, Postgres, nginx.

Installation

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs postgresql nginx certbot python3-certbot-nginx
sudo useradd -m -s /bin/bash n8n
sudo -u n8n npm install -g n8n

Postgres

sudo -u postgres createuser --pwprompt n8n
sudo -u postgres createdb -O n8n n8n

systemd-Unit

# /etc/systemd/system/n8n.service
[Unit]
Description=n8n workflow automation
After=network.target postgresql.service

[Service]
Type=simple
User=n8n
WorkingDirectory=/home/n8n
Environment="DB_TYPE=postgresdb"
Environment="DB_POSTGRESDB_HOST=127.0.0.1"
Environment="DB_POSTGRESDB_DATABASE=n8n"
Environment="DB_POSTGRESDB_USER=n8n"
Environment="DB_POSTGRESDB_PASSWORD=REPLACE_ME"
Environment="N8N_ENCRYPTION_KEY=REPLACE_ME"
Environment="N8N_HOST=n8n.example.com"
Environment="N8N_PROTOCOL=https"
Environment="WEBHOOK_URL=https://n8n.example.com/"
Environment="GENERIC_TIMEZONE=Europe/Madrid"
ExecStart=/usr/bin/n8n start
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now n8n
sudo journalctl -u n8n -f

Dieselben Hardening-Patterns, die ich sonst nutze, gelten: ProtectSystem=strict, NoNewPrivileges=true, dediziertes Datenverzeichnis unter /home/n8n/.n8n. Siehe systemd-Services für KI-Server für die vollständige Hardening-Vorlage und Linux-VPS-KI-Dev-Setup für das Base-Image.

nginx + certbot

server {
    listen 443 ssl http2;
    server_name n8n.example.com;

    ssl_certificate /etc/letsencrypt/live/n8n.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/n8n.example.com/privkey.pem;

    client_max_body_size 64m;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        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;
    }
}

sudo certbot --nginx -d n8n.example.com einmal laufen lassen, Cron übernimmt die Erneuerung.

Produktive Konfiguration, die zählt

Diese Settings gelten für alle drei Pfade. Die Defaults sind auf Dev getunt, nicht auf Prod.

• EXECUTIONS_MODE=queue trennt Execution vom Hauptprozess. Pflicht bei ernsthaftem Load.
• EXECUTIONS_DATA_SAVE_ON_SUCCESS=none stoppt n8n davon, für jeden erfolgreichen Lauf eine Zeile in die Executions-Tabelle zu schreiben. Auf einer busy Instance verhindert das allein Postgres-Bloat. Error-Records behalten.
• EXECUTIONS_DATA_MAX_AGE=720 behält Execution-History für 30 Tage (Wert in Stunden). An Audit-Anforderungen anpassen.
• GENERIC_TIMEZONE=Europe/Madrid oder wo Sie sind. Cron-Trigger respektieren das.
• N8N_BASIC_AUTH_ACTIVE=true mit Passwort — Minimum. n8n nie ohne Auth öffentlich fahren. Für echte Teams Authelia oder Authentik als Forward-Auth davor.
• N8N_LOG_LEVEL=info in Produktion. debug flutet das Journal.
• N8N_METRICS=true exponiert /metrics für Prometheus.

Backups, die Sie wirklich wiederherstellen können

Nie getestete Backup-Pläne sind Fiktion. Meiner ist ein nächtlicher systemd-Timer mit drei Aufgaben:

#!/usr/bin/env bash
# /usr/local/bin/n8n-backup.sh
set -euo pipefail
TS=$(date -u +%Y%m%dT%H%M%SZ)
DEST=/var/backups/n8n

mkdir -p "$DEST"
docker compose -f /opt/n8n/docker-compose.yml exec -T postgres \
  pg_dump -U n8n n8n | gzip > "$DEST/db-$TS.sql.gz"
tar czf "$DEST/data-$TS.tar.gz" -C /opt/n8n data files
cp /opt/n8n/.env "$DEST/env-$TS.bak"

restic -r "$RESTIC_REPOSITORY" backup "$DEST"
find "$DEST" -type f -mtime +7 -delete

Drei Dinge werden gesichert: Postgres-Dump, Data- und Files-Verzeichnis (Custom-Nodes und Binary-Payloads) und die .env mit Encryption-Key. Off-Box mit restic oder borg pushen. Der Encryption-Key liegt auch im Password Manager — geht er verloren, ist jedes gespeicherte Credential totes Gewicht.

Dann der Teil, der zählt: Einmal im Jahr das Backup auf einen frischen VPS restoren und einloggen versuchen. Wenn das nicht klappt, existiert der Plan nicht. Termin setzen.

Security

n8n ist eine authentifizierte Webapp mit Root-Level-Zugriff auf alles, was Sie anschließen. So behandeln.

• UI nie ohne Auth exponieren. Basic-Auth ist Minimum, SSO-Forward-Auth via Authelia oder Authentik besser.
• Webhook-URLs sind die Angriffsfläche. Sie sind öffentlich by design. Jeden Input im Workflow validieren. Am Reverse-Proxy rate-limiten. Für M2M-Webhooks die Webhook-Auth-Header-Option nutzen.
• ufw default-deny-inbound, nur 22, 80, 443. Postgres und Redis auf Docker-Netzwerk oder localhost.
• fail2ban am Reverse-Proxy, der auf 401-Floods gegen die Login-Page achtet.
• Wöchentliche Image-Updates. Ich fahre einen Cron, der sonntags n8nio/n8n:latest pulled und den Stack neu startet. Watchtower macht dasselbe, wenn Sie das bevorzugen.
• Rotation des N8N_ENCRYPTION_KEY ist keine lockere Operation. Erfordert Re-Encryption jedes Credentials in der DB, das n8n per CLI-Kommando unterstützt — aber Sie müssen den alten Key haben. Planen, nicht panisch rotieren.

n8n skalieren: echte Zahlen

Aus Messungen an eigenen Instanzen und Kunden-Deployments:

• Single-Instance, kein Queue-Mode: 10 bis 20 parallele Executions, bevor die UI ruckelt. Passt für Fünfer-Team mit ein paar Dutzend Workflows.
• Queue-Mode, ein Host, 2 bis 4 Workers: 100 bis 500 parallele Executions, 50.000 pro Tag komfortabel. Hier topen die meisten Self-Hoster aus, und die meisten brauchen nie mehr.
• Kubernetes mit HPA auf Workers: der Bottleneck verschiebt sich zu Postgres. Connection-Pool-Exhaustion ist das erste Symptom. Auf pgbouncer wechseln oder Managed Postgres mit höherem Connection-Limit.
• Multi-Region oder Multi-Cluster: n8n wurde nicht für Active-Active designt. Lässt sich fahren, aber Sie besitzen jeden Edge-Case. Jenseits dieses Punkts ist eine dedizierte Orchestrierungsplattform meist der richtige Call.

Wann Docker Compose nicht mehr reicht

Konkrete Trigger, die den Wechsel zu Kubernetes rechtfertigen:

• Mehr als 100.000 Executions pro Tag und Postgres ist auch nach pgbouncer Ihr Bottleneck.
• Zero-Downtime-Upgrades sind vertraglich Pflicht. Blue-Green ist auf Kubernetes deutlich sauberer.
• Sie haben ein Platform-Team, das jeden Service auf Kubernetes fährt und Konsistenz will.
• Sie brauchen Multi-Region-Failover und haben Active-Active-Postgres.

Greift nichts davon: auf Docker Compose bleiben.

KI-Workflows auf selbst gehostetem n8n

Selbst gehostetes n8n fährt dieselben LangChain- und KI-Nodes wie Cloud. Ich rufe Claude für die meiste Agent-Arbeit über den HTTP-Request-Node auf — einfacher zu durchschauen als die abstrahierten LangChain-Wrapper. Das Pattern:

1. Trigger (Webhook oder Schedule).
2. Datenvorbereitung in einem Code-Node.
3. HTTP-Request-Node gegen https://api.anthropic.com/v1/messages mit API-Key in Credentials und Prompt-Caching am System-Block. Die Patterns aus Claude-API-Prompt-Caching portieren direkt.
4. Response parsen mit Code-Node oder Tool-Use-Structured-Output-Pattern. Siehe Claude-API-Structured-Output für das Prefill-Pattern.
5. Side-Effects: DB schreiben, Slack posten, CRM updaten.

Für schwerere Agent-Logik schlägt ein Code-Node mit kurzer TypeScript-Function, die das Anthropic-SDK aufruft, das Verdrahten komplexen States durch Nodes. Für echten MCP-Server-Zugriff aus n8n funktioniert das HTTP-Bridge-Pattern aus MCP-Server in TypeScript bauen.

Monitoring

N8N_METRICS=true aktivieren und Prometheus auf /metrics zeigen. Die vier Dashboards, die ich wirklich anschaue:

• Execution-Rate und Error-Rate pro Workflow.
• Execution-Dauer p95 und p99. Steigt etwas, degradiert entweder eine Drittanbieter-API oder ein Workflow regressed.
• Queue-Depth in Redis. Steigt sie ohne zu sinken, hängen Workers.
• Postgres-Connection-Pool-Usage und Slow-Query-Log.

Alerts, die ich verdrahte: Error-Rate über 2 Prozent für 5 Minuten, Queue-Depth über 100 für 10 Minuten, Worker-Pod unhealthy, Postgres-Connections über 80 Prozent. Alles andere ist Noise.

Upgrade-Pfad ohne Outage

n8n shipt Major-Versionen mit Breaking Changes, und die Release-Notes sind die einzige Quelle der Wahrheit. Mein Prozess:

1. Staging-Instance mit Kopie der Produktionsdaten. Neues Image pullen, starten, durch die kritischen Workflows klicken.
2. Image-Tags in Produktion auf konkrete Versionen pinnen, nicht latest, sobald Sie jenseits der Experimentierphase sind. n8nio/n8n:1.78.2 schlägt latest für Reproduzierbarkeit.
3. Auf Docker Compose: neues Image pullen, docker compose up -d, Logs beobachten. Eine Minute Downtime.
4. Auf Kubernetes: Blue-Green mit zwei Deployments und Service-Switch, oder Rolling Update, wenn die Workflows das tolerieren.
5. Vor jedem Major-Upgrade backuppen. Wenn die Migration scheitert, DB restoren und Image rollbacken.

Das ist das ganze Playbook. n8n-Self-Hosting ist langweilig, sobald es aufgesetzt ist — das ist der Punkt. Das Setup zahlt sich im ersten Monat zurück, in dem Sie kein Credential an einen Drittanbieter-SaaS ausliefern oder Execution-Kosten gegenüber Ihrer Finance erklären.

Weiterführendes

• Make.com vs. n8n für produktive Workloads
• Zapier zu n8n migrieren
• n8n selbst hosten Anleitung
• Make vs. n8n Vergleich
• systemd-Services für KI-Server
• Linux-VPS für KI-Dev-Setup