Zurück zur Academy

n8n: Workflow-Automatisierung verstehen

Architektur-Konzepte | Deployment-Optionen | Self-Hosting vs Cloud | Technische Fundierung

Auf dieser Seite:

Workflow-Automatisierung: Architektur-Grundlagen

Was ist ein Workflow-Orchestrator und wie funktioniert er technisch?

Ein Workflow-Orchestrator ist ein System, das die Ausführung von sequenziellen oder parallelen Tasks zwischen verschiedenen Services koordiniert. Technisch gesehen: Event-driven Execution Engine mit visueller Programmieroberfläche.

Kernkonzepte

1. Nodes (Execution Units)

Atomare Funktionseinheiten. Jede Node kapselt eine Operation (API-Call, Datenverarbeitung, Conditional Logic).

Technisch: Node = Function mit Input/Output Schema. Input: JSON-Objekt. Output: JSON-Objekt oder Array. Execution Context wird durch Workflow-Engine verwaltet.
2. Workflow Graph (DAG)

Workflows sind Directed Acyclic Graphs (DAG). Nodes sind Vertices, Connections sind Edges. Ausführung erfolgt topologisch sortiert.

Execution Order: Topological Sort des Graph. Parallele Branches werden concurrent ausgeführt (Thread/Process Pool, je nach Implementation).
3. Trigger-Mechanismen

Workflows starten durch Events: Webhook (Push), Polling (Pull), Cron (Schedule), Manual Trigger.

Webhook: Event-driven, Real-time. HTTP POST → Workflow Execution
Polling: Periodic Check (z.B. alle 5 Min neuer Email). Resource-intensive.
Cron: Time-based Schedule (z.B. täglich 8 Uhr Report generieren)
4. State Management

Execution State muss persistiert werden (DB), um Retry, Error Handling, Debugging zu ermöglichen.

Persistence: SQLite/PostgreSQL für Execution Logs. Jeder Workflow-Run hat Execution ID, Timestamp, Input/Output Data, Error State.

n8n: Technische Charakteristika

Architektur
• Node.js (TypeScript) Monolith
• SQLite (default) oder PostgreSQL für State
• Redis (optional) für Queue/Cluster Mode
• Express.js für HTTP Server (Webhook Endpoint)
Extensibility
• Custom Nodes: NPM Packages (TypeScript)
• Code Nodes: JavaScript/Python inline execution
• Webhook Nodes: Custom HTTP Endpoints
• Native Git Integration (Workflows als JSON in Git)

Plattform-Kategorien verstehen

Architekturelle Unterschiede zwischen Cloud-SaaS, Hybrid und Self-Hosted

Die fundamentale Entscheidung

Bei Workflow-Automatisierung gibt es zwei grundsätzlich verschiedene Architektur-Ansätze, die unterschiedliche Trade-offs haben:

Cloud-SaaS (Zapier, Make)
Architektur: Mandantenfähige Multi-Tenant-Plattform. Ihre Workflows laufen auf geteilter Infrastruktur.
Vorteil: Zero Setup, sofort nutzbar
Nachteil: Vendor Lock-In, keine volle Datenkontrolle
Self-Hosted (n8n)
Architektur: Dedicated Instance. Sie betreiben eigene n8n-Installation auf Ihrer Infrastruktur.
Vorteil: Volle Kontrolle, kein Vendor Lock-In, DSGVO-konform
Nachteil: Wartungsaufwand, Infrastruktur-Know-how nötig
Kriterium
n8nSelf-Hosted
Cloud-SaaS Plattformen
Pricing-Modell
Execution-basiert
1 Workflow-Run = 1 Execution (egal wie viele Items)
Task/Operation-basiert
Jedes Item × Steps = Tasks abgerechnet
Deployment-Optionen
Unbegrenzt
VPS, On-Premise, Docker, Kubernetes, Cloud VM
Nur Cloud
Vendor-gehostete Plattform
Data Residency
Volle Kontrolle
Sie bestimmen Server-Standort (DE, EU, On-Prem)
Provider-abhängig
Oft USA-Server, Schrems II problematisch
Code/Customization
Unbegrenzt
Custom Nodes (NPM), JS/Python Inline Code
Limitiert
Sandboxed Code Execution (wenn überhaupt)
Version Control (Git) Native Git Integration Meist nicht verfügbar
Lokale AI-Modelle Möglich (Ollama, LocalAI) Nicht möglich
Operational Overhead
Mittel-Hoch
Updates, Backups, Monitoring, Security-Patches
Minimal
Vendor managed
Vendor Lock-In
Kein
Fair-Code Lizenz, Workflows exportierbar
Hoch
Proprietäres Format, Migration schwierig

