GitHub Actions haben sich als eine der beliebtesten Lösungen für Continuous Integration und Continuous Deployment etabliert. Doch trotz ihrer Leistungsfähigkeit stoßen Entwickler bei der Arbeit mit komplexen Systemkonfigurationen, vor allem im NixOS-Umfeld, schnell an eine harte Grenze: den verfügbaren Speicherplatz auf den GitHub Actions Runnern. Standardmäßig stehen dort etwa 20 Gigabyte nutzbarer Speicherplatz zur Verfügung, was auf den ersten Blick ausreichend erscheinen mag. Im Alltag erweist sich dies jedoch als nur äußerst begrenztes Platzangebot, wenn es darum geht, umfangreiche NixOS-Konfigurationen oder Home Manager-Setups aufzubauen und vollständig in der CI/CD-Pipeline zu bauen und zu testen. Die Speicherlimitierung kann die Entwicklererfahrung stark beeinträchtigen und führt nicht selten zu der frustrierenden Fehlermeldung „no space left on device“.
Sie hindert Entwickler daran, ihre vollständigen Konfigurationen zu validieren und vollständig gecachte Builds zu erzeugen, was die Geschwindigkeit und Effizienz der gesamten Entwicklungs- und Auslieferungskette deutlich reduziert. Die Problematik geht dabei weit über einen simplen Mangel an Speicherplatz hinaus. Eine umfassende Arbeitsstation oder ein Home-Lab-Server mit allen nötigen Entwicklerwerkzeugen, Softwarepaketen und Abhängigkeiten nimmt oft zwischen 10 bis 15 GB Speicher nur für den Nix Store in Anspruch. Hinzu kommen Dinge wie angepasste Kernel-Module, Drittanbieter-Software wie Ollama oder spezifische Paketüberschreibungen, die noch weiteren Platz beanspruchen. Das Resultat: Die vorhandenen 20 GB sind in der Praxis für viele Entwickler schlicht nicht ausreichend. Ohne den vollen Zugriff auf ausreichend hohen Speicherplatz sind Builds oft nur unvollständig möglich.
Im schlimmsten Fall bleiben nur Teilschritte oder einzelne Pakete testbar, was die Gefahr birgt, dass bei Änderungen an Systemen oder Paketen nicht die gesamte Konfiguration korrekt geprüft wird. Die Folge sind verlängerte lokale Kompilationszeiten, verschwendete Ressourcen und verzögerte Release-Zyklen. Vor diesem Hintergrund hat der Entwickler Martin Wimpress das Projekt „Nothing but Nix“ ins Leben gerufen. Es handelt sich um eine innovative GitHub Action, die das Speicherplatzproblem auf den Runnern auf radikale Weise angeht. Das Ziel ist klar: Den verfügbaren Speicherplatz von circa 20 GB auf bis zu 130 GB zu erhöhen, sodass auch sehr schwere Nix-Builds problemlos innerhalb von GitHub Actions ausgeführt werden können. Dabei handelt es sich keineswegs um einen einfachen Hack oder Workaround, sondern um eine technische Lösung, die die vorhandenen Ressourcen der Runner-Systeme intelligent und effizient nutzt.
So wird beispielsweise ungenutzter Space auf dem /mnt-Dateisystem entdeckt und dynamisch für die Nix-Umgebung einbezogen. Der Kern der Technik hinter „Nothing but Nix“ ruht auf zwei Hauptmechanismen. Zunächst wird direkt zu Beginn des Workflows ein großer Loopback-Device erzeugt, das aus dem freien Speicher auf dem /mnt-Volume stammt. Dieses Image wird mit einem speziell getunten Btrfs-Dateisystem formatiert, das dediziert nur für Nix genutzt wird. Dieses Btrfs-System nutzt RAID0 für optimale Performance und Kompression, was besonders in CI-Umgebungen von großem Vorteil ist. Schon direkt nach dem Mounten dieses zusätzlichen Volumes stehen dem Nix Store circa 65 GB Speicher mehr zur Verfügung, ohne dass der Entwickler selbst in die Konfiguration eingreifen muss. Doch „Nothing but Nix“ hört nicht bei dieser initialen Speichererweiterung auf. Während der Workflow weiterläuft, startet ein im Hintergrund arbeitender Prozess eine aggressive Bereinigung des Systems.
Dabei werden vorinstallierte, aber für Nix-User häufig unnötige Pakete und Softwarekomponenten gelöscht. Dazu zählen unter anderem Docker-Images, mehrere Programmiersprachen-Runtimes, Paketmanager oder umfangreiche Dokumentationen. Das Ziel ist eine merkliche Reduktion des belegten Speicherplatzes und damit eine dynamische Vergrößerung des verfügbaren Nix-Speichers. Nach dem erfolgreichen Löschen dieser unnötigen Daten wird ein weiteres Volume als Loopback-Device erzeugt, das dann zum Btrfs-Pool hinzugefügt wird und so die Kapazität auf bis zu 130 GB anhebt. Eine wichtige Rolle bei dieser radikalen Speicherplatzgewinnung spielt die Verwendung von „rmz“, einer Komponente des Fast Unix Commands Projekts, die das Löschen von Dateien stark beschleunigt. Klassische Löschvorgänge können in einer CI-Umgebung mit großen Datenmengen sehr zeitintensiv sein und den Workflow unangemessen verlangsamen.
RMz reduziert die Löschzeit von etwa elf Minuten auf unter eine Minute und sorgt so für eine effiziente und schnelle Speicherbereinigung. Neben der praktischen Umsetzung ist die Wahl von Btrfs als Dateisystem für den erweiterten Nix Store eine bewusste technologische Entscheidung. Btrfs unterstützt unter anderem die dynamische Erweiterung eines Speicherpools durch Hinzufügen weiterer Geräte, was maßgeblich für die flexible Speichervergrößerung genutzt wird. Zusätzlich sorgt die Kompressionsfunktion – standardmäßig mit zstd – für zusätzlichen Speicherplatzgewinn bei den Nix-Paketen und deren Artefakten. Das Mounten der Loopback-Devices mit der Option „nodiscard“ verhindert außerdem Probleme mit falscher Speicherplatzanzeige, die bei Loopgeräten ohne diese Option auftreten können. Insbesondere bei sparsam belegten Dateien ist diese Einstellung essentiell für eine korrekte Verwaltung und Meldung der Systemkapazität.
Ein spannendes Feature von „Nothing but Nix“ ist das sogenannte „Hatchet Protocol“. Hierbei handelt es sich um verschiedene Modi, mit denen der Nutzer steuern kann, wie aggressiv die Speicherplatzbereinigung ausfallen soll. Optionen wie „holster“, „carve“, „cleave“ oder „rampage“ erlauben eine fein abgestufte Balance zwischen Leistung, Benutzerfreundlichkeit und maximaler Speicherfreigabe. So kann man beispielsweise mit „holster“ lediglich den freien Platz aus dem /mnt-Verzeichnis nutzen und damit etwa 65 Gigabyte erhalten, während „rampage“ eine radikale Eliminierung jeglicher unnötiger Software durchführt und so bis zu 130 Gigabyte an Speicher freigibt. Die Voreinstellung „cleave“ wird für die meisten Nix-Anwender empfohlen, da sie ein optimales Verhältnis zwischen einer hohen Speicherfreigabe und dem Erhalt wichtiger Tools bietet. Die Vorteile für Entwickler, die mit „Nothing but Nix“ arbeiten, sind enorm.
Einmal eingerichtet, können alle Nix- und Home Manager-Konfigurationen vollständig und zuverlässig in CI-Systemen gebaut und validiert werden. Der gesamte Buildprozess lässt sich so auf ein Minimum an Kompilationszeit reduzieren, da dank eines vollständigen Zwischenspeichers („Cache“) bei FlakeHub Updates mit minimalem Mehraufwand erfolgen können. Für Arbeitsstationen, Server, Laptops und VMs ergeben sich dadurch signifikante Effizienzsteigerungen, ohne dass bei Konfigurationsänderungen stets eine vollständige Neukompilierung nötig wird. Ein weiterer Aspekt ist die Kostenersparnis. Statt teurere GitHub Runner mit mehr Ressourcen mieten zu müssen, wird das Potential der standardmäßig bereitgestellten Runner durch „Nothing but Nix“ weitaus besser ausgeschöpft. Gerade für kleine Teams, Hobby-Entwickler oder Open Source-Projekte kann dies eine entscheidende Rolle spielen, um Entwicklungs- und Testprozesse ökonomisch durchführbar zu halten.
Gerade Entwicklungen bei Determinate Systems verdeutlichen, wie wichtig und zeitgemäß die Lösung ist. Dort werden umfangreiche FlakeHub-Caches für schnelle Systemupdates genutzt, aber zuvor freier Speicherplatz in GitHub Actions war schlicht nicht ausreichend. Mit „Nothing but Nix“ konnten nun komplette Server- und Workstation-Setups, lokale LLMs (Language Model-Instanzen), Medienserver, Backup-Systeme und mehr in CI zuverlässig abgebildet und gebaut werden. Das Resultat ist eine drastische Verbesserung der Entwicklerproduktivität und Systemstabilität. Darüber hinaus denkt der Entwickler Wimpress bereits über zukünftige Erweiterungen nach, etwa die Nutzung von Hardwarevirtualisierungstechnologien wie KVM innerhalb von GitHub Actions. So wäre es denkbar, in naher Zukunft sogar VM-basierte Buildumgebungen direkt in GitHub Actions zu starten und so die Flexibilität und Sicherheit der CI-Pipelines weiter zu erhöhen.
Diese Vision zeigt, wie weit die Idee von ressourcenschonender und effizienter CI in Kombination mit Nix bereits gediehen ist. Für alle, die „Nothing but Nix“ testen möchten, ist der Einstieg sehr einfach. Im GitHub Actions Workflow wird die Aktion direkt nach dem Checkout ausgeführt, bevor Nix installiert und genutzt wird. So steht der erweiterte Speicherplatz sofort für alle Buildschritte zur Verfügung. Zudem ist eine korrekte Berechtigungskonfiguration für die Authentifizierung am FlakeHub erforderlich, damit der Cache optimal genutzt wird. Die ganze Aktion ist als Open Source auf GitHub verfügbar und lässt sich flexibel an individuelle Bedürfnisse anpassen. Zusammenfassend markiert „Nothing but Nix“ einen bedeutenden Fortschritt in der Anwendung von Nix in der Cloud. Mit diesem Tool wird die größte Speicherplatzbeschränkung der GitHub Actions Runner elegant umgangen und ein neuer Standard für produktive und skalierbare Nix-Projekte gesetzt.
Entwickler, die auf komplexe Multi-Paket-Builds angewiesen sind, können nun kommerzielle teure Infrastruktur umgehen und trotzdem schnelle, vollumfängliche Builds realisieren. Die Kombination aus ausgeklügelter technischer Lösung und einfacher Bedienbarkeit macht „Nothing but Nix“ zu einem wertvollen Werkzeug für die Nix-Community und darüber hinaus. Die stetige Weiterentwicklung und das Engagement der Community versprechen dabei, dass noch viele spannende Funktionen und Verbesserungen folgen werden. Wer auf der Suche nach einer zuverlässigen, kosteneffizienten und zukunftssicheren Lösung für Nix Builds in CI/CD-Umgebungen ist, sollte „Nothing but Nix“ unbedingt ausprobieren und sein eigenes CI-Setup damit auf ein neues Level heben.
