n8n self-hosted auf AWS: Was ein Enterprise-Setup wirklich braucht

n8n läuft in zehn Minuten per Docker. Genau das ist das Problem. Der schnelle Start lebt auf einer einzelnen VM, mit SQLite, ohne Backup, und ein halbes Jahr später hängen daran die Rechnungsläufe. Wir betreiben n8n für Kunden auf AWS. Hier beschreiben wir, was ein Setup braucht, das IT-Leitung, Datenschutzbeauftragter und Betriebsrat mittragen.

Warum überhaupt selbst hosten

Die Frage kommt in jedem Projekt. Drei Gründe sprechen aus unserer Erfahrung für Self-Hosting:

• DSGVO und Auftragsverarbeitung: Die Daten bleiben in Ihrem AWS-Konto in Frankfurt. Sie brauchen keinen zusätzlichen Auftragsverarbeiter für die Automatisierungsplattform und setzen Löschfristen selbst durch.
• Bankdaten und Zahlungsverkehr: Wer Kontoumsätze, Mahnläufe oder SEPA-Dateien verarbeitet, möchte die Execution-Daten nicht bei einem Drittanbieter liegen haben. Bei einer Prüfung ist "läuft in unserer VPC" eine kurze Antwort.
• Betriebsrat: Workflows berühren oft Mitarbeiterdaten, etwa beim Onboarding oder in der Zeiterfassung. Eine Betriebsvereinbarung ist leichter, wenn Sie Zugriff, Protokollierung und Aufbewahrung selbst kontrollieren.

Das gilt auch beim Einsatz von Claude in den Workflows. Sie entscheiden, welche Felder an das Modell gehen und welche vorher maskiert werden. Dazu kommt: Self-Hosting kennt keine Execution-Limits. Ein nächtlicher Abgleich über viele tausend Datensätze kostet Rechenzeit, nicht Lizenz.

Queue Mode: Ein Prozess reicht nicht

Standardmäßig macht n8n alles in einem Prozess: Oberfläche, Webhooks, Trigger und Ausführungen. Das reicht für Experimente. Sobald ein langer Workflow die Oberfläche blockiert oder ein Neustart laufende Executions abbricht, ist Schluss.

Das Enterprise-Setup nutzt den Queue Mode:

• Ein Main-Prozess bedient Oberfläche und Trigger.
• Eigene Webhook-Prozesse nehmen eingehende Aufrufe an, auch wenn die Worker unter Last stehen.
• Worker führen die Workflows aus. Sie skalieren horizontal, bei uns meist als Container auf ECS Fargate.
• Redis auf ElastiCache verteilt die Jobs.
• Postgres auf RDS speichert Workflows, Credentials und Executions. SQLite hat in Produktion nichts verloren.

Die Kernkonfiguration ist überschaubar:

EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=<elasticache-endpoint>
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=<rds-endpoint>
N8N_ENCRYPTION_KEY=<aus Secrets Manager>
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=336

Die letzten beiden Zeilen werden gern vergessen. Ohne Pruning wächst die Execution-Tabelle, bis RDS langsam wird. Bei Finanzdaten legen Sie die Aufbewahrung mit der Fachabteilung fest, nicht mit dem Default.

Zugriff: SSO und Secrets

Lokale n8n-Benutzer mit Passwort sind bei zehn Beteiligten nicht mehr zu pflegen. Zwei Dinge gehören deshalb ins Setup:

• SSO über SAML oder OIDC, angebunden an Entra ID oder Okta. Verlässt jemand das Unternehmen, erlischt der Zugang zentral. SAML und OIDC gibt es in n8n nur mit Enterprise-Lizenz. Ohne Lizenz setzen wir den Application Load Balancer mit OIDC-Authentifizierung vor die Oberfläche. Webhooks bleiben über einen eigenen Pfad erreichbar.
• Secrets gehören nicht im Klartext in die Task Definition. ECS liest sie direkt aus AWS Secrets Manager. Der wichtigste ist N8N_ENCRYPTION_KEY: Verlieren Sie ihn, sind alle gespeicherten Credentials wertlos. Also ab in den Secrets Manager, ohne automatische Rotation, mit Zugriffsprotokoll über CloudTrail.

