Was als Open-Source-Automatisierungstool zählt (und was nicht)
Ein Open-Source-Automatisierungstool ist eine Engine, die Flows orchestriert — sie triggert, verbindet Apps, bewegt Daten, entscheidet zwischen Schritten — und deren Code du auf deiner eigenen Infrastruktur statt in der Cloud eines Dritten betreiben kannst. Der Unterschied zu Zapier oder Make ist nicht, was sie tun, sondern wo die Engine lebt und wer die Daten kontrolliert: bei einem geschlossenen SaaS auf deren Servern; bei einem Open-Source-Tool dort, wo du sagst.
Eine Namensverwechslung lohnt sich aufzulösen. „Open-Source-KI" meint meist die Sprachmodelle, die du selbst hosten kannst (Llama, Mistral und Co.), und das ist eine andere Entscheidung — offenes Modell vs. geschlossene API. Hier geht es um Orchestrierung: das Tool, das den Flow ausführt und das Modell aufruft, welches auch immer. Zwei getrennte Schichten, nach unterschiedlichen Kriterien gewählt.
Die drei, die zählen: n8n, Activepieces und Windmill
Die Open-Source-Landschaft ist breit, aber für KI-Automatisierung im Unternehmen dreht sich das echte Gespräch um drei. Alle drei lassen sich selbst hosten; sie unterscheiden sich in Lizenz, Ausrichtung und Zielgruppe.
| Tool | Lizenz | Ausrichtung | Für wen es passt |
|---|---|---|---|
| n8n | Sustainable Use License (Fair-Code) | Visueller Node-Editor + Code bei Bedarf | Gemischte Teams; die größte Community und die meisten Integrationen |
| Activepieces | MIT (die freizügigste) | Einfaches visuelles No-Code | Weniger technische Teams, die volle Lizenzfreiheit wollen |
| Windmill | AGPLv3 | Code-first (TypeScript, Python, Go, Bash, SQL) mit auto-generierten UIs | Engineering-Teams, die internes Tooling als Code wollen |
Die Lizenz ist keine Juristen-Fußnote: sie ändert, was du tun darfst. n8ns Lizenz ist für den internen Gebrauch offen, verbietet aber den Weiterverkauf als Managed Service an Dritte. Activepieces unter MIT bindet dich an fast nichts. Windmill unter AGPLv3 verlangt die Veröffentlichung deiner Änderungen nur, wenn du die Software verteilst — nicht bei interner Nutzung. Für 90 % der Unternehmen, die es für den eigenen Betrieb hosten, verhalten sich alle drei wie echtes Open Source.
Wann sich Self-Hosting lohnt (und wann nicht)
Self-Hosting ist weder kostenlos noch per se besser. Es lohnt sich, wenn einer dieser Drücke real ist — und nicht, wenn keiner es ist.
Es lohnt sich, wenn:
- Daten das Haus nicht verlassen dürfen. Regulierte Branche, sensible Informationen oder eine DSGVO-Vorgabe, dass Daten in deinem Perimeter bleiben. Der Grund Nummer eins und der schwerste.
- Das Volumen den Preis sprengt. SaaS rechnet pro Vorgang oder pro Aufgabe ab; ab einem gewissen Volumen wächst der Preis pro Ausführung eines Cloud-Plans schneller als der deines eigenen Servers.
- Du eigene Logik oder Code brauchst. Wenn der Flow etwas verlangt, das No-Code nicht abdeckt, ist Code in jedem Schritt kein Luxus mehr.
- Du Lock-in vermeiden willst. Die Engine zu kontrollieren heißt, dass eine Preis- oder Konditionsänderung des Anbieters dich nicht an die Wand drückt.
Es lohnt sich nicht, wenn:
- Du nur ein paar Apps verbindest und der Cloud-Plan passt: Wechseln kostet mehr, als es spart.
- Du niemanden hast, der die Infrastruktur wartet (siehe die realen Kosten unten).
- Dein Engpass nicht die Ausführung ist, sondern das Urteil: freien Text lesen, Absicht verstehen, über Mehrdeutiges entscheiden. Das behebt kein Tool-Wechsel; das ist eine KI-Schicht obendrauf.
Die realen Kosten des Self-Hostings, jenseits der Lizenz
„0 € Lizenz" ist wahr und irreführend zugleich. Die Kosten stecken nicht in der Lizenz; sie stecken im Betrieb des Systems. Das taucht wirklich auf der Rechnung auf:
- Server und Hosting: die Maschine, auf der es läuft, ihre Bandbreite und ihr Speicher.
- Backups und Hochverfügbarkeit: ein kritischer Flow, der ohne Kopie ausfällt, ist ein Vorfall, keine Automatisierung.
- Updates und Sicherheitspatches: jede Version bringt Korrekturen, die anzuwenden sind; eine offene, ungepatchte Engine ist eine offene Tür.
- Monitoring und Logs: ohne Observability weißt du nicht, dass der Flow versagt hat, bis sich jemand beschwert.
- Die Person, die es wartet: die dominierende Kostenstelle. Nicht die Software, sondern die technische Zeit, es gesund zu halten.
Self-Hosting und DSGVO: Datensouveränität, kein Häkchen
Das Tool selbst zu hosten hält Engine und Datenbank in deinem Perimeter. Ein guter Ausgangspunkt für die DSGVO, aber damit ist das Thema nicht erledigt. Datensouveränität entscheidet die gesamte Kette des Flows, nicht das Dashboard-Etikett.
Der übliche blinde Fleck: die Engine ist zu Hause, aber der Flow ruft eine LLM-API in den USA auf, feuert einen Webhook an einen Dritten oder speichert einen Anhang in einem Cloud-Speicher. Bei jedem dieser Sprünge verlassen die Daten deinen Perimeter genauso wie bei einem SaaS. Den Orchestrator selbst zu hosten und sensible Inhalte an ein unkontrolliertes externes Modell zu schicken, ist halbe Souveränität. Du musst schauen, wo jeder Sprung lebt — und genau hier glänzt selbst gehostetes n8n gegenüber den Cloud-Alternativen, gerade weil du die ganze Kette unter deinem Dach halten kannst.
Wie du in einem Satz wählst
Wenig technisches Team und volle Lizenzfreiheit → Activepieces (MIT). Gemischtes Team, das Community und Integrationen schätzt → n8n (Fair-Code). Engineering-Team, das alles als Code und in Git versioniert will → Windmill (AGPLv3). Und eine Warnung, die Projekte rettet: wenn dein echtes Problem ist, dass der Flow Urteilsvermögen braucht, löst es keiner der drei allein — das ist eine KI-Schicht obendrauf, kein Tool-Wechsel.