Sailwright befindet sich in der öffentlichen Beta – Jetzt ausprobieren · Feedback geben

Über Sailwright

Entstanden aus echten Onboarding- und Support-Problemen in gemischten Betriebssystem-Teams.

Wie alles begann

Sailwright entstand aus echten Onboarding- und Support-Problemen in gemischten Betriebssystem-Teams: Entwickler verbrachten Stunden damit herauszufinden, wie ein Rechner eingerichtet sein sollte, Unterschiede beim Setup waren schwer zu debuggen und zu reproduzieren, und betriebssystemspezifische Skripte drifteten von Quartal zu Quartal weiter auseinander. Das Ziel ist seit dem ersten Tag unverändert – die Rechnereinrichtung reproduzierbar, testbar und deutlich unabhängiger vom Gedächtnis oder selbstgeschriebenen, hostspezifischen Skripten zu machen.

Sailwright wurde ursprünglich unter dem Namen Dev Alchemy entwickelt – einige interne Pfade und Umgebungsvariablen tragen noch das alte Präfix dev-alchemy, während die Migration abgeschlossen wird.

Wie wir es sehen

Sailwright ist bewusst kein Ersatz für klassisches MDM-/UEM-Tooling. Es ergänzt diese Tools, indem es die Ebene der Entwickler-Werkzeuge und Workflows abdeckt, die meist manuell, teamspezifisch und schwer zu reproduzieren bleibt – die Skripte und das informelle Wissen, die zwischen dem liegen, was ein MDM durchsetzt, und dem, was ein Entwickler tatsächlich installiert haben muss, um arbeiten zu können.

Dieser Fokus hält den Projektumfang bewusst schmal: versionierte Ansible-Rollen und Playbooks als Single Source of Truth, plattformübergreifend, wo es sinnvoll möglich ist, umgesetzt über hostspezifisches Tooling statt über Einmal-Skripte pro Rechner.

Was Sailwright anders macht

Im Gegensatz zu reinen ansible-playbook-Läufen, chezmoi, Nix/Devbox oder Devcontainern kombiniert Sailwright Ansible mit host-spezifischem, temporärem VM-Build- und Provisioning-Tooling. So lassen sich dieselben Playbooks gegen echte macOS-, Linux- und Windows-Ziele testen, bevor sie jemals den Rechner eines Entwicklers berühren.

Konkret bedeutet das: ein einheitliches Befehlsvokabular für den VM-Lebenszyklus auf allen drei Host-Betriebssystemen, Windows-Provisioning ohne zurückbleibenden dauerhaften Remote-Verwaltungszugriff, über jede beliebige OCI-Registry (im Docker-Stil) verteilbare Build-Artefakte sowie idempotente Läufe, die Drift reparieren, statt einen Neuaufbau zu erfordern.

Lizenz

Sailwright verwendet ein duales Lizenzmodell. Copyright © 2026 Carl-Christian Sautter. Die Community Edition ist Open Source unter der GNU Affero General Public License v3 (AGPLv3). Wenn Sie Sailwright in kommerziellen Produkten, SaaS-Plattformen oder anderen Closed-Source-Umgebungen ohne AGPL-Verpflichtungen einsetzen möchten, ist eine separate kommerzielle Lizenz erhältlich – kontaktieren Sie uns für Details.

Frühe Releases wurden unter der MIT-Lizenz veröffentlicht; wenn Sie einen älteren Tag oder ein älteres Release verwenden, beachten Sie die Lizenzdatei, die in dieser Version enthalten ist.

Mitwirken

Beiträge sind willkommen – das Projekt wird offen auf github.com/csautter/sailwright entwickelt. Besonders wertvoll: weitere Rollen und Playbooks, breitere plattformübergreifende Abdeckung, bessere Dokumentation und Hilfestellung bei der Fehlerbehebung sowie Bugfixes mit Testabdeckung. Wer einen Pull Request einreicht, stimmt damit der Contributor License Agreement des Projekts zu; sie erlaubt es den Maintainern, Beiträge sowohl unter den Open-Source- als auch den oben genannten kommerziellen Bedingungen zu lizenzieren.

Aktiv werden

Werfen Sie einen Blick darauf, was Sailwright kann, unter Funktionen, oder sehen Sie es bei echten Problemen im Einsatz unter Anwendungsfälle. Informieren Sie sich über die Lizenzbedingungen im Impressum, oder kontaktieren Sie uns bei Fragen.