Dazu Projekte und Rollen in n8n: Trennen Sie Finance-Workflows von Marketing-Workflows. Wer eine Credential nicht sieht, kann sie auch nicht versehentlich in einem Test-Workflow benutzen.

Backups und Updates ohne Ausfall

Backups bestehen aus zwei Teilen. Erstens automatisierte RDS-Snapshots mit Point-in-Time-Recovery. Zweitens ein nächtlicher Export aller Workflows als JSON in ein versioniertes S3-Bucket, über die n8n-API. Das ist Ihr Audit-Trail: Wer hat wann welchen Workflow geändert. Und testen Sie die Wiederherstellung einmal pro Quartal in einer separaten Umgebung. Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung.

n8n veröffentlicht wöchentlich. Nicht jede Version muss auf Produktion. Unser Vorgehen:

• Versionen pinnen, nie latest.
• Erst Staging, mit einem Smoke-Test der kritischen Workflows.
• Rolling Deployment auf ECS: Neue Worker starten, alte Worker laufen ihre aktuellen Jobs zu Ende und stoppen dann. Dafür muss der Container sauber auf SIGTERM reagieren, n8n unterstützt das.
• Der Main-Prozess führt beim Start Datenbankmigrationen aus. Dabei ist die Oberfläche kurz nicht erreichbar. Webhooks und Worker laufen weiter, und das ist der Punkt, der zählt.

Monitoring in CloudWatch

Ein Workflow, der still stirbt, fällt erst auf, wenn die Buchhaltung nachfragt. Deshalb:

• Container-Logs nach CloudWatch Logs, als JSON mit N8N_LOG_OUTPUT=json, damit Sie nach Workflow-ID filtern können.
• Metriken über den /metrics-Endpunkt im Prometheus-Format, eingesammelt vom CloudWatch Agent. Wichtig sind Queue-Länge, Fehlerrate und Dauer.
• Alarme auf wartende Jobs über Schwellwert, Worker-Neustarts, freien RDS-Speicher und fehlgeschlagene Executions pro Stunde.
• Health Check des Load Balancers auf /healthz.

Wenn Workflows Claude aufrufen, etwa für die Extraktion aus PDF-Rechnungen, loggen Sie Token-Verbrauch und Antwortzeit mit. Das sind Kosten und Latenz, die Sie sehen wollen. Die Alarme gehen nach Slack oder Teams, an eine Person mit Verantwortung. Wie Sie Fehler in den Workflows selbst behandeln, beschreiben wir im nächsten Artikel.

Wann n8n Cloud reicht

Nicht jedes Unternehmen braucht das alles. n8n Cloud ist die richtige Wahl, wenn:

• keine Bank-, Gesundheits- oder Mitarbeiterdaten durch die Workflows laufen,
• der Auftragsverarbeitungsvertrag mit n8n Ihrem Datenschutzbeauftragten genügt,
• Sie kein Team haben, das AWS betreibt, und auch keines aufbauen wollen,
• Ihre Last unter den Execution-Limits des Plans bleibt.

Dann sparen Sie sich die Infrastruktur und bekommen Updates frei Haus. Unsere ehrliche Empfehlung: Starten Sie mit Cloud, wenn die Daten es erlauben, und ziehen Sie später um. Workflows sind JSON, der Umzug ist machbar.

Fazit

Ein produktives n8n-Setup auf AWS ist kein Hexenwerk, aber auch kein Docker-Einzeiler. Queue Mode, Postgres, SSO, Secrets Manager, getestete Backups und Alarme sind das Minimum. Wir haben das mehrfach aufgebaut und kennen die Stolpersteine. Wenn Sie wissen möchten, ob Self-Hosting oder Cloud zu Ihrem Fall passt, buchen Sie ein kostenloses 30-minütiges Kennenlerngespräch.