Windmill: Workflow-Automatisierung selbst hosten – ein Praxiseinstieg

Wer im Unternehmen wiederkehrende Aufgaben automatisieren will – ein nächtlicher Export aus der Datenbank, ein Skript, das eine Rechnung ins Buchhaltungssystem schiebt, ein kleines internes Formular für den Vertrieb – steht schnell vor derselben Wahl: Entweder man baut jede dieser Kleinigkeiten von Hand aus Cronjobs, Skripten und selbstgestrickten Weboberflächen zusammen, oder man kauft eine No-Code-Plattform, die den Code hinter einer Klickfläche versteckt. Beide Wege haben ihren Preis. Der erste kostet Wartungszeit, der zweite Flexibilität – und oft die Hoheit über die eigenen Daten.

Windmill (öffnet in neuem Tab) tritt genau in diese Lücke. Das Werkzeug verwandelt einzelne Skripte in aufrufbare Endpunkte, Workflows und Benutzeroberflächen, ist quelloffen und lässt sich auf der eigenen Infrastruktur betreiben. Dieser Beitrag ordnet ein, was Windmill tatsächlich leistet, für wen es sich lohnt – und zeigt den Einstieg über Docker Compose, mit dem eine lauffähige Instanz in wenigen Minuten steht.

Was Windmill ist – und was nicht

Laut der Windmill-Dokumentation (öffnet in neuem Tab) ist Windmill eine quelloffene Workflow-Engine und Entwicklerplattform, die als Alternative zu Werkzeugen wie Retool, Airflow, Prefect, Temporal und n8n positioniert ist. Der Kerngedanke lässt sich in einem Satz fassen: Ein einzelnes Skript – geschrieben in TypeScript, Python, Go, PHP, Bash, C#, SQL, Rust, Ruby oder R – wird ohne Zwischenschritte zu einer API, einem auslösbaren Job und einem automatisch erzeugten Eingabeformular.

Das ist der entscheidende Unterschied zu klassischen No-Code-Plattformen. In seinem Grundsatzpapier „Why Windmill" (öffnet in neuem Tab) teilt der Anbieter alle Programmierarbeit in zwei Kategorien: den Code, der zählt – die eigentliche Geschäftslogik – und den Boilerplate, also alles Drumherum: Oberflächen, Fehlerbehandlung, Wiederholungslogik, Abhängigkeitsverwaltung, Rechteverwaltung, Zeitpläne. Windmill will Letzteres übernehmen, ohne den erstgenannten Code hinter einer Klickfläche zu verbergen. Man schreibt weiterhin echten Code in gängigen Sprachen – Windmill kümmert sich um den Rest.

Konkret besteht die Plattform laut Dokumentation aus vier Bausteinen:

• Skripte: einzelne Funktionen in einer der unterstützten Sprachen, die zu Microservices mit automatisch erzeugter Oberfläche werden.
• Flows: ein Workflow-Editor, der Skripte per Drag-and-drop oder als YAML zu Abläufen verkettet – mit Verzweigungen, Schleifen, Wiederholungen, Freigabeschritten und Wartezuständen, die währenddessen keine Ressourcen verbrauchen.
• Apps: ein Baukasten für interne Oberflächen, wahlweise als Low-Code-Editor oder als vollständiger Code-Ansatz mit React oder Svelte.
• Auslöser: Webhooks, Zeitpläne, HTTP-Routen und eine offene API, über die sich jedes Skript und jeder Flow anstoßen lässt.

Windmill ist damit kein reines Ersatzprodukt für einen einzelnen Zweck, sondern eine Plattform, die Skript-Ausführung, Workflow-Orchestrierung und interne Oberflächen unter einem Dach zusammenführt.

Für wen sich das lohnt

Der Name des Werkzeugs verrät die Zielgruppe: Windmill bezeichnet sich selbst als code-first und developer platform. Wer keine Zeile Code schreiben möchte, ist hier falsch – dafür gibt es reine No-Code-Anbieter. Interessant wird Windmill überall dort, wo bereits Skripte laufen, die niemand richtig im Griff hat: das Python-Skript auf dem Server eines Kollegen, der nächtliche Cronjob, den keiner mehr anzufassen wagt, das interne Tool ohne Oberfläche.

Der Reiz liegt in drei Punkten, die die Dokumentation hervorhebt und die sich in der Praxis nachvollziehen lassen:

