Why We're Moving on from Nix

Summary

Today we’re excited to release Railpack — the next iteration of the Railway builder, developed from the ground up and based on everything we’ve learned from building over 14 million apps with Nixpacks.We first announced Nixpacks nearly 3 years ago and it quickly became the default way to build images from user code on Railway. While Nixpacks works great for 80% of users, that still left us with 200k Railway users who might encounter limitations daily. It became clear we needed a major builder upgrade to scale our user base from 1M to 100M.Cumulative builds with Nixpacks over timeHere are the highlights of Railpack:Granular Versioning: Support for major.minor.patch versions of packages (instead of Nix’s approximate versions)Smaller Builds: We’ve been able to reduce image sizes between 38% (Node) and 77% (Python), enabling faster deploys on RailwayBetter caching: Railpack interfaces directly with BuildKit to control the layers and filesystem, resulting in more cache hits (with sharable caches across environments)You can opt-in to using Railpack for your builds today. It is already powering builds for railway.com and central station.The biggest problem with Nix is its commit-based package versioning. Only the latest major version of each package is available, with versions tied to specific commits in the nixpkgs repo. We tried to support every patch version, but it looked like this:const AVAILABLE_SWIFT_VERSIONS: &[(&str, &str)] = &[ // ... ("5.4", "c82b46413401efa740a0b994f52e9903a4f6dcd5"), ("5.4.2", "c82b46413401efa740a0b994f52e9903a4f6dcd5"), ("5.5.2", "7592790b9e02f7f99ddcb1bd33fd44ff8df6a9a7"), ("5.5.3", "7cf5ccf1cdb2ba5f08f0ac29fc3d04b0b59a07e4"), ("5.6.2", "3c3b3ab88a34ff8026fc69cb78febb9ec9aedb16"), ("5.7.3", "8cad3dbe48029cb9def5cdb2409a6c80d3acfe2e"), ("5.8", "9957cd48326fe8dbd52fdc50dd2502307f188b0d"), ];This approach isn’t clear or maintainable, especially for contributors unfamiliar with Nix’s version management.For languages like Node and Python, we ende...