Railpack Is No Longer Just Railway's Builder: What the 2026 Third-Party Ecosystem Proves for Self-Hosted Build Pipelines

Nixpacks is in maintenance mode, Railpack is Railway's default builder, and that part of the story is old news. The 2026 news is what happened next: seven independent projects — a Rust PaaS, Dokku docs, a Coolify beta, a GitHub Action, and more — all standardized their auto-build path on Railway's open-source builder. A builder with one production consumer is a vendor's internal tool. A builder with seven is infrastructure.

That distinction is the whole question for anyone running a self-hosted git-push pipeline. Betting your auto-build path on a single vendor's internal tool is risky: the roadmap serves one company, and if priorities shift, you own a fork. Betting on a tool with a real third-party ecosystem is a different calculus — bugs get found by strangers, edge cases get fixed upstream, and the project's survival no longer depends on one company's quarter. So here is the verdict up front: Railpack passed the second-consumer test in 2026, and passed it several times over. The rest of this post is the evidence — who adopted it, what real migrations report, and what the honest build-box floor costs.

The adopter table: who ships Railpack in 2026​

Seven rows, and none of them is Railway. That is the point. Each integration is shaped differently — shell-out, prepare/plan split, CI wrapper — which tells you the tool's seams are clean enough to embed in architectures its authors never drew.

Why Railway walked away from Nix​

To understand what these projects are betting on, it helps to know what Railpack actually is. Railway's announcement post, "Why We're Moving on From Nix," frames it as a ground-up rewrite informed by building over 14 million apps with Nixpacks. The architecture has three ideas that matter for a self-hosted operator:

The core is a compiler, not a script generator. Railpack analyzes your source and emits a build plan — a low-level graph of steps where each step declares exactly which previous step or image it needs. That plan is independent of Docker, BuildKit, or any other backend; BuildKit is currently the primary execution engine. The practical consequence: railpack prepare (plan) and the actual build are separable, which is exactly the seam rise-deploy/rise exploits to offer a buildctl path with no Docker daemon.

Execution rides BuildKit's graph. Instead of Nixpacks' Nix-store approach — which famously fills disks and serializes work — Railpack generates BuildKit LLB, getting layer caching, parallel step execution, and cache mounts largely for free. This is also where the widely quoted image-size wins come from: Pier's FAQ reports roughly 38% smaller Node images and 77% smaller Python images versus Nixpacks, crediting the BuildKit-graph approach.

Toolchains come from Mise, versions from your repo. Where Nixpacks pinned its own Nix package set, Railpack resolves runtimes through Mise — which means engines.node in your package.json is honored instead of worked around. Multiple real migrations cite exactly this: the Nixpacks-era nixpacks.toml Node version hack gets deleted, and the version file the team already maintains becomes the source of truth again.

Configuration lives in railpack.json at the repo root (JSON Schema published at schema.railpack.com), with environment-variable overrides like RAILPACK_BUILD_APT_PACKAGES and RAILPACK_DEPLOY_APT_PACKAGES splitting build-time system packages from the ones that ship in the final image.

The ecosystem, consumer by consumer​

Pier is the deepest integration and the most instructive. Pier is a single-Rust-binary Coolify alternative that idles at 20–40 MB of RAM — a project whose entire identity is lightness. Its Auto-build source deploys straight from a git repo with no Dockerfile: under the hood it shells out to Railpack against a local moby/buildkit daemon, both provisioned automatically by install.sh, with railpack.json overrides picked up from the repo root. Pier's team chose the heaviest possible build backend for the lightest possible PaaS, which tells you how much they trust the auto-detection: Node, Python, Go, PHP, Java, Ruby, Rust, Elixir, and static-site frameworks all build with zero config. They also published the honest cost of that choice, which gets its own section below.

rivetr took the portfolio approach. A commit adding "Railpack and CNB buildpack support with auto-install scripts" brought the platform to five build types — Dockerfile, Nixpacks, Railpack, Cloud Native Buildpacks via the Pack CLI, and presumably Compose/image — with build-type detection extended to the new paths and install.sh auto-installing Git, Nixpacks, Railpack, and the Pack CLI with fallbacks. That is the shape of a team hedging: Railpack is the future bet, Nixpacks stays until it isn't, and CNB covers the Heroku-buildpack crowd.

Dokku and Coolify are the incumbents moving. Dokku documented a railpack builder (install the CLI per railpack.com, run a privileged BuildKit container, point BUILDKIT_HOST at it), slotting Railpack next to its long-standing buildpacks and Dockerfile paths. Coolify went further in product terms: Railpack shipped as a beta build pack in v4.1.0 in May 2026, with the explicit guidance to prefer it for new auto-detected apps while Nixpacks remains the stable default. When the two biggest single-server PaaS projects both wire in your builder within months of each other, "single-vendor internal tool" stops describing it.