Lizenzmodelle verstehen

Fair-Code (n8n)

Source-Available Lizenz. Code ist einsehbar, selbst hostbar, aber nicht vollständig Open Source (Apache Sustainable License).

✓ Sie dürfen: Selbst hosten (unbegrenzt), Code anpassen, für Kunden nutzen, Community-Nodes entwickeln
✗ Nicht erlaubt: Als konkurrierende SaaS anbieten, kommerzielle Weiterverbreitung ohne Lizenz
Proprietary (Cloud-SaaS)

Closed Source. Code ist nicht einsehbar, keine Self-Hosting-Option.

Vorteil: Zero Setup, Vendor managed, schneller Start
Nachteil: Vendor Lock-In, Preis-/Policy-Änderungen, keine Kontrolle über Infrastruktur

Pricing-Modelle: Architekturelle Implikationen

Task-basiert vs Execution-basiert – warum das Kostenstrukturen fundamental verändert

Der fundamentale Unterschied

Task-basiertes Pricing (Cloud-SaaS)

Abrechnungseinheit: Task
1 Task = 1 Action auf 1 Item. Multi-Step Workflow mit 100 Items × 5 Steps = 500 Tasks.

Beispiel: CSV-Import mit 1.000 Zeilen
• Step 1: CSV Read (1.000 Tasks)
• Step 2: Validate (1.000 Tasks)
• Step 3: Transform (1.000 Tasks)
• Step 4: DB Insert (1.000 Tasks)
→ Total: 4.000 Tasks abgerechnet

Execution-basiertes Pricing (n8n)

Abrechnungseinheit: Workflow-Execution
1 Execution = 1 kompletter Workflow-Run, unabhängig von Item-Count oder Step-Count.

Beispiel: CSV-Import mit 1.000 Zeilen
• Workflow startet (Trigger)
• Alle 4 Steps werden ausgeführt
• 1.000 Items werden verarbeitet
• Workflow beendet
→ Total: 1 Execution abgerechnet

Kosten-Skalierung: Vergleich

Bei datenintensiven Workflows (hohe Item-Counts) ist Execution-basiertes Pricing exponentiell günstiger. Bei einfachen 1-Item-Workflows ist der Unterschied marginal.

Workflow-TypItems/RunStepsTasks (Cloud-SaaS)Executions (n8n)Faktor
Simple Notification133 Tasks1 Execution3x
Bulk Email Campaign50042.000 Tasks1 Execution2.000x
Data Migration10.000550.000 Tasks1 Execution50.000x

Versteckte Kosten bei Task-basiertem Pricing

  • Polling-basierte Triggers: Viele Cloud-SaaS-Plattformen nutzen Polling (alle 5-15 Min). Jedes Poll-Event = Task abgerechnet, auch wenn keine neuen Daten vorhanden sind.
  • Multi-Step Multiplication: 5-Step Workflow × 1.000 Runs = 5.000 Tasks. Jeder zusätzliche Step erhöht Kosten linear.
  • Premium Connectors: Zusätzliche Kosten für Enterprise-Apps (Salesforce, SAP, etc.), unabhängig von Task-Count.

Deployment-Architekturen

Von Managed Cloud bis Air-Gapped On-Premise – technische Trade-offs verstehen

Self-Hosting bedeutet nicht automatisch "auf eigenem Server". Es gibt verschiedene Deployment-Modelle mit unterschiedlichen Trade-offs bezüglich Kontrolle, Wartung und Compliance.

Managed VPS

Cloud-VM mit Management-Service

Architektur
Dedizierte VM bei Cloud-Provider (Hetzner, OVH, etc.). n8n läuft in Docker/systemd. Provider managed Backups, Updates durch Service.
Trade-offs
DSGVO-konform (EU-Server, dedizierte VM)
Wartung & Patches durch Service
Höhere Kosten als DIY VPS

On-Premise

Physischer Server, lokales Netzwerk

Architektur
Hardware in Ihrem Rechenzentrum/Büro. Raspberry Pi, NUC, oder Server-Hardware. Network-isolated oder VPN-only.
Trade-offs
Maximale Datenkontrolle (Air-Gapped möglich)
Lokale AI-Modelle (Ollama) ohne Cloud
Hardware-Wartung, Uptime-Garantie, Backups selbst managen

Vendor-Managed Cloud

SaaS by n8n (oder andere)

