Garnix wird eingestellt

• garnix wird seinen Hosting-Service im Zuge des Übergangs zu Shopify am 15. Juli 2026 einstellen
• Die Codebasis von garnix wird als Open Source veröffentlicht, sodass Nutzer zu einer eigenen oder gemeinsam genutzten Instanz migrieren können
• Nutzer, die am Betrieb einer öffentlichen Community-Instanz interessiert sind, können das garnix-Team kontaktieren; auch das Team ist an entsprechenden Gesprächen interessiert
• Am 15. Juli 2026 werden alle Nutzerdaten gelöscht; dazu gehören auch Build-Artefakte
• Daten und Build-Artefakte, die aufbewahrt werden sollen, müssen vor dem Abschaltdatum manuell heruntergeladen werden; die aktuelle Mitteilung wird in Form eines zitierten E-Mails geteilt

---

Einstellung des Dienstes und Veröffentlichung des Codes

• garnix schließt sich Shopify an und stellt im Rahmen dieses Übergangs den gehosteten garnix-Dienst am 15. Juli 2026 ein
• Die Codebasis von garnix wird als Open Source veröffentlicht, damit Nutzer zu einer eigenen oder gemeinsam genutzten Instanz wechseln können
• Nutzer, die am Betrieb einer öffentlichen Community-Instanz interessiert sind, können das garnix-Team kontaktieren

Nutzerdaten und Vorbereitung der Migration

• Am 15. Juli 2026 werden alle Nutzerdaten gelöscht, einschließlich der Build-Artefakte
• Daten oder Build-Artefakte, die aufbewahrt werden sollen, müssen vor dem Abschaltdatum selbst heruntergeladen werden
• Die Abschaltungsankündigung wurde nicht auf garnix.io bestätigt und wird in Form eines Zitats aus einer von [e-mail] erhaltenen E-Mail geteilt
• Das garnix-Team bedankte sich für die Unterstützung der Community, einschließlich Spenden und Feedback aus der Zeit von Open Collective; als Teammitglieder werden Alex David, Sönke Hahn und Julian K. Arni genannt

[GN⁺]

Lobste.rs-Kommentare

• Schade! Ich mochte den Artikel sehr, der das Problem von Rolling Deployments löst, indem serviceabhängige URLs in den Service-Build eingebettet werden
  https://garnix.io/blog/call-by-hash/

• Für alle, die sich fragen, was Garnix ist:
  Garnix ist ein CI-Service für nixifizierte, flake-basierte GitHub-Repositories
  Quelle: https://github.com/garnix-io/garnix-ci#garnix

• Garnix war mit großem Abstand das beste CI-System, das ich je benutzt habe
  Während GitHub Actions noch nach einem Runner suchte, hatte Garnix den Build oft schon abgeschlossen, und selbst meine Rust-Projekte mit mittlerer Komplexität waren normalerweise in unter einer Minute fertig
  Wenn ich nur die Dokumentation geändert hatte, ging es noch schneller, und die Dokumentation wurde tatsächlich auch gebaut
  Klar, das liegt an Nix, aber Garnix hat diese Integration wirklich hervorragend umgesetzt
  CI, das in das Build-System integriert ist, kann viel besser funktionieren als ein Ansatz, bei dem bei jedem Lauf ein halbiertes Tar des Dateisystems von S3 heruntergeladen und dann ein Cache darübergelegt wird
  Dazu kommt, dass es auf Nix basiert und deshalb exakt dasselbe baut wie lokal, sodass es keine langen Feedback-Schleifen gibt wie „YAML-Tippfehler beheben, pushen, 10 Minuten warten, den nächsten Fehler sehen, Debug-Ausgabe hinzufügen, wieder pushen ...“
  Wenn es lokal baut, funktioniert es auch in CI

• Wirklich schade. In der letzten Woche oder so hatte ich ein paar merkwürdige Probleme bemerkt, aber ihnen keine große Bedeutung beigemessen
  Dass nur GitHub unterstützt wurde, fand ich etwas ärgerlich, aber trotzdem war es ein großartiger Service
  Ich werde mir am Wochenende die Open-Source-Version ansehen und prüfen, ob Self-Hosting realistisch ist, und falls jemand Alternativen für Nix-Builds kennt, wäre ich dankbar für Hinweise

