Zwischen „das macht bei uns jemand von Hand“ und „dafür lassen wir Software entwickeln“ liegt eine große Lücke. n8n füllt genau diese: Workflows werden visuell zusammengesteckt, laufen auf eigener Infrastruktur, und wo die fertigen Bausteine nicht reichen, schreibt man ein paar Zeilen JavaScript oder Python. Seit die AI-Nodes dazugekommen sind, endet das nicht mehr bei „wenn A, dann B“.
Der entscheidende Unterschied zu Zapier oder Make: Die Daten verlassen das eigene Haus nicht. Bei Rechnungen, Personaldaten oder Kundenkommunikation ist das kein Nebenaspekt, sondern der Grund für die Entscheidung.
Vorab: die Lizenz
n8n steht unter einer „fair-code“-Lizenz, nicht unter einer klassischen Open-Source-Lizenz. Selbst hosten und intern nutzen ist ausdrücklich erlaubt und kostenlos. Nicht erlaubt ist, n8n als eigenes Hosting-Angebot weiterzuverkaufen. Wer die Plattform intern betreibt — also die große Mehrheit —, ist damit auf der sicheren Seite; wer daraus ein Produkt für Dritte bauen will, sollte vorher die Lizenzbedingungen lesen. Einige Enterprise-Funktionen (SSO, mehrere Main-Instanzen, Log-Streaming) hängen zusätzlich an einer kommerziellen Lizenz.
Variante 1: Docker Compose
Für eine einzelne Instanz auf einem Server reicht Compose. Wichtig ist von Anfang an PostgreSQL statt der SQLite-Standardeinstellung — dazu unten mehr.
services:
postgres:
image: postgres:16-alpine
restart: unless-stopped
environment:
POSTGRES_DB: n8n
POSTGRES_USER: n8n
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?bitte in .env setzen}
volumes:
- postgres_data:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U n8n -d n8n"]
interval: 10s
timeout: 5s
retries: 5
n8n:
image: docker.n8n.io/n8nio/n8n:latest
restart: unless-stopped
depends_on:
postgres:
condition: service_healthy
ports:
- "127.0.0.1:5678:5678"
environment:
# Verschlüsselt alle gespeicherten Credentials. Einmal setzen, nie ändern,
# getrennt vom Backup aufbewahren. Siehe Abschnitt "Betriebspraxis".
N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY:?bitte in .env setzen}
DB_TYPE: postgresdb
DB_POSTGRESDB_HOST: postgres
DB_POSTGRESDB_PORT: 5432
DB_POSTGRESDB_DATABASE: n8n
DB_POSTGRESDB_USER: n8n
DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
# Muss die von außen erreichbare Adresse sein, nicht die interne.
# Sonst zeigen erzeugte Webhook-URLs auf localhost.
N8N_HOST: n8n.example.com
N8N_PROTOCOL: https
WEBHOOK_URL: https://n8n.example.com/
GENERIC_TIMEZONE: Europe/Berlin
TZ: Europe/Berlin
# Ausführungshistorie nach 14 Tagen aufräumen, sonst wächst die
# Datenbank unbegrenzt weiter.
EXECUTIONS_DATA_PRUNE: "true"
EXECUTIONS_DATA_MAX_AGE: "336"
volumes:
- n8n_data:/home/node/.n8n
volumes:
postgres_data:
n8n_data:Der Port ist bewusst auf 127.0.0.1 gebunden — davor gehört ein Reverse Proxy mit TLS (Traefik, Caddy, nginx). Eine n8n-Instanz, die offen im Netz steht, ist ein Angriffsziel mit Zugriff auf sämtliche hinterlegten Zugangsdaten.
Variante 2: Helm-Chart
Für Kubernetes gibt es ein gepflegtes Community-Chart: community-charts/n8n (aktuell Chart 1.24.28 mit n8n 2.34.6). Es stammt nicht von n8n selbst, sondern aus der Community — deshalb gilt hier wie bei jedem Fremd-Chart: Version pinnen und Release Notes vor dem Upgrade lesen.
helm repo add community-charts https://community-charts.github.io/helm-charts
helm repo update
helm show values community-charts/n8n > values-default.yamlKleines Setup: eine Instanz, externe Datenbank
# values.yaml
db:
type: postgresdb
externalPostgresql:
host: postgres.datenbanken.svc.cluster.local
port: 5432
database: n8n
username: n8n
# Kein Passwort im Klartext: Secret mit dem Key `postgres-password`.
existingSecret: n8n-postgres
existingSecretPasswordKey: postgres-password
# Der Schlüssel für alle gespeicherten Credentials. Siehe Betriebspraxis.
existingEncryptionKeySecret: n8n-encryption-key
timezone: Europe/Berlin
main:
resources:
requests:
cpu: 200m
memory: 512Mi
limits:
memory: 2Gi
ingress:
enabled: true
className: traefik
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
hosts:
- host: n8n.example.com
paths:
- path: /
pathType: Prefix
tls:
- secretName: n8n-tls
hosts:
- n8n.example.comOhne weitere Angaben läuft n8n im Modus regular: Der Main-Pod führt die Workflows selbst aus. Für die meisten internen Automatisierungen genügt das.
Größeres Setup: Queue-Modus mit Workern
Sobald Workflows länger laufen, parallel starten oder viele Webhooks eintreffen, wird der Main-Pod zum Flaschenhals. Dann übernimmt der Queue-Modus: Der Main-Pod verteilt Jobs über Redis, Worker arbeiten sie ab, separate Webhook-Pods nehmen eingehende Requests entgegen.
db:
type: postgresdb
externalPostgresql:
host: postgres.datenbanken.svc.cluster.local
database: n8n
username: n8n
existingSecret: n8n-postgres
existingSecretPasswordKey: postgres-password
existingEncryptionKeySecret: n8n-encryption-key
# Redis als Job-Queue. Für Produktion besser eine bestehende, gesicherte
# Instanz über externalRedis einbinden als die mitgelieferte Subchart-Redis.
redis:
enabled: true
worker:
mode: queue
# Jobs, die ein Worker gleichzeitig bearbeitet. Runter, wenn die Workflows
# speicherhungrig sind — hoch, wenn sie überwiegend auf APIs warten.
concurrency: 10
autoscaling:
enabled: true
minReplicas: 2
maxReplicas: 8
resources:
requests:
cpu: 200m
memory: 512Mi
limits:
memory: 2Gi
webhook:
mode: queue
count: 2
# Binärdaten (Anhänge, PDFs, Bilder) nicht im Speicher halten. Im Queue-Modus
# ist S3 die saubere Wahl: alle Pods greifen auf denselben Speicher zu.
binaryData:
mode: s3
s3:
host: s3.example.com
bucketName: n8n-binary
bucketRegion: eu-central-1
existingSecret: n8n-s3
ingress:
enabled: true
className: traefik
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
hosts:
- host: n8n.example.com
paths:
- path: /
pathType: Prefix
tls:
- secretName: n8n-tls
hosts:
- n8n.example.comEin Detail, das leicht übersehen wird: binaryData.mode steht standardmäßig auf default, und das bedeutet „im Arbeitsspeicher“. Ein Workflow, der eine 200-MB-PDF verarbeitet, kippt damit den Pod. Im Queue-Modus kommt hinzu, dass Main-, Worker- und Webhook-Pods dieselben Binärdaten sehen müssen — spätestens dort führt an S3 oder einem geteilten Volume kein Weg vorbei.
Betriebspraxis
Der Encryption Key ist das Wichtigste. Er verschlüsselt sämtliche gespeicherten Credentials. Geht er verloren, sind alle hinterlegten Zugangsdaten unbrauchbar — auch mit intaktem Datenbank-Backup. Also: einmal erzeugen, in einem Secret-Store (Vault, Sealed Secrets, External Secrets) ablegen, getrennt vom Datenbank-Backup sichern und nie wieder ändern. Das Chart generiert bei leerem Feld selbst einen Schlüssel; für ein Setup, das jemand später wiederherstellen können soll, ist ein bewusst gesetzter Schlüssel in einem Secret der bessere Weg.
PostgreSQL von Anfang an. SQLite ist der Standard und funktioniert für die ersten Gehversuche. Es lässt sich aber nicht auf mehrere Pods verteilen, verträgt keine parallelen Schreibzugriffe und macht jede Migration später zur Fleißarbeit. Der Wechsel kostet am ersten Tag zehn Minuten und im sechsten Monat einen Nachmittag.
Ausführungshistorie begrenzen. Ohne Pruning wächst die Datenbank mit jedem Lauf. EXECUTIONS_DATA_PRUNE mit einem Maximalalter — oder im Chart die entsprechenden Werte — verhindert, dass die Instanz nach einem Jahr an ihrer eigenen Protokollierung erstickt.
Webhook-URL prüfen. Der häufigste Fehler bei Betrieb hinter einem Reverse Proxy: n8n kennt seine öffentliche Adresse nicht und erzeugt Webhook-URLs auf localhost:5678. Der externe Dienst kann sie dann nicht erreichen, und der Fehler äußert sich erst, wenn niemand mehr am Setup arbeitet. WEBHOOK_URL beziehungsweise webhook.url gehört gesetzt.
Zugriff absichern. n8n speichert API-Schlüssel, Datenbankzugänge und Mail-Konten. Die Instanz gehört hinter eine Authentifizierung — n8n bringt eigene Benutzerverwaltung mit, ein vorgelagerter Auth-Proxy (Authentik, Authelia) ist die stärkere Variante. Öffentliche Webhook-Pfade lassen sich davon gezielt ausnehmen.
Backups umfassen zwei Dinge: die PostgreSQL-Datenbank (Workflows, Credentials, Historie) und den Encryption Key. Eines ohne das andere ist wertlos.
Wofür man es tatsächlich einsetzt
Die überzeugendsten Anwendungen sind selten spektakulär — sie ersetzen Kleinarbeit, die niemand vermisst:
- Alarme bündeln: Meldungen aus Monitoring, Backup-Jobs und Zertifikatsprüfungen laufen in einem Workflow zusammen, werden gefiltert und landen im richtigen Chat-Kanal statt in fünf verschiedenen Postfächern. Wer bereits Uptime Kuma betreibt, kann dessen Webhooks direkt hier andocken.
- Onboarding: Neuer Mitarbeiter im HR-Tool angelegt → Konten in Microsoft 365 erzeugen, Gruppen zuweisen, Hardware-Ticket öffnen, Checkliste an die Führungskraft schicken.
- Formular zu Ticket: Kontaktformular der Website erzeugt ein Ticket im Helpdesk, legt den Kontakt im CRM an und bestätigt dem Absender den Eingang.
- Rechnungslauf: PDF-Rechnungen aus einem Postfach ziehen, in die Buchhaltungssoftware übertragen, Dubletten erkennen, Ausnahmen zur manuellen Prüfung melden.
- Datenabgleich: Nächtlicher Abgleich zwischen CRM, Warenwirtschaft und Newsletter-Tool, mit Report über alles, was nicht zusammenpasst.
- Betriebs-Kleinkram: Ablaufende Domains und Zertifikate prüfen, Backup-Ergebnisse einsammeln, Statusberichte erzeugen.
Die AI-Nodes
Hier wird n8n von einem Integrations-Werkzeug zu etwas anderem. Die AI-Bausteine folgen dem Baukastenprinzip: Ein AI Agent-Node bekommt ein Sprachmodell, optional ein Gedächtnis, und beliebig viele Werkzeuge angehängt — und entscheidet dann selbst, welches er wann benutzt.
Modelle werden als eigene Nodes angebunden: Anthropic (Claude), OpenAI, Google Gemini, Azure OpenAI, Mistral, Groq — und Ollama für lokal laufende Modelle. Letzteres ist der Punkt, an dem die Datenschutzfrage kippt: Ein Modell, das im eigenen Cluster läuft, sieht keine Daten außerhalb des Hauses. Für Klassifizierung und Extraktion reichen kleinere lokale Modelle oft aus; für anspruchsvolles Formulieren und mehrstufiges Schlussfolgern ist ein starkes gehostetes Modell in aller Regel überlegen. Beides im selben Workflow zu kombinieren, ist gängige Praxis: lokal vorsortieren, extern nur das Nötige.
Werkzeuge sind die eigentliche Stärke. An einen Agent lassen sich anhängen: HTTP-Request (beliebige API), Code, Vector Store, Rechner, Datumsfunktionen — und, besonders nützlich, ein Workflow-Tool: ein anderer n8n-Workflow als aufrufbare Funktion. Damit wird jede Automatisierung, die man ohnehin gebaut hat, zu einer Fähigkeit des Agenten.
Gedächtnis hält Konversationen zusammen — als einfacher Puffer oder persistent in Postgres oder Redis.
Vector Stores (Qdrant, PGVector, Pinecone, In-Memory) plus Embedding-Nodes ergeben den RAG-Baukasten: Dokumente einlesen, in Abschnitte teilen, einbetten, ablegen — und im zweiten Workflow beantwortet der Agent Fragen aus genau diesem Bestand.
Daneben stehen fertige Nodes für die Aufgaben, für die man keinen Agenten braucht: Text Classifier (Kategorie zuordnen), Information Extractor (strukturiertes JSON aus Fließtext), Sentiment Analysis, Summarization Chain und Question and Answer Chain.
AI-Anwendungsfälle, die tragen
- Ticket-Triage: Eingehende Support-Mails werden klassifiziert, mit Priorität versehen und der richtigen Gruppe zugewiesen. Der Text Classifier reicht dafür — kein Agent nötig, und das Ergebnis ist nachvollziehbar.
- Wissensdatenbank mit Antwort: Interne Dokumentation, Handbücher und alte Ticketverläufe in einen Vector Store, davor ein Chat-Trigger. Mitarbeiter fragen in normaler Sprache und bekommen eine Antwort mit Quellenangabe statt einer Trefferliste.
- Dokumente auslesen: Rechnungen, Lieferscheine, Bestellungen als PDF hinein, strukturiertes JSON heraus — Belegnummer, Betrag, Datum, Positionen. Der Information Extractor mit definiertem Schema erledigt, wofür früher ein OCR-Projekt aufgesetzt wurde.
- Antwortentwürfe: Auf Standardanfragen erzeugt der Workflow einen Antwortentwurf samt passender Anlagen und legt ihn zur Freigabe vor. Bewusst als Entwurf: Der Mensch bleibt im Ablauf, und genau das macht den Einsatz im Kundenkontakt vertretbar.
- Berichte aus verstreuten Quellen: Monatszahlen aus mehreren Systemen einsammeln, zusammenfassen lassen, als lesbaren Bericht verschicken — inklusive Hinweis auf die Ausreißer.
- Website-Chat mit Anbindung: Ein Chat-Agent, der nicht nur die Website kennt, sondern über Workflow-Tools Termine prüfen oder Bestellstatus abfragen kann.
Ein Rat aus der Praxis: Der AI Agent ist der eindrucksvollste, aber nicht der beste Einstieg. Wo ein Classifier oder Extractor genügt, ist das Ergebnis vorhersagbarer, billiger und leichter zu debuggen. Ein Agent lohnt sich, wenn der Weg zur Lösung im Voraus nicht feststeht.
Fazit
n8n schließt die Lücke zwischen Handarbeit und Individualentwicklung — und mit den AI-Nodes reicht es inzwischen in Bereiche, die vorher ein eigenes Projekt bedeutet hätten. Der Einstieg kostet einen Nachmittag: Compose-Datei, PostgreSQL, Reverse Proxy. Im Cluster steht mit dem Community-Chart in vergleichbarer Zeit ein Setup, das über Worker mitwächst.
Die zwei Dinge, die man von Anfang an richtig machen sollte, sind unspektakulär: PostgreSQL statt SQLite, und den Encryption Key sicher verwahren.
Wir bauen Automatisierungen mit n8n und betreiben die Instanzen dazu — vom ersten Workflow bis zur AI-Anbindung im eigenen Cluster. Sprechen Sie uns an.
Timo Bergen
Gründer & Geschäftsführer