• Kein Boilerplate. Aus den Parametern einer Funktion erzeugt Windmill automatisch ein Eingabeformular. Wer schon einmal eine kleine Weboberfläche nur gebaut hat, damit ein Nicht-Techniker ein Skript anstoßen kann, kennt den Aufwand, der hier entfällt.
• Alles liegt im Code und in Git. Der gesamte Arbeitsbereich lässt sich laut Dokumentation über die CLI und Git-Synchronisierung (öffnet in neuem Tab) versionieren. Skripte, Flows und sogar Infrastrukturdefinitionen liegen als Dateien vor – kein Export-Knopf, keine Blackbox.
• Kein Lock-in. Der Code besteht aus normalen Dateien in gängigen Sprachen, ohne proprietäre SDKs. Wer Windmill wieder verlassen will, nimmt seine Skripte mit.

Für den Mittelstand ist vor allem der letzte Punkt relevant. Eine selbstgehostete, quelloffene Lösung bedeutet: Die Daten und die Automatisierung bleiben im eigenen Haus, auf der eigenen Infrastruktur. Das ist kein Nebeneffekt, sondern für viele Unternehmen mit sensiblen Prozessen die Voraussetzung überhaupt.

Wie ausgereift ist das Projekt?

Belegbarkeit vor Werbeversprechen: Windmill ist kein Neuling. Das GitHub-Repository (öffnet in neuem Tab) zählt zum Zeitpunkt dieses Beitrags rund 17.800 Sterne und über 14.600 Commits, und die Commit-Historie zeigt Aktivität im Stundenrhythmus. Nach eigenen Angaben auf der Startseite (öffnet in neuem Tab) setzen über 4.000 Organisationen das Werkzeug ein.

Ein Wort zur Geschwindigkeit, denn hier ist Vorsicht angebracht. Windmill bewirbt sich als „schnellste Workflow-Engine der Branche" und nennt in der Repository-Beschreibung (öffnet in neuem Tab) einen Faktor von 13 gegenüber Airflow. Diese Zahl stammt aus einem Benchmark des Anbieters selbst – sie ist ein Marketing-Argument, kein neutraler Messwert, und sollte entsprechend eingeordnet werden. Wer Windmill wegen der Geschwindigkeit in Betracht zieht, misst am besten mit der eigenen Last nach, statt sich auf die Hausnummer zu verlassen.

Zwei weitere Punkte gehören zur ehrlichen Einordnung: Windmill ist quelloffen, einige Funktionen – etwa die Echtzeit-Zusammenarbeit (Multiplayer (öffnet in neuem Tab)) – sind laut Dokumentation der kommerziellen Enterprise Edition vorbehalten. Und das Projekt nimmt derzeit ausdrücklich keine externen Code-Beiträge an; Fehlermeldungen und kleine, leicht prüfbare Korrekturen bleiben willkommen, wie die Contributing-Hinweise (öffnet in neuem Tab) im Repository festhalten. Für den reinen Einsatz spielt das keine Rolle, für den Gedanken „wir bauen selbst mit" aber sehr wohl.

Der Einstieg: Windmill per Docker Compose selbst hosten

Der schnellste Weg zu einer laufenden Instanz führt über Docker Compose. Laut Self-Host-Anleitung (öffnet in neuem Tab) besteht Windmill architektonisch aus nur drei Pflichtkomponenten: einer Postgres-Datenbank, die den gesamten Zustand inklusive der Job-Warteschlange hält, einem oder mehreren Containern im Server-Modus (Frontend und API) sowie einem oder mehreren im Worker-Modus, die die eigentlichen Jobs ausführen. Hinzu kommen optionale Bausteine wie der LSP-Dienst für die Editor-Unterstützung und ein Reverse Proxy (im mitgelieferten Setup Caddy).

Für einen ersten Test genügen laut Anleitung drei Dateien und ein Befehl. Voraussetzung ist eine laufende Docker-Installation; unter Linux etwa mit sudo systemctl start docker.

# Die drei Konfigurationsdateien aus dem Repository holen
curl https://raw.githubusercontent.com/windmill-labs/windmill/main/docker-compose.yml -o docker-compose.yml
curl https://raw.githubusercontent.com/windmill-labs/windmill/main/Caddyfile -o Caddyfile
curl https://raw.githubusercontent.com/windmill-labs/windmill/main/.env -o .env

# Alle Komponenten starten
docker compose up -d

Danach ist die Oberfläche unter http://localhost erreichbar. Der Caddy-Proxy leitet den Verkehr im Hintergrund an den Windmill-Server (Port 8000), den LSP-Dienst (Port 3001) und den Multiplayer-Dienst (Port 3002) weiter – nach außen ist nur ein Port sichtbar. Beim ersten Aufruf legt man ein Administrator- Konto an und kann sofort das erste Skript schreiben.

Das ist bewusst das Minimal-Setup für den lokalen Test. Wer produktiv gehen will, sollte einige Dinge beachten, die die Dokumentation ausdrücklich nennt:

• Datenbank auslagern. Für den Produktivbetrieb empfiehlt Windmill, den mitgelieferten Postgres-Container abzuschalten (Replikate auf 0) und über DATABASE_URL in der .env eine externe, verwaltete Datenbank anzubinden – etwa AWS RDS/Aurora, GCP Cloud SQL, Azure Database oder Neon.
• Rechteproblem bei verwalteten Datenbanken. Wenn der Datenbank-Nutzer kein Postgres-Superuser ist – bei RDS, Cloud SQL, Azure und Scaleway die Regel –, müssen die Windmill-Rollen laut Dokumentation vorab manuell angelegt werden, sonst bricht die erste Migration mit role "windmill_admin" does not exist ab. Dafür liefert Windmill ein Init-Skript mit, das einmalig mit einer privilegierten Rolle ausgeführt wird. Diese Falle kostet beim ersten Anlauf gern eine Stunde – wer sie kennt, umgeht sie.
• Worker skalieren. Als Faustregel nennt die Anleitung einen Worker pro vCPU und 1 bis 2 GB RAM. Mehr Durchsatz erreicht man, indem man schlicht die Zahl der Worker-Replikate erhöht – vom einzelnen VPS bis zum Kubernetes-Cluster mit vielen Knoten reicht dasselbe Modell.
• TLS außerhalb terminieren. Windmill empfiehlt ausdrücklich, die TLS-Verschlüsselung nicht im mitgelieferten Caddy, sondern über einen vorgelagerten Load Balancer oder Reverse Proxy zu regeln.

Für den größeren Maßstab gibt es zusätzlich ein Helm-Chart (öffnet in neuem Tab) für den Betrieb auf Kubernetes. Der Docker-Compose-Weg reicht aber, wie die Dokumentation festhält, für viele Anwendungsfälle vollkommen aus – gerade im Mittelstand, wo selten von Beginn an ein 1.000-Knoten-Cluster gebraucht wird.

Wenn Docker Compose nicht mehr reicht: Helm-Chart auf Kubernetes

Wächst die Last über eine einzelne Maschine hinaus, empfiehlt die Self-Host-Dokumentation (öffnet in neuem Tab) ausdrücklich den Wechsel auf das offizielle Helm-Chart statt eines handgestrickten Kubernetes-Manifests. Der Einstieg braucht laut Dokumentation nur zwei Befehle:

# Windmill-Helm-Repository hinzufügen
helm repo add windmill https://windmill-labs.github.io/windmill-helm-charts/

# Chart mit Standardwerten installieren
helm install windmill-chart windmill/windmill \
      --namespace=windmill \
      --create-namespace

Detaillierte Konfiguration – etwa für die Enterprise Edition oder eigene Werte für values.yaml – liefert das README des Chart-Repositories (öffnet in neuem Tab). Die Faustregel für die Worker-Dimensionierung gilt dabei unverändert: laut Dokumentation ein Worker pro vCPU und 1 bis 2 GB RAM, unabhängig davon, ob er auf einem einzelnen Server per Docker Compose oder als Pod im Cluster läuft. Für AWS-, GCP- und Azure-Umgebungen empfiehlt die Dokumentation explizit den Helm-Weg auf verwaltetem Kubernetes; nur für ein vereinfachtes Setup reicht laut Anleitung Docker Compose auf einer großen Einzelinstanz mit entsprechend vielen Worker-Replikaten.

Einordnung: sinnvoll, aber kein Selbstläufer

Windmill ist ein durchdachtes Werkzeug für eine reale Not: die vielen kleinen Automatisierungen, die in jedem Unternehmen entstehen und die niemand pflegt. Dass es Skripte in gängigen Sprachen zu vollwertigen internen Werkzeugen macht, ohne den Code zu verstecken, ist der eigentliche Gewinn. Wer bereits mit Python, TypeScript oder Bash arbeitet, findet hier eine Plattform, die den lästigen Teil abnimmt und die Hoheit über Code und Daten im Haus lässt.

Ein Selbstläufer ist es dennoch nicht. Der Betrieb einer selbstgehosteten Instanz mit externer Datenbank, sauberer TLS-Terminierung und skalierten Workern ist Infrastrukturarbeit, die Kompetenz voraussetzt. Und die eigentliche Frage entscheidet sich nicht am Werkzeug, sondern an den Prozessen: Welche Abläufe lohnt es überhaupt zu automatisieren, und wie schneidet man sie so zu, dass sie robust laufen und nicht beim nächsten Systemwechsel zerbrechen? Das Werkzeug ist der einfache Teil. Der schwierige beginnt davor.

Für einen ersten Eindruck aber genügt der Docker-Compose-Befehl von oben. Eine Viertelstunde, eine laufende Instanz – und danach die weit wichtigere Frage, was man ihr eigentlich anvertrauen will.