• Ich nutze garnix seit dem Launch, daher ist es schon ziemlich schade, dass es eingestellt wird
  Wenn jemand Nix-CI oder eine self-hostbare Lösung kennt, wäre ich für Empfehlungen dankbar
  Ich habe garnix hauptsächlich als Cache genutzt und außerdem einen Auto-Merge-Workflow auf Basis des öffentlichen Check-Status eingerichtet

  • tangled.org wird bald etwas Ähnliches veröffentlichen. Self-Hosting wird wohl auch möglich sein
  • Da garnix offenbar als Open Source veröffentlicht wird, könnte es selbst ein Kandidat für Self-Hosting sein
    Ich war zwar kein Kunde und nutze Nix nur zu Hause, aber ich werde mir auf jeden Fall ansehen, wie man es selbst hosten kann

• Wäre nicht der folgende Teil dabei, wäre das komplett off-topic gewesen:
  „Aber wir veröffentlichen die garnix-Codebasis als Open Source; ihr findet sie hier“
  Diesen Teil halte ich für thematisch passend und interessant
  In meiner Firma setzen wir voll auf Nix, und ich habe dazu ziemlich gemischte Gefühle
  Ein großer Teil des unguten Gefühls kommt daher, dass Nix eine wirklich großartige Technologie ist, sich aber immer noch wie ein sehr junges Alien-Artefakt anfühlt
  Bei Nix bleibt noch unglaublich viel spannende und wertvolle Arbeit zu tun, und das finde ich sehr ermutigend
  Sich für Nix zu entscheiden bedeutet aber auch, auf eine ganze Reihe von Komfortfunktionen zu verzichten, die etablierte Plattformen über lange Zeit aufgebaut haben, deshalb habe ich mir Garnix und verschiedene andere Tools im Nix-Ökosystem angesehen
  Tatsächlich steckt meine Firma viel mehr Aufwand in „grundlegende“ Funktionen, die man sonst gratis bekäme
  Zum Beispiel ist schon das Ausführen von Validierungen in GitHub Actions komplexer als bei gewöhnlichen Projekten, und Dinge wie Caching und Parallelisierung sind extrem wichtig für robuste und schnelle Builds
  Ich glaube, dass Unternehmen, die das Nix-Ökosystem weiterentwickeln, stark wachsen werden, oder dass jemand auf den Schultern der Nix-Giganten etwas baut, das die Welt aufmischt
  Leider wirkt Garnix wie einer dieser Pioniere, die von einer größeren Organisation geschluckt wurden

  • Interessanterweise ist Nix gar nicht so jung
    Es ist ein paar Jahre älter als Docker und hat erst in jüngerer Zeit an Popularität gewonnen, weil es nur spät aufgeblüht ist

• Jetzt, wo garnix Open Source ist, frage ich mich, wie schwierig es wäre, es von GitHub zu entkoppeln
  Es von flakes zu entkoppeln sollte ziemlich einfach sein. Flakes sind nicht real und können dir nichts antun

  • Immer wenn ich garnix gesehen habe, fühlte ich mich wie Thaddäus, der neidisch aus dem Fenster schaut, während SpongeBob und Patrick draußen Spaß haben
    Diese Möglichkeit ist definitiv spannend

• Leicht am Thema vorbei, aber ich versuche gerade, mein CI auf Nix umzustellen, und die Dev-/CI-Umgebung ist groß
  Der Hauptgrund ist, dass mehrere vollständige Browser darin enthalten sind, und ich finde keinen Weg, nix build oder das Wiederherstellen des Caches zu vermeiden
  Selbst 10 GB in einer 1-Gbit-Umgebung wiederherzustellen ist zu langsam
  Bei Docker ist dieses Problem mit self-hosted Runnern bereits gelöst
  Man baut einfach ein Docker-Image und hält es als Cache auf dem Host vor, auf dem der CI-Runner startet
  Aber bei Nix weiß ich nicht, wie man das macht
  Ich bräuchte eine Möglichkeit, einen nix store zu teilen, in dem bereits alles enthalten ist, was die Entwicklungsumgebung braucht, und dieser Store müsste aus dem tatsächlichen Dev-Environment-Flake abgeleitet sein, das im Repository eingecheckt ist
  So etwas scheint es nicht zu geben, oder?

  • Ich verstehe das Problem nicht ganz. Wenn du den Runner selbst hostest und /nix/store vorab mit allem füllst, was für diesen Workflow benötigt wird, dann ist das doch – genau wie bei einem OCI-Image – einfach schon da, oder?
    Bei meinem früheren Arbeitgeber haben wir selbstgehostete GitLab-Runner betrieben und vor dem Einsatz für einen Service jeweils einen Satz aktueller Build-Artefakte instanziiert, um sie vorab aufzuwärmen
    Die Jobs haben dann einfach das verwendet, was bereits in /nix/store gecacht war