Windmill 2026 selbst hosten: Worker, PostgreSQL, Isolation und sichere Upgrades
Ein aktueller, produktionsnaher Folgebeitrag, der Herstellerdokumentation in Betriebskontrollen, Migrationsentscheidungen und überprüfbare Freigabekriterien übersetzt.
Was sich 2026 geändert hat
Wir greifen das Thema erneut auf, weil sich die Systemgrenzen verschoben haben. Die dauerhaften Prinzipien bleiben wertvoll, doch aktuelle Versionen machen einige frühere Abkürzungen unvollständig oder riskant. Dieser Folgebeitrag beginnt mit der am 14. Juli 2026 verfügbaren Herstellerdokumentation, trennt Fakten von lokalen Entscheidungen und behandelt jede Konfigurationsänderung als kontrollierten Eingriff in den Produktionsbetrieb.
Aktuelle Primärquellen
So setzen wir die Aktualisierung ein
Zuerst werden die Primärquellen geprüft und die tatsächlich eingesetzten Versionen dokumentiert. Vor jeder Änderung definieren wir das beobachtbare Ergebnis. Der kleinste reversible Eingriff wird in einer repräsentativen Umgebung getestet. Ein erfolgreicher Befehl ist noch kein Abnahmekriterium: Entscheidend sind Dienstzustand, Datenintegrität, Latenz, Sicherheitsgrenzen und Rücksetzzeit. Die weiterhin nützliche Diagnoselogik des früheren Beitrags bleibt nachfolgend als betriebliche Grundlage erhalten; versionsabhängige Beispiele müssen mit der aktuellen Dokumentation abgeglichen werden.
Vor der Freigabe dokumentieren wir den Konfigurationsvergleich, eine nachweislich wiederherstellbare Sicherung und die Befehle zum Rücksetzen des Eingriffs. Eine Person beobachtet das erste Produktionsfenster, eine zweite genehmigt die Eskalation, falls sich die vereinbarten Indikatoren in die falsche Richtung bewegen. Warnungen müssen das sichtbare Betriebsrisiko benennen, nicht nur die meldende Komponente. Im Readback-Zeitraum vergleichen wir Fehlerraten, Warteschlangentiefe, Ressourcensättigung, Verarbeitungslatenz und Datenvollständigkeit mit der Baseline. Dabei betrachten wir Durchschnitts- und Randwerte, weil ein stabiler Mittelwert Fehler bei einem kleinen, aber wichtigen Anteil der Vorgänge verdecken kann. Die Änderung wird erst geschlossen, wenn verzögerte Jobs, Wiederholungen, geplante Aufgaben und nachgelagerte Exporte abgeschlossen sind. Jeder manuelle Rettungsschritt wird dokumentiert; fehlt er im Runbook, ist das Runbook noch nicht vollständig.
- Die Self-Hosting-Entscheidung: Wann SaaS mehr kostet als eigene Infrastruktur
- Disaster Recovery für selbst gehostete Dienste: Unsere Backup-Strategie
- Mehrere Datenbankinstanzen auf einem Server selbst betreiben
Betriebliche Grundlage
Workflow-Automatisierungsplattformen sind für moderne Entwicklungsteams unverzichtbar, aber Cloud-Lösungen wie Windmill Cloud können mit steigender Nutzung teuer werden. Wir zeigen Ihnen, wie Sie Ihre eigene Windmill-Instanz auf Ubuntu mit Docker Compose und Traefik-Integration einrichten und dabei kritische PostgreSQL-Authentifizierungsprobleme überwinden, die Ihre Installation zum Scheitern bringen können.
Was Sie aufbauen werden
Am Ende dieses Tutorials verfügen Sie über:
- Voll funktionsfähige Windmill-Installation mit HTTPS
- Automatische SSL-Zertifikate über Let's Encrypt durch Traefik
- Produktionsreife PostgreSQL-Datenbank mit korrekter Authentifizierung
- Ressourcenoptimierte Worker-Konfiguration
- Integration mit bestehender Docker-Infrastruktur
- Produktionsreifes Setup für professionelle Workflow-Automatisierung
Monatliche Kosten: 4,51 € (CX11-Server) + Domainkosten – dieselbe Infrastruktur kann mehrere Automatisierungstools betreiben
Voraussetzungen
- Ubuntu 24.04 LTS-Server mit installierten Docker und Docker Compose
- Bestehendes Traefik-Reverse-Proxy-Setup (siehe unseren n8n-Setup-Leitfaden für die Traefik-Konfiguration)
- Domainname, der auf Ihre Server-IP verweist
- Mindestens 4 GB RAM und 2 vCPUs empfohlen
- SSH-Zugang und grundlegende Kommandozeilenkenntnisse
Windmill verstehen
Windmill ist eine Open-Source-Workflow-Engine, die Folgendes bietet:
- Visueller Workflow-Editor mit TypeScript/Python/Go-Unterstützung
- Job-Scheduling und Ausführungsverwaltung
- API-Integrationsfähigkeiten
- Team-Kollaborationsfunktionen
- Self-Hostbar ohne Nutzungslimits
Im Gegensatz zum knotenbasierten Ansatz von n8n konzentriert sich Windmill auf Code-First-Workflows mit einer leistungsstarken Entwicklungsumgebung.
Schritt 1: Servervorbereitung und Verzeichnisstruktur
Zunächst bereiten wir unsere Serverumgebung vor. Wir verwenden eine lebensmittelbasierte Namenskonvention für Windmill-Instanzen, um Konflikte zu vermeiden:
Namenskonvention: Verwenden Sie einfache Lebensmittelnamen für mehrere Windmill-Instanzen:
- Erste Instanz: pizza
- Weitere Instanzen: pasta, salad, soup, burger usw.
- Dies vermeidet Konflikte und erleichtert die Verwaltung
Schritt 2: Umgebungskonfiguration
Erstellen Sie eine sichere Umgebungsdatei mit korrekten Zugangsdaten:
Wichtig: Ersetzen Sie windmill.yourdomain.com durch Ihre tatsächliche Domain!
Schritt 3: Docker-Compose-Konfiguration
Erstellen Sie die Haupt-Docker-Compose-Konfiguration:
Wichtig: Aktualisieren Sie die Domain in den Traefik-Labels entsprechend Ihrem Setup!
Schritt 4: Das PostgreSQL-Passwort-Problem (Kritisches Problem)
Hier scheitern die meisten Windmill-Installationen, und es erforderte erhebliche Fehlersuche, um die Ursache zu identifizieren:
Das Problem: Sonderzeichen in Passwörtern
Bei der Verwendung von openssl rand -base64 32 zur Passwortgenerierung erhalten Sie oft Sonderzeichen wie =, @, #, % usw. Diese Zeichen verursachen PostgreSQL-Authentifizierungsfehler in Docker-Umgebungen, selbst wenn sie korrekt maskiert sind.
Beispiel eines problematischen Passworts:
Die Lösung: Reine Hex-Passwörter
Verwenden Sie reine Hex-Passwörter, die keine Sonderzeichen enthalten:
Zusätzliche PostgreSQL-Konfigurationsprobleme
- Benutzerkonfiguration: Verwenden Sie postgres als Standardbenutzer, nicht benutzerdefinierte Benutzer wie windmill_user
- Volume-Persistenz: PostgreSQL ignoriert POSTGRES_PASSWORD-Umgebungsvariablen, wenn bestehende Datenvolumes andere Zugangsdaten enthalten
- URL-Format: Fügen Sie ?sslmode=disable in die Datenbank-URL für Docker-Umgebungen ein
Schritt 5: Installation und Start
Installieren wir nun Windmill mit unserer korrigierten Konfiguration:
Sie sollten eine Ausgabe wie diese sehen:
Schritt 6: Fehlerbehebung häufiger Probleme
Problem 1: PostgreSQL-Authentifizierungsfehler
Symptome:
Lösung:
Problem 2: Container startet nicht
Symptome:
- Container beendet sich sofort
- Ressourcenzuweisungsfehler
Lösung:
Problem 3: SSL-Zertifikatsprobleme
Symptome:
- HTTPS funktioniert nicht
- Zertifikatsfehler
Lösung:
Schritt 7: Zugang und Ersteinrichtung
Nach Abschluss der Installation:
- Windmill aufrufen: https://windmill.yourdomain.com
- Standard-Zugangsdaten:
E-Mail: [email protected]
- Passwort: changeme
- Einrichtung abschließen:
Admin-Passwort ändern
- Basis-URL konfigurieren
- Benutzerkonten einrichten
Schritt 8: Ressourcenoptimierung
Speicherzuweisung (für 8-GB-Server)
Unsere Konfiguration weist Ressourcen effizient zu:
- Windmill Server: ~800 MB
- Windmill Worker: 2 GB (begrenzt)
- PostgreSQL: ~500 MB
- Systemreserve: ~4,7 GB
CPU-Zuweisung (für 4-vCPU-Server)
- Worker: 1 vCPU (begrenzt)
- Andere Dienste: 3 vCPUs (geteilt)
Skalierungsregel: 1 Worker pro vCPU mit jeweils 1–2 GB RAM
Schritt 9: Produktionshärtung
Backup-Skript erstellen
Monitoring einrichten
Automatisierte Updates konfigurieren
Schritt 10: Erweiterte Konfiguration
Integration mit bestehendem SMTP
Wenn Sie einen Mailserver haben (z. B. aus unserem n8n-Setup), integrieren Sie ihn:
Mehrere Windmill-Instanzen
Für Teams, die isolierte Umgebungen benötigen:
Sicherheitsaspekte
Netzwerkisolierung
- PostgreSQL nur innerhalb des Docker-Netzwerks erreichbar
- Keine externen Datenbankports freigegeben
- HTTPS-Terminierung auf Traefik-Ebene
Ressourcenlimits
- Worker-Container haben CPU- und Speicherlimits
- Verhindert Ressourcenerschöpfungsangriffe
- Konfigurierbar basierend auf Serverkapazität
SSL-Sicherheit
- Automatische Let's-Encrypt-Zertifikate
- HTTP-zu-HTTPS-Weiterleitungen
- Moderne TLS-Konfiguration
Überwachung und Wartung
Wöchentliche Gesundheitschecks
Monatliche Wartung
Kostenaufstellung und Vergleich
Monatliche Kosten
Self-Hosted-Setup:
- Hetzner CX21 (4 GB RAM): 8,46 €/Monat
- Domainkosten: ~1 €/Monat
- Gesamt: ~9,50 €/Monat
Windmill Cloud im Vergleich:
- Team-Plan: 30 $/Monat pro Benutzer
- Einsparungen: 250 $+ jährlich für kleine Teams
Leistungsvorteile
Vorteile des Self-Hosting:
- Unbegrenzte Workflow-Ausführungen
- Keine externen Rate-Limits
- Volle Datenkontrolle
- Individuelle Integrationen
- Flexible Ressourcenskalierung
Fehlerbehebungsreferenz
Schnelldiagnose
Häufige Fehlermuster
- "password authentication failed" -- Verwenden Sie Hex-Passwörter, Volumes löschen
- "connection refused" -- Netzwerkkonfiguration überprüfen
- "certificate errors" -- DNS und Traefik-Setup verifizieren
- "out of memory" -- Worker-Ressourcenlimits anpassen
Skalierung Ihrer Windmill-Infrastruktur
Horizontale Skalierung
Für Hochlast-Umgebungen:
Vertikale Skalierung
Server-Ressourcen upgraden:
- CX31 (8 GB RAM): 16,07 €/Monat für schwere Workloads
- CX41 (16 GB RAM): 29,75 €/Monat für Enterprise-Nutzung
Integration mit bestehender Infrastruktur
Zusammenarbeit mit n8n
Wenn Sie bereits n8n betreiben (aus unseren früheren Tutorials):
- Windmill behandelt Code-First-Workflows
- n8n behandelt visuelle, einfache Automatisierungen
- Beide teilen denselben Traefik-Proxy
- Separate Datenbanken verhindern Konflikte
Gemeinsam genutzte Dienste
Bestehende Infrastruktur nutzen:
- Traefik: Verwaltet SSL für alle Dienste
- Mailserver: Gemeinsames SMTP für Benachrichtigungen
- Monitoring: Einheitliches Logging und Metriken
- Backups: Zentralisierte Backup-Strategie
Fazit
Self-Hosting von Windmill bietet Enterprise-Grade-Workflow-Automatisierung zu einem Bruchteil der Cloud-Hosting-Kosten. Der Schlüssel zum Erfolg ist das Verständnis der PostgreSQL-Authentifizierungsanforderungen und die Verwendung reiner Hex-Passwörter, um Sonderzeichenprobleme zu vermeiden, die Installationen zum Scheitern bringen können.
Wichtigste Vorteile dieses Setups
- Kosteneffizient: Hunderte Euro jährlich sparen im Vergleich zu Cloud-Lösungen
- Produktionsreif: Bewältigt Enterprise-Workloads zuverlässig
- Sicher: HTTPS, isolierte Netzwerke und Ressourcenlimits
- Skalierbar: Einfach Worker und Ressourcen nach Bedarf hinzufügen
- Privat: Ihr Code und Ihre Daten verlassen nie Ihre Infrastruktur
Diese Konfiguration wurde in Produktionsumgebungen getestet und bietet die Zuverlässigkeit, die für geschäftskritische Workflow-Automatisierung benötigt wird. Die Fehlerbehebungsschritte behandeln reale Probleme, die beim Deployment aufgetreten sind, insbesondere die PostgreSQL-Authentifizierungsprobleme, die viele Self-Hosted-Installationen betreffen.
Für komplexe Workflow-Anforderungen oder Enterprise-Deployments sollten Sie professionelle Beratung in Betracht ziehen, um Ihren spezifischen Anwendungsfall zu optimieren und eine optimale Ressourcenzuweisung sicherzustellen.
Nächste Schritte
- Erkunden Sie Webhook-Fehlerbehebungstechniken, die auch für Windmill gelten
- Prüfen Sie Payload-Optimierung für den Umgang mit großen Datensätzen
- Erwägen Sie die Integration mit bestehenden n8n-Installationen
Über tva
tva gewährleistet umfassendes Infrastrukturmanagement von Datenbanksystemen, Cloud-Umgebungen und globalen Lieferketten. Unser methodischer Ansatz verbindet strenge Sicherheitsprotokolle mit Leistungsoptimierung, während strategische Beratungsdienstleistungen eine präzise Koordination sowohl digitaler Fähigkeiten als auch physischer Ressourcen ermöglichen – unter Einhaltung höchster Standards operativer Exzellenz und Compliance in allen Engagements.
Besuchen Sie tva.sg für weitere Informationen über unsere Dienstleistungen und zusätzliche Automatisierungs-Tutorials.
Von der Konfiguration zur Betriebsentscheidung
Die entscheidende Frage lautet nicht, ob sich eine Plattform konfigurieren lässt. Das Team muss Verantwortlichkeiten erklären, Abweichungen erkennen, ohne Improvisation wiederherstellen und die beabsichtigte Wirkung nachweisen können. Deshalb verbinden wir jede Änderung mit einer verantwortlichen Rolle, einer Baseline, einem Rücksetzpfad und einem festen Readback-Zeitraum. So wird aus einer einmaligen Korrektur eine belastbare Betriebsfähigkeit. Dieselbe Dokumentation gibt der nächsten verantwortlichen Person einen belastbaren Ausgangspunkt und macht spätere Optimierungen zu messbaren Entscheidungen statt zu einer neuen Runde von Vermutungen.