Architektur
Multi-Tenant SaaS. n8n-Team managed alle Aspekte (Updates, Scaling, Backups). Execution auf geteilter Infrastruktur.
Trade-offs
Zero Setup, sofort nutzbar
Auto-Updates, professionelles Monitoring
Vendor-Infrastruktur (oft USA-Server, DSGVO-kritisch)

DIY VPS

Selbst-Administration

Architektur
Bare-Metal VPS (Hetzner, OVH). Sie installieren & konfigurieren n8n selbst (Docker Compose, systemd). Volle SSH-Kontrolle.
Trade-offs
Niedrigste Kosten (€5-20/Monat VPS)
Volle Kontrolle über Konfiguration
Selbst-Administration: Updates, Security-Patches, Backups, Monitoring

Deployment-Entscheidung: Kriterien

Compliance-Anforderungen
DSGVO-kritisch: Managed VPS (EU) oder On-Premise
Non-EU Daten: Vendor Cloud möglich
Highly Sensitive: On-Premise (Air-Gapped)
Operational Capacity
Kein Tech-Team: Managed VPS oder Vendor Cloud
Linux-Admin vorhanden: DIY VPS möglich
DevOps-Team: Kubernetes/Multi-Region Setup
Budget & Scale
Budget-optimiert: DIY VPS (€5-20/Monat)
Standard: Managed VPS (wartungsfrei)
High-Scale: Kubernetes Cluster (Redis Queue, Multi-Worker)

AI-Integration: Architekturelle Unterschiede

Warum Self-Hosted Plattformen bei AI-Workflows überlegen sind

AI-Workflows haben fundamentally different Anforderungen als klassische Integrationen: Lange Laufzeiten, hohe Token-Counts, lokale Modelle, RAG-Pipelines. Hier zeigen sich die architekturellen Vorteile von Self-Hosted Lösungen.

AI-Workflow Architektur

Self-Hosted (n8n)
  • LangChain Integration: Native Nodes für Vector Stores, Embeddings, Chains, Agents
  • Lokale LLMs: Ollama, LocalAI, llama.cpp via localhost
  • Custom Code: Python Nodes für komplexe AI-Pipelines
  • Keine Timeout-Limits: Lange RAG-Pipelines (>5 Min) kein Problem
Cloud-SaaS
  • Nur Cloud-APIs: OpenAI, Anthropic, etc. Lokale Modelle nicht möglich
  • Execution Timeouts: Meist 30-120 Sek Limit pro Step
  • Limitierte Customization: Nur vorgefertigte Integrationen
  • Data Residency: Prompts & Responses über Vendor-Server

Praxis-Beispiel: RAG-Pipeline

Eine typische RAG-Pipeline (Retrieval-Augmented Generation) erfordert mehrere Steps: Document Loading → Chunking → Embedding → Vector Store → Retrieval → LLM Generation.

Mit Self-Hosted (n8n):
1. Document Loader Node (PDFs, Docs)
2. Text Splitter Node (Chunking Strategy: Recursive, Token-based)
3. Embeddings Node (OpenAI, Cohere, oder lokales Modell)
4. Vector Store Node (Pinecone, Qdrant, Chroma)
5. Retriever Node (Similarity Search)
6. LLM Node (Claude, GPT, oder Ollama lokal)
→ Alle Steps in einem Workflow, keine Timeout-Probleme
Mit Cloud-SaaS:
1. Document Loader: ✓ (wenn native Integration)
2. Text Splitter: ✗ (Custom Code limitiert)
3. Embeddings: ✓ (nur Cloud-APIs)
4. Vector Store: ✗ (meist keine native Integration)
5. Retriever: ✗ (Custom Logic schwierig)
6. LLM: ✓ (nur Cloud-APIs)
→ Pipeline unvollständig, Workarounds nötig

Model Gateway Pattern: Flexibilität durch Abstraktion

Ein Model Gateway (z.B. OpenRouter) ist ein Unified API Endpoint für hunderte AI-Modelle. Vorteil: Modell-Switching ohne Code-Änderung.

Warum Model Gateway?
  • Vendor Independence: Wechseln Sie Provider ohne Workflow-Änderung
  • Cost Optimization: Task-spezifisches Modell (Cheap für Simple, Premium für Complex)
  • Fallback: Automatischer Failover wenn Provider down
