Seit fast drei Jahren war Nixpacks das Herzstück von Railway, wenn es darum ging, Containerimages aus Nutzeranwendungen zu erstellen. Mit über 14 Millionen gebauten Apps zeigte sich Nixpacks als robuste Lösung, die für den Großteil der Nutzer funktionierte. Dennoch gab es eine signifikante Nutzerzahl – etwa 200.000 Anwender – die tagtäglich mit den Grenzen von Nixpacks zu kämpfen hatten. Als Railway plante, die Nutzerbasis von einer Million auf 100 Millionen zu skalieren, wurde klar, dass eine grundlegende Verbesserung des Builders notwendig war.
So entstand Railpack – die neue Generation des Railway Builders, die von Grund auf neu entwickelt wurde und sämtliche Erfahrungen aus Nixpacks einbezieht. Aber warum genau hat sich Railway für den Wechsel weg von Nix entschieden und welche Vorteile bringt Railpack mit sich? Um diese Fragen zu beantworten, lohnt sich zunächst eine detaillierte Betrachtung der Schwächen und Herausforderungen, die mit Nix verbunden sind, sowie das, was Railpack heute neu und besser macht. Nix – Stärken und Grenzen Nix ist an sich eine innovative Paketverwaltung und Build-Umgebung, die durch ihren deklarativen und wiederholbaren Ansatz besticht. Bei Railway wurde Nixpacks entwickelt, um mittels Nix diese Stärken für das Bauen von Containerimages für Apps nutzbar zu machen. Doch in der Praxis erwies sich insbesondere die Art der Versionierung der Pakete als große Hürde.
In Nix sind Paketversionen nicht einfach als Major-, Minor- oder Patch-Versionen organisiert, sondern mit einem spezifischen Commit-Hash im nixpkgs Repository verbunden. Zwar können unterschiedliche Major-Versionen nebeneinander existieren, doch sind die Versionen an jeweilige Commit-SHA gebunden, was die konsistente Verwaltung von mehreren Patch-Versionen erschwert. Dies führte dazu, dass Railway bei Sprachen wie Node.js und Python im Grunde nur die jeweils neueste Major-Version unterstützte. Ein Update eines einzigen Commit-Hashes hatte unweigerlich Auswirkungen auf andere Paketversionen, wodurch Builds, die zuvor problemlos liefen, plötzlich mit unerwarteten Fehlern scheiterten.
Diese Unvorhersehbarkeit sorgte für Frust bei den Nutzern und erschwerte eine stabile und verlässliche Build-Umgebung, vor allem für größere Projekte und in Produktionsumgebungen. Zudem war diese komplexe, commitbasierte Verwaltung schwer für Entwickler außerhalb der Nix-Community zu durchschauen und zu warten. Neben der Versionierung wurde auch die Größe der erzeugten Containerimages zum Problem. Nixpack-Builds bündelten sämtliche Pakete und deren Abhängigkeiten in einer einzigen großen Layer-Datei im Nix-Store, die sich kaum weiter aufsplitten ließ. Das führte zu vergleichsweise schweren Images, die langsame Deployments und größere Ressourcennutzung verursachten.
Weil die Layer so groß waren, war das Caching und die Wiederverwendung von bereits gebauten Layern eingeschränkt. Ein zusätzlicher Faktor, der das Caching beeinträchtigte, war die Art und Weise, wie Railway Umgebungsvariablen in den Build einschleuste. Ein Deploymentspezifischer ID-Wert wurde in jeder Buildumgebung gesetzt und verursachte dadurch, dass viele Layer stets ungültig wurden und komplett neu gebaut werden mussten. All dies zusammen erschwerte Effizienz und Geschwindigkeit. Die Nachteile von Nixpacks basierten dabei weniger auf Schwächen von Nix selbst, sondern vielmehr darauf, wie die Technologie implementiert und abstrahiert wurde.
Railway stellte fest, dass eine zu starke Abstraktion der komplexen Eigenheiten von Nix zum Scheitern verurteilt ist. Für die Mehrheit der Nutzer ist es weder sinnvoll noch praktikabel, sich mit Konzepten wie Derivationen oder komplizierten Commit-gebundenen Versionen auseinanderzusetzen. Dieses Missverhältnis zwischen Nix-Prinzipien und anwenderfreundlicher Umsetzung führte zur Entscheidung, neue Wege zu gehen. Aus Nixpacks wird Railpack – Die Zukunft des Buildens Railpack ist das Ergebnis einer radikalen Neuorientierung. Bei der Entwicklung wurde klar, dass man sich von Nix und der gewohnten Rust-Codebasis trennen musste, um den Anforderungen an Skalierbarkeit, Geschwindigkeit und Wartbarkeit gerecht zu werden.
Railpack basiert daher komplett auf Go in Kombination mit moderner BuildKit-Technologie, die den Buildprozess granular steuert und parallele Abläufe erlaubt. Eines der wichtigsten Updates ist die granulare Versionsverwaltung. Railpack unterstützt echte Major-, Minor- und Patch-Versionen von Paketen und entfernt so die eigentümliche, restiktive Commit-basierte Versionierung. Dadurch können Nutzer jederzeit flexibel die gewünschte Version eines Pakets wählen, ohne auf unerwartete Veränderungen oder Ausfälle gefasst sein zu müssen. Diese Stabilität ist in professionellen Umgebungen entscheidend.
Zusätzlich sind die erzeugten Images mit Railpack deutlich schlanker. Node.js-Images werden um knapp 40 Prozent, Python-Images sogar um über 75 Prozent kleiner als bei Nixpacks. Dieser signifikante Unterschied führt unmittelbar zu schnelleren Deployments und spart Bandbreite sowie Speicherplatz bei den Anwendern. Das Caching-System profitiert ebenfalls enorm.
Dank der direkten Integration mit BuildKit kann Railpack den Layer-Cache besser verwalten, Verschwendung durch unkontrollierte Cache-Invalidierung verhindern und Schichten sogar über verschiedene Umgebungen hinweg teilen. Damit entfällt beispielsweise das Problem der zerstörerischen Umgebungsvariablen, weil Railpack die jeweiligen Werte hasht und diese Hashes indikativ in ein virtuelles Dateisystem einbindet. Nur wenn sich der Code oder die genutzten Umgebungsvariablen ändern, werden die entsprechenden Layer neu gebaut. Railpack geht dabei sogar noch weiter und verbessert den Umgang mit sensiblen Informationen durch den Einsatz von BuildKit-Secrets. Geheimnisse werden somit weder in Logs noch im finalen Image sichtbar, was die Sicherheit der Builds erhöht.
Zudem schafft Railpack durch seine ausgefeilte Planungsarchitektur, die aus Analyse, Planung und Generierung eines Buildplans in JSON besteht, eine höhere Transparenz und überprüfbare Abläufe. Jeder Arbeitsschritt ist genau definiert, einschließlich Abhängigkeiten und Datei-Ein-/Ausgaben, was die Wartung und Erweiterbarkeit der Build-Prozesse erleichtert. Für Entwickler bietet Railpack unmittelbare Vorteile im Alltag. Die Unterstützung moderner Frameworks für Frontend-Static-Site-Deployments wie Vite, Astro, Create React App oder Angular macht den Einstieg denkbar einfach und erfordert keinerlei zusätzliche Konfiguration. Dies erleichtert die Nutzung von Railway als vielseitige Plattform sowohl für Backend- als auch Frontend-Anwendungen.
Zukunft und Verfügbarkeit Railpack befindet sich derzeit in der Beta-Phase und kann von Nutzern in den Service-Einstellungen aktiviert werden. Neben Node.js und Python werden kontinuierlich weitere Sprachen und Frameworks eingebunden. Das Projekt ist offen, quelloffen zugänglich und wird aktiv durch die Community weiterentwickelt. Dennoch setzt Railway derzeit den Fokus vor allem auf die Tiefe der Unterstützung bei den am weitesten verbreiteten Technologien, um hier eine stabile und ausgereifte Nutzererfahrung zu gewährleisten.
Mit Railpack setzt Railway einen zukunftsweisenden Schritt, der das schnelle, flexible und übersichtliche Erstellen von Containerimages neu definiert. Der Wechsel von Nixpacks zu Railpack ist kein einfacher Technikwechsel, sondern eine strategische Entscheidung für Skalierbarkeit, Stabilität und Benutzerfreundlichkeit. Entwickler müssen sich nicht länger mit unzugänglichen und komplexen Versionierungsproblemen auseinandersetzen, sondern können sich auf das Wesentliche konzentrieren: die Entwicklung großartiger Anwendungen. Zusammenfassend lässt sich sagen, dass Railpack nicht nur ein neues Werkzeug für Railway ist – es markiert einen Paradigmenwechsel in der Art, wie Build-Prozesse orchestriert werden. Dieser Wandel ist gerade in Zeiten rasanter technologischer Entwicklung unverzichtbar und erleichtert es Entwicklern, von den neuesten Versionen und Innovationen zu profitieren, ohne Angst vor unerwarteten Build-Ausfällen oder langsamen Deployments zu haben.
Railway ist damit bestens gerüstet für die nächste Evolutionsstufe seiner Plattform und die Millionen von Anwendungen, die zukünftig darauf aufbauen werden.
