Richten Sie Entwicklerrechner unter macOS, Windows und Linux ein, testen und reparieren Sie sie – mit einem einzigen Befehl.
Sailwright
Die Einrichtung eines Entwicklerrechners gehört nach wie vor zu den manuellsten Aufgaben der Softwareentwicklung: Wiki-Checklisten, Einmal-Skripte und die Frage, wer es zuletzt gemacht hat. Sailwright ersetzt das durch Automatisierung, die Sie versionieren, testen und erneut ausführen können.
Es handelt sich um ein einziges Kommandozeilen-Tool, das Entwicklungsumgebungen unter macOS, Linux und Windows einrichtet, testet und wartet. Im Hintergrund kombiniert es Ansible mit dem jeweils passenden VM- und Systemtooling für jede Plattform, sodass Teams lokale Rechner, Remote-Hosts und temporäre Testsysteme aus einem einzigen Repository heraus verwalten können.
Sailwright ersetzt nicht das MDM-/UEM-Tooling Ihrer IT-Abteilung – es ergänzt diese Werkzeuge, indem es die Entwickler-Tooling-Ebene abdeckt, die sie nicht erreichen: den Teil, der meist manuell, teamspezifisch und schwer reproduzierbar bleibt.
Das Ergebnis: identisch konfigurierte Rechner, egal wie sie entstanden sind – ein neuer Laptop, ein neu aufgesetzter CI-Runner oder eine Workstation, deren Konfiguration abweicht und wieder in den Sollzustand gebracht werden muss.
Laden Sie die Binärdatei für Ihr Betriebssystem von den GitHub Releases herunter und führen Sie anschließend aus: sailwright install
Sie starten sailwright
…die VM baut sich von selbst, unbeaufsichtigt
Warum das hilft
Ein gemeinsames, versioniertes Rechner-Setup – hier sehen Sie, was sich für ein plattformübergreifendes Team ändert:
- Neue Entwickler in Minuten statt Tagen einarbeiten
- Rechner-Setup einheitlich halten – über macOS, Windows und Linux hinweg
- Setup-Änderungen sicher in Wegwerf-VMs testen, bevor Sie sie ausrollen
- Einmal-Skripte, Erfahrungswissen und wiederholten Support-Aufwand reduzieren
- Abweichende Rechner durch erneutes Ausführen derselben Automatisierung reparieren
Wer Sailwright nutzt
Entwickler, die ihre eigene Workstation in Ordnung halten. Plattform-Teams, die neue Kolleginnen und Kollegen einarbeiten. CI-Engineers, die Build-Images wiederverwenden. Windows- und Mac-Admins, die keinen dauerhaften Remote-Zugriff wollen. IT-Leitungen, die Open Source gegen Support-Verträge abwägen.
Sailwright bedient jede dieser Gruppen ein wenig anders – sehen Sie, für wen es geeignet ist, und finden Sie Ihr Szenario.
Ein Toolkit, jeder Host
Sailwright hält die Setup-Logik in versionierten Ansible-Rollen und Playbooks vor und nutzt dann die zum jeweiligen Host passenden Werkzeuge, um sie anzuwenden und zu testen.
| Host-Betriebssystem | Was Sie heute automatisieren können |
|---|---|
| macOS | Verwaltete Workflows für macOS (Tart), Ubuntu (UTM) und Windows 11 (UTM) sowie die direkte lokale Provisionierung des Host-Systems selbst |
| Windows | Verwaltete Workflows für Ubuntu (Hyper-V) und Windows 11 (Hyper-V, plus VirtualBox als instabil) sowie die direkte lokale Provisionierung des Host-Systems selbst |
| Linux | Verwaltete Workflows für Ubuntu und Windows 11 mit nativem QEMU/KVM über libvirt/virt-manager, außerdem die direkte lokale Provisionierung des Host-Systems selbst und Docker-basiertes Linux-Testing |
Tart, UTM, Hyper-V und QEMU/KVM sind die nativen Virtualisierungswerkzeuge der jeweiligen Plattform – Sailwright steuert sie für Sie, sodass Sie nie direkt mit ihnen arbeiten müssen.
- Ansible-Rollen und Playbooks sind die einzige verbindliche Quelle für das Rechner-Setup
- Rollen bleiben so weit wie möglich plattformübergreifend und weichen nur bei Bedarf betriebssystemspezifisch ab
- Ausführungen sind idempotent: Das gleiche Setup zweimal anzuwenden ist sicher und verändert beim zweiten Mal nichts
- Rechner holen und führen ihre eigene Automatisierung lokal aus – kein zentraler Server erforderlich
- Jede Änderung lässt sich mit dem --check-Modus vorab prüfen, bevor sie den Rechner verändert
Sailwright wird von Carl-Christian Sautter gepflegt und ist unter der GNU Affero General Public License v3 (AGPLv3) quelloffen; für den Einsatz in Closed-Source- oder SaaS-Produkten steht eine separate kommerzielle Lizenz zur Verfügung – Details finden Sie unter Über uns.
Es erhebt keine Telemetriedaten und funkt nirgendwohin nach Hause: Die einzigen Netzwerkaufrufe, die es tätigt, sind die, die Sie ausdrücklich anfordern (Release-/Self-Update-Downloads, OCI-Registry-Push/-Pull sowie die Ansible-/VM-/Netzwerkoperationen, die Ihre Playbooks definieren).
Erhöhte Rechte werden gezielt und zeitlich befristet vergeben – statt pauschal „alles als Administrator auszuführen“. Unter Windows legt sailwright provision local ein dediziertes, zeitlich befristetes lokales Administratorkonto sowie einen nur lokal erreichbaren WinRM-/SSH-Listener für die Dauer des Laufs an und stellt beim Aufräumen den vorherigen Zustand wieder her. Unter macOS/Linux fragen Installations- und Provisioning-Skripte nur für die Schritte, die es benötigen, nach sudo.
Release-Binärdateien werden mit veröffentlichten Prüfsummen ausgeliefert und keyless signiert mit cosign – Verifizierungsschritte finden Sie in SECURITY.md.
Sehen Sie es in Aktion
Schauen Sie sich Zielgruppen an, entdecken Sie die Funktionen, oder sehen Sie reale Workflows unter Anwendungsfälle.
Bereit, es auszuprobieren? Laden Sie ein Release für Ihr Betriebssystem von GitHub Releases herunter und gehen Sie dann so vor:
- sailwright install – installiert die Abhängigkeiten auf dem Host
- sailwright provision local --check – zeigt eine Vorschau der Änderungen, ohne etwas zu verändern
- sailwright provision local – wendet das Setup Ihres Teams an
Die vollständige Anleitung, einschließlich Windows- und VM-Workflows, finden Sie in der Dokumentation – oder nehmen Sie Kontakt auf, wenn Sie Fragen haben.