Windmill: Script-first Workflows mit TypeScript, Python, Go und Bash unter AGPLv3

Was ist Windmill?

Windmill ist eine Open-Source-Plattform für Script-first-Workflow-Automation, gegründet 2022 in Paris von Ruben Fiszel. Die Position im Markt ist klar: Windmill behandelt Code (TypeScript, Python, Go, Bash) als first-class und legt um diesen Code-Kern die typischen Workflow-Plattform-Features – Scheduling, UI-Generierung, Secrets-Management, Versionierung, Approval-Flows. Der Vergleich mit Zapier oder n8n ist eher irreführend; Windmill ist näher an einer „Self-Hosted-Vercel-für-Backend-Scripts" als an einem visuellen Workflow-Tool.

Stand Mai 2026 unterstützt Windmill vier Sprachen first-class: TypeScript (Deno- und Bun-Runtime), Python 3.11+, Go 1.21+ und Bash. Zusätzlich gibt es eine eingebaute SQL-Editor (Postgres, MySQL, MS-SQL, BigQuery, Snowflake) und PowerShell-Support. Jedes Script ist eine Funktion mit typisierten Parametern; aus diesen Parametern generiert Windmill automatisch ein Web-UI für manuelle Trigger.

Flows kombinieren mehrere Scripts in einem gerichteten Graphen. Branching, Iteration, Suspends (Wait-for-Event), Approval-Steps und Sub-Flows sind alle nativ. Trigger-Quellen: Cron, Webhook, manuelle Ausführung, externe Events über Polling.

Kommerziell ist Windmill dual-lizenziert: AGPLv3 für den Core (Self-Hosting mit Compliance-Auflagen unter AGPL) und kommerzielle Lizenz für Enterprise-Features (SSO, Audit-Log, Advanced-RBAC). Cloud-Tier startet bei USD 0/Monat (Free, 1.000 Executions, 5 Mitglieder), Team ab USD 30/Monat für 50.000 Executions, Enterprise auf Anfrage. Self-Host ist die üblichere Wahl – die AGPL-Compliance ist für interne Nutzung kein Problem, nur für Wiederverkauf in eigenen Produkten muss die Copyleft-Pflicht beachtet werden.

Die Self-Host-Architektur ist eigenständig: Docker-Compose mit Postgres als DB, Windmill-Server, Windmill-Worker (skalierbar) und optional einem Caddy-Container für den Reverse-Proxy. Ressourcen-Verbrauch ist höher als bei Activepieces, da jeder Script-Run einen Container-Spawn auslost – eine 4-vCPU-Maschine deckt typisch 50-100k Executions/Monat.

Warum es wichtig ist

Windmill löst ein konkretes Problem für Engineering-Teams: die Disziplin von Git-versioniertem Code mit dem Komfort einer Workflow-Plattform kombinieren. Wer in einem KMU oder Treuhand-Setup eine Engineering-Resource hat (interner Entwickler, externer Dienstleister), kann mit Windmill Workflows als TypeScript- oder Python-Code im Git-Repo halten – Code-Review, Tests, CI/CD wie bei normaler Software.

Für eine CH-Treuhand mit Engineering-Capacity sind drei Hebel konkret. Erstens: ELT-Pipelines für Buchhaltung. Daten aus Bexio, Abacus oder Lexoffice ziehen, transformieren, in ein Data-Warehouse (Postgres oder Snowflake) laden – solche Pipelines lassen sich in Windmill als Python-Scripts schreiben, mit Cron geplant, mit Slack-Alert bei Fehler. Funktional ähnlich wie Airflow, aber mit besserer UI und einfacherem Onboarding.

Zweitens: Approval-Flows mit Mensch-im-Kreis. Windmill hat einen nativen „Approval-Step": ein Flow pausiert, sendet eine Nachricht an einen User, wartet auf Bestätigung (per E-Mail-Link oder UI-Klick), und fährt dann weiter. Für Mandanten-Onboarding mit GwG-Prüfung oder für Rechnungs-Freigaben über einer Limite ist das die richtige Architektur – KI schlägt vor, Mensch entscheidet, dann fliesst die Operation ins ERP.

