Release of Railpack: Today, Railpack is released, the next iteration of the Railway builder, based on lessons from building over 14 million apps with Nixpacks.

• Nixpacks Limitations: Nixpacks worked well for 80% of users but left 200k Railway users with daily limitations. A major builder upgrade was needed to scale the user base.

Problems with Nix:

• Commit-based Versioning: Nix's commit-based package versioning led to issues like only the latest major version being available and versions tied to specific commits. This made it unclear and hard to maintain, especially for contributors unfamiliar with Nix's version management. For languages like Node and Python, only the latest major version was supported, and updating the commit hash could break other package versions.
• Image Sizes and Caching: Nixpacks' use of Nix often resulted in large image sizes with a single /nix/store layer. There was no way to split Nix dependencies into separate layers, and caching was problematic as there was little control over when layer caches were invalidated.

Introducing Railpack:

• Architectural Highlights: It generates a custom BuildKit LLB + Frontend for more control over image construction. Uses Mise for version resolution and package installation. Can lock dependencies when a build is successful and improves secret environment variable management.
• How it Works: The process is split into three parts - Analyze, Plan, and Generate. BuildKit graphs are extremely parallel, and Railpack analyzes the code and generates a build plan. Each step defines the required previous step or image. BuildKit starts at the end and works backwards, pulling from the cache if possible.

What Railpack Unlocks:

• Supports building and deploying Vite, Astro, CRA, and Angular static sites with zero config.
• Has tight integration with the Railway UI.
• Supports the latest versions of languages without a Railpack release.
• Optimized layer caching for a project across environments.