Praxis-Pattern
Cheap Model für Bulk: Classification, Tagging, Simple Summarization
Standard Model für Production: Customer Support, Content Generation
Premium Model für Complex: Code Analysis, Deep Reasoning, Multi-step Chains
Integration in n8n:
Native OpenRouter Node (oder OpenAI-kompatible API). Model-Switching via Parameter: model: "provider/model-name". Ein Workflow kann verschiedene Modelle für verschiedene Steps nutzen.

Entscheidungskriterien: Systematisch evaluieren

Framework für die Auswahl der richtigen Workflow-Plattform

5-Dimensionen-Framework

1
Compliance & Data Residency
Fragen: Verarbeiten Sie EU-Personendaten? DSGVO-kritisch? Branchen-Compliance (HIPAA, SOC2)?
→ Self-Hosted (EU-VPS/On-Prem) wenn DSGVO kritisch
→ Cloud-SaaS wenn nur Non-EU Daten oder Marketing-Only
2
Workflow-Charakteristik
Fragen: Datenintensive Workflows (>100 Items/Run)? AI-Heavy? Custom Logic nötig?
→ Self-Hosted wenn datenintensiv (Execution-Pricing spart massiv)
→ Self-Hosted wenn AI-Workflows mit RAG/lokalen Modellen
→ Cloud-SaaS wenn Simple 1-Item-Workflows
3
Technical Capacity
Fragen: DevOps-Team vorhanden? Linux-Admin-Kenntnisse? Wartungsbudget?
→ Managed VPS wenn kein Tech-Team (Setup + Wartung durch Service)
→ DIY VPS/On-Prem wenn DevOps vorhanden (niedrigste Kosten)
→ Cloud-SaaS wenn zero maintenance gewünscht
4
Cost Structure
Fragen: Vorhersehbares Volumen? Budget-Constraints? ROI-Optimierung kritisch?
→ Self-Hosted wenn hohes Volumen (60-95% Ersparnis vs Cloud-SaaS)
→ Cloud-SaaS wenn niedriges, unvorhersehbares Volumen (Pay-as-you-go)
5
Vendor Lock-In Tolerance
Fragen: Wie kritisch ist Platform-Independence? Exit-Strategie wichtig?
→ Self-Hosted (n8n) wenn Lock-In unakzeptabel (Fair-Code, Workflows exportierbar)
→ Cloud-SaaS wenn Lock-In akzeptabel (Convenience > Independence)

Quick Decision Matrix

Ihr ProfilEmpfohlene LösungBegründung
EU-KMU, DSGVO-kritisch
Personendaten, kein Tech-Team
Managed VPS (EU)DSGVO-konform, wartungsfrei, dedizierte Infrastruktur
Startup, Budget-optimiert
DevOps vorhanden, hohes Volumen
DIY VPSNiedrigste Kosten, volle Kontrolle, Technical Capacity vorhanden
Non-Tech Business
Simple Workflows, keine EU-Daten
Cloud-SaaSZero Setup, einfachste Bedienung, Compliance nicht kritisch
AI-First Company
RAG, lokale LLMs, Custom Pipelines
Self-Hosted (On-Prem)Ollama-Integration, keine Timeouts, Custom Code unbegrenzt
Enterprise, High-Volume
>1M Executions/Monat, Multi-Region
Kubernetes ClusterHorizontal Scaling, Redis Queue, Multi-Worker Setup

Key Takeaways

Pricing-Modell ist kritischer als Preis. Execution-basiert vs Task-basiert verändert Kostenstrukturen fundamental – besonders bei datenintensiven Workflows.
DSGVO ist nicht optional. Wenn Sie EU-Personendaten verarbeiten, ist Self-Hosting (EU-Server) oder On-Premise der sichere Weg. Cloud-SaaS mit USA-Servern ist Schrems-II-problematisch.
Self-Hosted ≠ DIY. Managed VPS kombiniert Self-Hosting-Vorteile (DSGVO, Kontrolle) mit Cloud-Convenience (wartungsfrei).
AI-Workflows brauchen andere Architektur. Lokale LLMs, lange Laufzeiten, RAG-Pipelines – Cloud-SaaS ist hier limitiert. Self-Hosted mit LangChain-Integration ist überlegen.
Fair-Code schützt Sie vor Vendor Lock-In. n8n's Lizenzmodell erlaubt Self-Hosting unbegrenzt, Workflows sind JSON (exportierbar). Migration ist möglich.

Bereit für Workflow-Automatisierung?

In einem kostenlosen Beratungsgespräch analysieren wir Ihre Use Cases und zeigen Ihnen, welche Architektur für Ihre Anforderungen optimal ist.

Kostenfreies Beratungsgespräch buchen

Oder zurück zur Academy-Übersicht