Railpack vs Nixpacks (2026): ¿Cuál Deberías Usar Ahora?

Tras escribir desplegar un proyecto Python uv con Git y Railpack en Dokploy volví y ejecuté una comparación Railpack vs Nixpacks en condiciones. El panorama cambió desde que cubrí esto por primera vez: Nixpacks, la herramienta a la que la mayoría de paneles self-hosted todavía van por defecto, está oficialmente congelada.

El README de Nixpacks de Railway ahora lleva un banner de modo mantenimiento apuntando a Railpack. La última versión de Nixpacks fue v1.41.0 el 24-10-2025. Railpack publicó v0.41.0 el 13-10-2026 y sigue sacando una versión cada una o dos semanas.

Así que esto ya no es una pieza de “cuál es mejor”. Es una comprobación de estado más un árbol de decisión: cara a cara de cómo funcionan los dos builders, soporte plataforma por plataforma (Railway, Coolify, Dokploy), un recorrido de prueba local para que verifiques las afirmaciones en tu propia máquina, y un mapa de migración para montajes Nixpacks existentes.

Una nota de costes antes de empezar: el tamaño de imagen no es una métrica de vanidad. Imágenes base más pequeñas significan menos almacenamiento de registry y menos ancho de banda en cada pull de despliegue. Las cifras de lanzamiento — 38% menos en la base de Node y 77% menos en la de Python — son el argumento de coste. Lo desgloso en la sección de caché.

¿Qué son Railpack y Nixpacks?

Ambas herramientas resuelven el mismo problema: convertir un repo Git en una imagen OCI sin escribir un Dockerfile. Vienen de la misma empresa, y una es el reemplazo de la otra. Los pipelines de build de abajo muestran dónde divergen.

Nixpacks construye una única capa de Nix store mientras Railpack divide los builds en capas BuildKit cacheables

Nixpacks: Antes Default de Railway, Ahora en Modo Mantenimiento

Nixpacks fue presentado por Railway en 2022, escrito en Rust como alternativa a Cloud Native Buildpacks. Usa el gestor de paquetes Nix para traer dependencias de sistema y de lenguaje, detecta tu stack desde archivos como package.json o main.py, y produce una imagen reproducible con cero configuración. El post de lanzamiento de Railpack de Railway cita 14 millones de apps construidas con Nixpacks antes de que las limitaciones empezaran a morder.

Esa es la historia. El estado actual es lo que importa en 2026:

• 08-09-2025: avisos de modo mantenimiento añadidos al README y a los docs (#1365).
• 24-10-2025: v1.41.0 publicada, añadiendo soporte de Node 24. Sigue siendo la última versión al 14-10-2026.
• 24-11-2025: aviso de modo mantenimiento reforzado, el README recomienda Railpack (#1378). Último commit significativo.
• El repo no está archivado, pero está efectivamente congelado (unas 3.5k estrellas, sin release en unos 12 meses).

[Coste/ops] Una herramienta de build congelada es un riesgo operativo, no solo una insignia rancia. Tus builds siguen funcionando solo mientras los archivos de nixpkgs y las imágenes base sigan siendo compatibles. No llegarán nuevas versiones de lenguajes, y tampoco correcciones de seguridad. Node 24 es la última actualización de lenguaje que recibirá Nixpacks.

Railpack: El Sistema de Build Activo de Railway

Railpack se lanzó el 4 de marzo de 2025 (no en 2026, como afirmaban escritos más viejos, incluida mi primera versión de este artículo) con el post “Why We’re Moving on From Nix”. Está escrito en Go sobre BuildKit, con Mise manejando la resolución de versiones de herramientas. Es el sucesor de Nixpacks de Railway y, a 2026, el único sistema de build documentado de Railway.

El razonamiento del cambio merece conservarse, porque explica las diferencias de tamaño y caché que sigues viendo hoy. Empieza con el tamaño de imagen: todo lo que Nix instala aterriza en una única capa /nix/store. Reproducible, pero gruesa. Luego la invalidación de caché. Railway inyecta una variable de entorno de deployment ID, que seguía reventando las cachés de capas de Nixpacks. Las capas de BuildKit se componen e invalidan con mucha más granularidad. Luego el versionado. Las versiones de Nixpacks vienen de commits de nixpkgs, mientras Railpack resuelve versiones exactas de herramientas a través de Mise.

La meta declarada de Railway es escalar de 1 millón a 100 millones de usuarios, y el sistema de build era uno de los cuellos de botella.

Estado actual: v0.41.0 el 13-10-2026, cadencia de una a dos semanas desde principios de 2025, unas 1.2k estrellas y activo. Está probado en producción a escala de Railway, pero la CLI sigue siendo pre-1.0. Trata “estable en producción” y “API estable” como afirmaciones distintas.

Tercera opción: si ningún builder encaja, escribe tu propio Dockerfile. El orden de capas y los builds multi-stage son la palanca, y las buenas prácticas de Docker COPY para optimización de capas cubren la parte que la mayoría hace mal. En Coolify y Dokploy un tipo de build Dockerfile se sienta junto a los otros dos.

Railpack vs Nixpacks: Comparación Cara a Cara

La tecnología bajo el capó: BuildKit vs Nix

• Nixpacks: Nix empaqueta cada dependencia en una única capa gorda /nix/store. Reproducible, sí. Delgada o amigable con la caché, no.
• Railpack: BuildKit compila un plan de build en LLB con capas separadas para dependencias, build y runtime (mira el diagrama de arriba). Mise fija versiones exactas de herramientas.

En eficiencia y comportamiento de caché, gana Railpack. En reproducibilidad del modelo Nix, gana Nixpacks, si puedes vivir con el tamaño.

Configuración: Autodetección cero-config, railpack.json cuando lo necesites

Esta es la afirmación que la mayoría de artículos hacen mal, incluida mi versión anterior. Railpack no exige un archivo de config. Autodetecta tu stack con cero configuración, exactamente igual que Nixpacks. Si se encuentra un railpack.json, esa configuración se usa encima de la detección. Los docs de Railway son directos al respecto: “It works with zero configuration.”

Ambas herramientas parten por tanto del mismo sitio: haz push de un repo, obtén una imagen. Añades config solo para sobrescribir algo.

{
  "$schema": "https://schema.railpack.com",
  "packages": { "node": "22" },
  "steps": {
    "install": { "commands": ["npm ci"] },
    "build": {
      "inputs": [{ "step": "install" }],
      "commands": ["npm run build"]
    }
  },
  "deploy": { "startCommand": "node dist/index.js" }
}

[phases.setup]
nixPkgs = ["nodejs_22"]

[phases.install]
cmds = ["npm ci"]

[phases.build]
cmds = ["npm run build"]

[start]
cmd = "node dist/index.js"

El schema actual de Railpack tiene campos raíz provider, buildAptPackages, packages, caches, secrets y steps. Los steps toman inputs, commands, secrets, assets, variables, caches y deployOutputs. Si encuentras posts más viejos mostrando un array plano setup/install/deploy, esa era una forma de beta muy temprana y ya no existe.

En el lado de Nixpacks obtienes la misma historia de “sobrescribe solo lo que necesites”: nixpacks.toml opcional, más variables de entorno NIXPACKS_* como NIXPACKS_NODE_VERSION=22.

Así que “Nixpacks para plug-and-play, Railpack para control” es un marco desactualizado. Ambos son cero-config. Railpack simplemente te da una superficie de sobrescritura más profunda cuando la necesitas.

Tamaño de imagen Docker y caché de build

Estas son las cifras en las que confío. Del post de lanzamiento de Railway, medidas contra las imágenes base de Nixpacks:

• Imágenes base de Node: 38% más pequeñas con Railpack.
• Imágenes base de Python: 77% más pequeñas con Railpack.

No voy a repetir las capturas de “1.3GB vs 450MB” que circulan del mismo post. Venían de sesiones de dive en el artículo, no de un benchmark reproducible, y los porcentajes junto a ellas nunca cuadraron con las cuentas. No he vuelto a ejecutar una comparación de tamaño local para esta actualización. Si quieres tus propias cifras, construye la misma app con ambas herramientas y compara con docker images y dive.

[Coste/ops] Los porcentajes son la historia de costes: el almacenamiento del registry y el egress escalan con el tamaño de imagen. En un VPS pequeño que hace pull de imágenes en cada despliegue, una base de Node 38% más pequeña es ancho de banda que no pagas en cada pull.

La caché es donde Railpack se adelanta más:

# push/pull a shared cache from a registry (buildx syntax)
railpack build --cache-from type=registry,ref=ghcr.io/me/cache \
               --cache-to type=registry,ref=ghcr.io/me/cache,mode=max .

# force a clean build
railpack build --no-cache .

Dentro de railpack.json también puedes declarar montajes de caché compartidos vs bloqueados para cosas como node_modules o cachés de pip.

Una salvedad si despliegas en Railway: los hits de caché no están garantizados. Sus builders escalan arriba y abajo, así que un builder nuevo puede arrancar en frío. NO_CACHE=1 desactiva la caché de capas por completo. El propio consejo de Railway para apps sensibles al tiempo de build es construir la imagen tú mismo en un pipeline de CI y desplegar esa imagen. Si tu build tarda minutos y tu presupuesto es ajustado, ese es el camino honesto.

Fijación de versiones: Node.js y Python

• Railpack: el default de Node es lts, y solo se soportan versiones LTS mantenidas. El orden de resolución es RAILPACK_NODE_VERSION → devEngines.runtime → engines.node → .nvmrc → .node-version → mise.toml/.tool-versions → lts. Python va por defecto a 3.13.2 y soporta 3.10+, resuelto desde RAILPACK_PYTHON_VERSION → .python-version/.tool-versions/mise.toml → runtime.txt → Pipfile → default. Los pins a nivel de patch como 3.13.2 funcionan, porque Mise instala versiones exactas.
• Nixpacks: los pins de versión llegan a través de NIXPACKS_NODE_VERSION y amigos, pero se resuelven contra el snapshot de nixpkgs con el que la herramienta se distribuye. Node 24 llegó en v1.41.0 y nada ha llegado desde entonces. Obtienes lo que contenga ese snapshot congelado.

# Railpack: pin in the environment
RAILPACK_NODE_VERSION=22
RAILPACK_PYTHON_VERSION=3.13.2

# or commit a version file and skip the env vars
echo "22" > .nvmrc

Railpack puede fijar al release de patch que probaste. Nixpacks solo puede fijar a lo que ofrezca su snapshot congelado.

Cobertura de lenguajes y frameworks

La vieja línea de “Railpack cubre cinco lenguajes en beta” ya no existe. Railpack tiene ahora 14 providers: php, golang, java, rust, ruby, elixir, python, deno, dotnet, node (Node, Bun y tooling de frontend), gleam, cpp, staticfile y shell. Existe manejo de primera clase de frameworks para Vite, Astro, Next.js, CRA, Symfony, Laravel, Django, Rails, Phoenix, workspaces Nx y TanStack Start.

Nixpacks tiene soporte maduro para Node.js, Python, Go, PHP y más, pero esa superficie está congelada en v1.41.0. Node 24 es la última actualización de lenguaje que recibirá jamás.

La cobertura solía favorecer a Nixpacks. En 2026 favorece a Railpack, y la brecha seguirá ampliándose solo por un lado.

Soporte por plataforma en 2026: Railway, Coolify y Dokploy

Esta es la sección que importa si corres tu propio stack. Los builders no existen en el vacío; lo que puedes elegir depende del panel que tengas delante. Para cómo se comparan los paneles entre sí, mira la comparación Coolify vs Dokploy vs Kamal 2. Y si aún estás dimensionando hardware: tanto Coolify como Dokploy corren cómodamente en un VPS de Hetzner Cloud asequible (unos €4-7/mes por una máquina de clase cx22/cx32), o un VPS de Hostinger económico si quieres almacenamiento NVMe en la misma clase de precio.

Railway: Solo Railpack (Nixpacks eliminado de los docs de build)

En Railway no hay decisión que tomar. Los docs de build actuales documentan solo Railpack. Nixpacks no se ofrece como opción de build. Los servicios nuevos van por defecto a Railpack desde 2025 (la fecha exacta del changelog no pude precisarla; mira railway.com/changelog si la necesitas). Si despliegas en Railway, estás en Railpack configures algo o no.

Coolify: Ambos Builders (Railpack etiquetado Beta, apps con fuente Git)

Coolify soporta ambos. Nixpacks tiene docs maduros y sigue disponible. Railpack se ofrece como método de build etiquetado Beta: funciona solo para aplicaciones con fuente Git, y configuras el tipo de Site (Dynamic, Static o SPA) más un Publish Directory. Mira los docs de Railpack de Coolify para los campos exactos.

Guía práctica: Nixpacks sigue funcionando en Coolify hoy. Railpack es opt-in. Si estás empezando una instalación de Coolify, mi guía de cómo instalar Coolify como alternativa self-hosted gratis a Heroku cubre el montaje, y el review de Coolify v5 tiene el estado actual de la plataforma.

Dokploy: Nixpacks sigue siendo el default, Railpack “(NEW)” con fijación de versión

El tipo de build por defecto de Dokploy sigue siendo Nixpacks. Railpack aparece como tipo de build “(NEW)” con algo que las otras plataformas no te dan: un campo de fijación de versión de Railpack (mira los docs de build-type). El ejemplo de los docs muestra 0.15.1, que está rancio. Fija una versión actual en su lugar, como 0.41.x.

[Coste/ops] Fijar cambia “recibir correcciones automáticamente” por “mis builds no se rompen un martes”. Con Railpack empujando releases cada una o dos semanas, y minors con breaking changes como v0.37.0 y v0.38.0 aterrizando en los últimos meses, yo fijaría en Dokploy y refijaría deliberadamente tras leer las notas de versión.

Dokploy también expone los mandos de build como variables de entorno: RAILPACK_BUILD_CMD, RAILPACK_START_CMD, RAILPACK_PACKAGES, RAILPACK_BUILD_APT_PACKAGES y RAILPACK_DEPLOY_APT_PACKAGES. Si Dokploy no está instalado todavía, sigue la guía de instalación de Dokploy. Para una app real en este stack, usé estos tipos de build para desplegar TanStack Start en un VPS con Dokploy.

Prueba Railpack en local antes de cambiar

No migres por fe. Puedes ejecutar el plan exacto que Railpack ejecutará en tu portátil en unos minutos. Si quieres ver el mismo flujo de extremo a extremo contra una app real, sigue desplegar un proyecto Python uv con Git y Railpack en Dokploy una vez que la salida del plan de abajo te parezca correcta.

Lo que necesitas:

1. Instala la CLI:

curl -sSL https://railpack.com/install.sh | sh

mise use github:railwayapp/railpack@latest

2. Inspecciona el plan antes de construir nada:

railpack build --show-plan .

No necesitas ningún archivo de config. El plan muestra el provider detectado, las versiones de paquetes resueltas, y cada paso que Railpack ejecutará.

3. Guarda el plan para revisión o diffs de CI:

railpack prepare . --out railpack-plan.json

4. Arranca un daemon BuildKit y construye:

docker run --rm --privileged -d --name buildkit moby/buildkit
export BUILDKIT_HOST='docker-container://buildkit'
railpack build .

5. Para CI, cablea una caché compartida:

railpack build --cache-from type=registry,ref=ghcr.io/me/cache \
               --cache-to type=registry,ref=ghcr.io/me/cache,mode=max .

[Verifica] La salida de --show-plan lista los paquetes y pasos que esperas (un provider equivocado o un npm ci ausente significa que la detección no vio lo que crees). Tras el build, docker images muestra la nueva imagen. Ejecuta dive <imagen> si quieres ver los tamaños por capa.

[Modos de fallo]

• BUILDKIT_HOST sin definir o el contenedor BuildKit sin correr: railpack build falla inmediatamente. Arranca el daemon del paso 4 primero.
• Las variables de config no se leen de tu entorno de shell. Pásalas explícitamente: railpack build --env 'RAILPACK_PACKAGES=pipx:httpie jq@latest' .. Desde v0.37.1 esto también aplica a RAILPACK_DISABLE_CACHES.
• exit 75 significa un fallo transitorio. Seguro reintentar en CI en vez de fallar el pipeline.
• Windows: los builds existen, el soporte no. Usa WSL2 o una máquina Linux.

npx skills add railwayapp/railpack --skill railpack

Cómo migrar de Nixpacks a Railpack

La migración es trabajo de config, no de datos. Mapeas variables de entorno, cambias el tipo de build, y observas la salida del plan. Nada en tu base de datos o volúmenes cambia.

Mapeo de variables de entorno: NIXPACKS_* a RAILPACK_*

Vigila el cambio semántico en la fila PKGS. NIXPACKS_PKGS lista paquetes Nix. RAILPACK_PACKAGES lista herramientas Mise con versiones opcionales, por ejemplo [email protected] o pipx:httpie. No son equivalentes intercambiables.

[Verifica] Tras cambiar las variables y el tipo de build, ejecuta railpack build --show-plan . y confirma que el plan refleja los nuevos valores: paquetes esperados listados, comandos install/build intercambiados, comando de arranque correcto.

Trampas: imágenes base Debian 13, precedencia de devEngines y builds de Python desde fuente

Estos son los modos de fallo que rompen migraciones en la práctica:

• Imágenes base Debian 13 (Trixie) desde v0.37.0 (18-08-2026, breaking). Las listas apt personalizadas y las imágenes base fijadas deben ser compatibles con Trixie. GCC 14 trata los tipos de puntero incompatibles como errores, así que builds de gems nativos y extensiones C que compilaban bien bajo Nixpacks pueden fallar. Solución: actualiza las fuentes apt a Trixie y arregla los warnings de punteros en la extensión, o fija un Railpack más viejo hasta que lo hagas.
• La precedencia de devEngines cambió en v0.38.0 (26-08-2026, breaking). Un campo devEngines en package.json ahora gana a engines, .nvmrc y lockfiles. pnpm se instala vía Mise, no Corepack. Si tu versión de Node de repente parece mal, mira devEngines primero.
• Los builds de Python desde fuente fallan por diseño cuando no existe binario precompilado para la versión pedida. Es una característica: la compilación silenciosa desde fuente es lenta y frágil. Si de verdad la necesitas, MISE_PYTHON_COMPILE=1 la activa.
• Los navegadores de Playwright son opt-in vía RAILPACK_NODE_PLAYWRIGHT_INSTALL=1 o RAILPACK_PYTHON_PLAYWRIGHT_INSTALL=1. Si los tests e2e fallan con navegadores ausentes, es por eso.
• Java va por defecto a builds de Temurin, y las descargas de Node se verifican por GPG a través de Mise.

[Rollback] La migración es reversible mientras Nixpacks siga construyendo en tu plataforma. Conserva las viejas variables NIXPACKS_* y la config hasta que el build de Railpack haya corrido limpio en producción, luego elimínalas. En Dokploy y Coolify, volver el tipo de build a Nixpacks es el deshacer. No hay migración de datos en ninguna dirección.

Pros y contras

Nixpacks

Pros:

• Detección cero-config para Node.js, Python y los sospechosos habituales.
• Probado en batalla desde 2022, con 14 millones de apps construidas.
• Reproducibilidad a nivel Nix si valoras ese modelo.

Contras:

• Modo mantenimiento: sin nuevas funciones, sin nuevas versiones de lenguajes, sin correcciones de seguridad.
• Imágenes más grandes. Las imágenes base de Railpack miden 38% menos (Node) y 77% menos (Python).
• Fijación de versiones gruesa atada a un snapshot de nixpkgs congelado.
• La caché vive dentro de la única capa /nix/store, así que tienes menos que afinar.

Railpack

Pros:

Contras:

• Pre-1.0 (v0.41.x). Los releases con breaking changes aterrizan entre minors; fija versiones.
• Ecosistema más joven. Coolify etiqueta la integración como Beta, Dokploy la llama “(NEW)”.
• Algunos builds de Python necesitan MISE_PYTHON_COMPILE=1 cuando no existe binario precompilado.

Tabla de decisión: ¿Cuál deberías elegir?

Árbol de decisión 2026 para elegir entre Railpack y Nixpacks

Si estás empezando un proyecto nuevo, empieza con Railpack. Baja a un Dockerfile escrito a mano cuando necesites control total sobre capas o una base personalizada. Si tienes Nixpacks existente en Coolify o Dokploy, construye hoy, así que nada arde. Usa la tabla de migración de arriba, fija versiones, y planea el cambio en tu calendario en vez de en un incidente. En Railway, la respuesta es Railpack. No hay segunda opción.

Si ningún builder encaja y solo quieres contenedores en un VPS, mira los mejores paneles de servidor self-hosted y las rutas de Dockerfile o Docker Compose.

FAQ

Veredicto final

En 2026 la decisión es más estrecha de lo que solía ser, porque una de las dos opciones está parada.

Para proyectos nuevos, usa Railpack. Es cero-config cuando quieres eso, profundamente configurable cuando no, y produce imágenes más pequeñas con un comportamiento de caché que puedes afinar. Si quieres control máximo sobre capas e imágenes base, salta ambos y escribe un Dockerfile. Si ningún builder encaja con la forma de tu app, despliega una app Docker Compose en Dokploy y deja de pelear con el builder.

Si corres Nixpacks existente en Coolify o Dokploy, sigue construyendo hoy, fija la versión de Railpack ahora (no después), mapea tus variables NIXPACKS_* con la tabla de arriba, y verifica con railpack build --show-plan . antes de cambiar nada en producción. El rollback es un desplegable.

En Railway ya estás en Railpack. Lee las notas de versión antes de fijar.

La salvedad honesta: Railpack es pre-1.0 y v0.37.0/v0.38.0 demostraron que los breaking changes aún aterrizan. Fija versiones y refija a propósito. Nixpacks es estable de la forma en que un coche aparcado es estable: nada cambiará, incluidas las cosas que desearías que cambiaran.

Empieza esta noche: railpack build --show-plan . en cualquier repo que te importe. Tarda treinta segundos y te dice exactamente qué pasaría.