Drittens: Custom-Logik mit voller Sprach-Freiheit. Wer einen spezifischen Algorithmus implementieren muss (z.B. eine MWST-Plausibilitätsprüfung mit Pandas-DataFrames, eine Lead-Scoring-Logik mit scikit-learn, eine Abrechnungslogik mit numpy), kann das direkt in Windmill-Python-Scripts tun. Keine Code-Action-Limits wie bei Zapier, keine Whitelist wie bei Activepieces.

Die AGPL-Lizenz ist für interne Nutzung kein Hindernis. Wer Windmill in einem SaaS-Produkt embedden will, muss entweder die Copyleft-Pflicht erfüllen (eigener Code unter AGPL) oder die kommerzielle Lizenz buchen. Für Treuhand-interne Nutzung greift das nicht.

Wie es funktioniert

Ein Windmill-Workspace organisiert die Inhalte in vier Kategorien: Scripts (einzelne Funktionen in einer Sprache), Flows (Graphen aus Scripts), Apps (custom-UIs aus den Script-Outputs) und Resources (typisierte Secrets für DB-Connections, API-Keys, Cloud-Credentials). Jede Resource hat ein Schema, gegen das die Inputs validiert werden.

Ein Script wird über ein Web-IDE editiert – Monaco-Editor mit Auto-Completion, integrierte Test-Ausführung, Versions-History. Die Funktion akzeptiert typisierte Parameter; Windmill generiert daraus automatisch eine UI-Form für manuelle Trigger. Speichern erzeugt eine neue Version, jede Version ist diffbar gegen vorherige. Optional kann ein Workspace mit Git synchronisiert werden – Pull/Push gegen ein eigenes Repo, damit Code-Review und CI integriert werden.

Ein Flow ist ein Graph aus Steps. Jeder Step ist entweder ein Script-Call, ein Branch (Wenn-Dann), ein For-Loop, ein While-Loop, ein Approval-Step (wartet auf Bestätigung), ein Suspend-Step (wartet auf externes Event), oder ein Subflow (Aufruf eines anderen Flows). Daten zwischen Steps fliessen über explizite Variablen-Bindings – Windmill ist strikt typed, im Gegensatz zur losen Verbindung bei n8n.

Ein typischer ELT-Flow für Buchhaltung: Cron-Trigger (täglich 02:00) -> Python-Script „bexio_export" (Bexio-API ziehen, in DataFrame) -> Python-Script „transform" (Bereinigung, Aggregationen) -> SQL-Step „load_warehouse" (in Postgres-Data-Warehouse INSERT) -> Slack-Step (Erfolg-/Fehler-Notification). Bei Fehler in Step 2 oder 3 wird Step 4 nicht ausgeführt, ein Error-Handler-Flow wird stattdessen getriggert.

Die Apps-Funktionalität ist eine spezielle Stärke: aus den Outputs eines Scripts lässt sich eine custom-UI bauen (Forms, Tabellen, Charts, Buttons). Damit lassen sich interne Tools sehr schnell erstellen – z.B. ein „Mandanten-Lookup-Tool" als App, das einen Python-Script aufruft und das Ergebnis als Tabelle anzeigt. Diese App kann mit Berechtigungen ausgestattet und einzelnen Mitarbeitern freigegeben werden.

Die Worker-Architektur skaliert horizontal: jeder Worker zieht Jobs aus der Queue, führt das Script in einem isolierten Container aus, schreibt das Ergebnis zurück. Bei 4 Workern parallel auf einer 8-vCPU-Maschine läuft Windmill bei mehreren hundert Executions pro Minute stabil.

Windmill Self-Hosted in 5 Schritten

1. 01Docker-Compose-Stack vorbereiten: Windmill-Server, Windmill-Worker (2-4 Container), Postgres als DB, Caddy als Reverse-Proxy mit TLS.
2. 02Workspace anlegen: Admin-User erstellen, erste Resources definieren (Postgres-Connection, OpenAI-API-Key, SMTP-Credentials).
3. 03Erste Scripts schreiben: Hello-World-Funktion in TypeScript oder Python, Auto-UI testen, Permissions setzen.
4. 04Flow zusammenbauen: 3-4 Scripts in einen Graphen verbinden, Error-Handler-Branch für Failure-Fall, Approval-Step bei kritischen Operationen.
5. 05Git-Sync aktivieren: Workspace mit eigenem Git-Repo verbinden, Pull/Push für Code-Review-Workflow, CI-Integration optional.