rise-deploy/rise and the GitHub Action prove the seams. Rise splits the pipeline exactly along Railpack's compiler boundary: railpack prepare emits the JSON build plan, then either docker buildx build (with the railpack-frontend BuildKit frontend) or buildctl build executes it — the latter needing no Docker daemon at all, with environment variables passed as BuildKit secrets rather than build args. The community GitHub Action by iloveitaly wraps the same flow for CI: build with Railpack, control the apt layers, push to a registry. It is now linked from Railpack's official deploying docs, which is the quietest strong signal in this whole list — Railway's own documentation sends CI users to a third-party Action.

What real migrations report​

Adoption by platforms is one signal; migrations by app developers is another. Public Nixpacks-to-Railpack migration commits in 2026 tell a consistent story:

• Smaller, faster images. The refrain across migration notes is the same: drop the explicit builder = "nixpacks" setting (or the stale nixpacks.toml), let Railway default to Railpack, get a smaller image that builds faster. One migration notes Railpack sidestepping the Nix-store disk exhaustion that had been failing their Nixpacks builds — the old backend's most hated failure mode, gone by architecture.
• engines.node honored via Mise. A representative commit moves install/build commands into railpack.json, deletes the Nixpacks Node-version workaround from nixpacks.toml, and notes that Railpack honors engines.node through Mise. The version pin the team already maintained starts working again.
• Apt packages move, and the old file is silently ignored. Under Railpack as default, nixpacks.toml is not read at all. One team debugged a failing PDF pipeline — libnspr4.so: cannot open shared object file — before realizing their apt list was sitting in a file nothing parses anymore; moving it to railpack.json under deploy.apt fixed it. Another hit the inverse: adding railpack.json alongside an existing nixpacks.toml flipped Railway's builder selection back to Nixpacks, and the fix was deleting nixpacks.toml outright.

That last pair is the real gotcha worth internalizing: the two config files are mutually exclusive signals, and neither warns you about the other. If you maintain a self-hosted pipeline that supports both builders, detect the conflict and fail loudly at plan time — don't reproduce Railway's silent behavior. And if you migrate, move the whole config (including apt packages, split into build vs. deploy) instead of leaving the old file around as a landmine.

The honest build-box floor: 4 GB of RAM, 40+ GB of disk​

Now the part vendors usually bury. Pier published a requirements table for its Railpack Auto-build path, and it is refreshingly blunt:

Compiling user code on the host is fundamentally different from running a prebuilt container, and Pier says so outright: on a host with less than 4 GB, the UI shows a hard warning because the build will almost certainly OOM-kill itself or a neighbor. This is the honest floor for any self-hosted Railpack path, not just Pier's — the BuildKit cache, the Mise toolchain downloads, and the language toolchains themselves all live on the build box. Pier's mitigations are the ones you should copy: prune the BuildKit cache daily (back to roughly 10 GB with 7-day retention), cap concurrent builds (default: one), put a memory limit on the BuildKit container (default 4g), and offer a skip flag (PIER_SKIP_RAILPACK=1) for hosts that should never build.

Translate that to hardware: a Hetzner CX32-class box (4 vCPU, 8 GB RAM) is the realistic minimum for a build node, and Rust workloads want the headroom above it. Budget the disk as cache, not storage — 40 GB free at build time, pruned on a schedule. None of this is a reason to avoid Railpack; it is a reason to provision the build tier deliberately instead of discovering the floor via OOM-kills at 2 a.m.

Should your pipeline bet on Railpack?​

The decision rule that falls out of all of this is simple. Default new auto-detected builds to Railpack if you can provision the floor above: the ecosystem depth (seven independent consumers and counting), the migration reports (smaller images, honored version pins, one well-understood gotcha), and the clean compiler/backend seam all point the same way. Nixpacks is maintenance mode — staying on it means owning every new-language rough edge yourself, forever.

Keep two escape hatches regardless of builder. First, always support plain Dockerfiles; no auto-detection covers every app, and the Dockerfile path is also your sub-4-GB story. Second, if your users come from Heroku, rivetr's CNB-via-Pack-CLI hedge is worth copying — buildpacks remain the lingua franca for that crowd. Railpack winning does not mean every other build path dies; it means the default for "I pushed code, make it run" has a new answer.

One more consideration for the roadmap-minded: Railpack's plan format is backend-independent by design, with BuildKit merely the first execution engine. A builder whose output is a portable plan is a builder your future scheduler, cache, or remote-build service can consume without re-solving language detection. That is a better foundation to standardize on than any single backend — and it is why the third-party ecosystem, not Railway's endorsement, is the real story of Railpack in 2026.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.