Wann Windmill einsetzen

Windmill ist die richtige Wahl, wenn (a) das Team Code-Knowhow hat (mindestens eine Person mit TypeScript- oder Python-Erfahrung), (b) Workflows als Code im Git-Repo gehalten werden sollen, (c) Approval-Flows oder Mensch-im-Kreis-Logik gebraucht werden und (d) Self-Hosting unter EU-Recht wichtig ist.

Konkrete Fälle: ELT-Pipelines für Buchhaltungs-Daten (Bexio/Abacus/Lexoffice -> Data-Warehouse), Custom-Backoffice-Tools (interne Apps für Mitarbeitende), Approval-Workflows (Rechnungsfreigaben, Mandanten-Onboarding mit GwG-Prüfung), Datenverarbeitung mit Pandas/Pydantic/Pillow, AI-Pipelines mit voller SDK-Freiheit (eigene LangChain-Logik, custom Embedding-Strategien), interne Reporting-Generatoren (PDF-Reports aus Python mit ReportLab).

Für Engineering-Teams in mittleren KMU oder Treuhand-Büro ab 20 Mitarbeitenden ist Windmill oft die produktivere Wahl als n8n: weniger UI-Overhead, mehr Code-Disziplin, bessere Integration mit bestehender Software-Entwicklung. Wer schon Git, CI/CD und Code-Review im Workflow hat, fügt Windmill leichter ein als ein visuelles Tool.

Für Standard-RAG- und Agent-Workflows ist Windmill mindestens so gut wie n8n – die volle Python-Freiheit erlaubt komplexe LangChain-Setups, custom Retriever, hybrid Embedding-Strategien. Vector-Store-Anbindung (Qdrant, Pinecone, pgvector) als reguläre Python-Imports.

Für Self-Hosting in EU/CH ist Windmill eine technisch saubere Wahl: Docker-Compose-Stack, Postgres als DB, klare Reverse-Proxy-Anbindung. Die AGPL-Compliance für interne Nutzung kein Thema.

Wann NICHT

Windmill ist die falsche Wahl, wenn das Team kein Code-Knowhow hat. Im Gegensatz zu n8n oder Activepieces gibt es keinen produktiven Pfad für No-Code-User – die UI hilft beim Editing, aber jeder Schritt verlangt mindestens grundlegende Programmier-Konzepte. Für Marketing- oder Sales-Teams ohne Engineering-Begleitung ist Make oder Zapier die richtige Wahl.

Ungeeignet ist Windmill bei reinen No-Code-SaaS-Integrationen. Wer „Slack-Nachricht bei neuem HubSpot-Deal" baut, hat in Zapier oder Make 90% des Setups in 5 Minuten – in Windmill muss man die HubSpot- und Slack-API selbst gegen das HTTP-Modul aufrufen oder ein kleines Script schreiben. Für einfache 1-zu-1-Verbindungen ist das überkompliziert.

Nicht passend ist Windmill bei sehr hoher Stückzahl mit Real-Time-Anforderungen (Millionen Events/Stunde). Die Worker-Architektur skaliert in den Bereich Tausende Executions/Minute, aber für echtes Streaming sind Kafka, Apache Flink oder dedizierte Streaming-Plattformen die richtige Wahl.

Für Embedded-Use-Cases in eigenem SaaS-Produkt ist die AGPL eine Hürde: entweder eigener Code wird unter AGPL gestellt (was selten gewünscht ist) oder die kommerzielle Lizenz wird gebucht. Wer Workflow-Automation in ein eigenes Produkt einbauen will, sollte Activepieces (MIT) oder n8n Embedded (kommerzielle Lizenz) bewusst vergleichen.

Für mission-critical-Workflows mit Stunden- oder Tage-Laufzeit, komplexem State und garantierter Exactly-Once-Semantik ist Temporal die robustere Wahl. Windmill kann durable execution durch Suspends abbilden, aber die State-Verwaltung ist nicht so durchdacht wie bei Temporal.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Windmill documentation – scripts, flows, apps, resources · 2026-05
2. Windmill pricing page (cloud and enterprise) · 2026-05
3. Windmill on GitHub – AGPLv3 core · 2026-05
4. Windmill flows, approval steps, and durable execution · 2026-04