Nixpacks vs Docker: Guía Definitiva sobre Tamaño, Velocidad y Por Qué Railway Cambió de Rumbo

La decisión entre Nixpacks vs Docker solía ser simple: intercambiar control por conveniencia. Pero en 2025, Railway -- el equipo que construyó Nixpacks -- lo puso en modo de mantenimiento y lanzó Railpack como su reemplazo. Eso cambia completamente el cálculo. Esta es la comparación completa docker vs nixpacks con tamaños de imagen reales, datos de velocidad de compilación, código lado a lado y un marco de decisión que tiene en cuenta dónde están realmente las cosas en 2026.

Nixpacks vs Docker de un Vistazo

Si necesitas desplegar sin un Dockerfile y tu stack está soportado, Nixpacks (o su sucesor Railpack) te pone en marcha en segundos. Si te importa el tamaño de la imagen, la velocidad de compilación o la optimización de producción, un Dockerfile personalizado gana cada vez.

Algo que vale la pena entender desde el principio: Nixpacks no reemplaza a Docker. Genera un Dockerfile internamente y usa el BuildKit de Docker para producir imágenes compatibles con OCI. Es una capa de abstracción sobre Docker, no una alternativa.

¿Qué es Nixpacks? (Y Cómo Difiere de Nix)

Nixpacks es una herramienta de compilación creada por Railway que detecta automáticamente el lenguaje y framework de tu aplicación, luego genera una imagen de contenedor sin ninguna configuración. Subes código, Nixpacks se encarga del resto. Esa es la propuesta, y para aplicaciones simples, realmente funciona.

Así se ve una compilación de Nixpacks:

# Sin configuración -- Nixpacks detecta tu stack automáticamente
nixpacks build . --name my-app

# O con un comando de inicio personalizado
nixpacks build . --name my-app --start-cmd "node dist/index.js"

Nixpacks escanea tu código fuente en busca de archivos como package.json, requirements.txt o go.mod y elige el "proveedor" correcto -- su término para recetas de compilación específicas del lenguaje. Fue diseñado para ser más rápido y simple que los buildpacks estilo Heroku, y durante un tiempo fue el compilador predeterminado de Railway.

Cómo Nixpacks Detecta Tu Stack

El pipeline de detección es directo: Nixpacks recorre la raíz de tu proyecto buscando archivos de configuración conocidos. ¿Encontró un package.json? Proveedor de Node.js. ¿Encontró requirements.txt o pyproject.toml? Proveedor de Python. Incluso maneja monorepos hasta cierto punto, aunque las cosas se complican con diseños de proyecto no estándar.

Nix vs Nixpacks: No Son lo Mismo

Esto confunde a casi todo el mundo (incluidos la mayoría de artículos que rankean para esta consulta). Nix es un gestor de paquetes funcional y sistema de compilación enfocado en compilaciones reproducibles. Nixpacks es una herramienta específica que usa paquetes Nix internamente para resolver dependencias. Están relacionados pero son diferentes -- como decir que "npm" y "create-react-app" son lo mismo porque uno usa al otro.

El contexto crítico para 2026: Nixpacks está en modo de mantenimiento. Railway dejó de agregar características y construyó Railpack para abordar limitaciones fundamentales. Los proyectos existentes siguen funcionando, pero no hay una hoja de ruta para mejoras.

Docker y Dockerfiles: El Estándar de la Industria

Conoces Docker. Así que saltemos el párrafo "Docker es una plataforma de contenerización" y centrémonos en lo que importa para esta comparación.

Un Dockerfile te da control explícito, capa por capa, sobre tu imagen de contenedor. Eliges la imagen base, controlas qué archivos se copian, especificas exactamente qué dependencias se instalan y optimizas el resultado final con compilaciones multi-etapa. Aquí hay un ejemplo listo para producción:

# Dockerfile multi-etapa de Node.js -- optimizado para tamaño
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist
EXPOSE 3000
CMD ["node", "dist/index.js"]

Las características clave de Docker relevantes para esta comparación: las compilaciones multi-etapa te permiten separar las dependencias de tiempo de compilación de la imagen de ejecución. El caché de capas a través de BuildKit hace que las compilaciones subsecuentes sean rápidas y predecibles. Y la selección de imagen base (Alpine, distroless, scratch) te da control directo sobre el tamaño de la imagen y la superficie de ataque.

El conocimiento de Docker también es universalmente transferible. Cada proveedor de nube, cada plataforma CI/CD, cada destino de despliegue entiende un Dockerfile.

Nixpacks vs Docker: Comparación Directa

Configuración e Instalación

El mayor punto de venta de Nixpacks es el despliegue sin configuración. Para una aplicación estándar de Node.js, literalmente no necesitas ningún archivo de configuración. Subes código, obtienes un contenedor. Con Docker, necesitas escribir y mantener un Dockerfile.

Cuando sí necesitas personalizar Nixpacks, usas nixpacks.toml:

# nixpacks.toml -- personalizar comportamiento de Nixpacks
[phases.setup]
nixPkgs = ["...", "ffmpeg"]  # Agregar dependencias del sistema

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

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

El Dockerfile equivalente es más verboso pero mucho más explícito:

FROM node:20-alpine
RUN apk add --no-cache ffmpeg
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
CMD ["node", "dist/index.js"]

Para un hackathon o prototipo, Nixpacks te ahorra tiempo real. Para cualquier cosa que mantendrás más de un fin de semana, ese Dockerfile se paga solo en capacidad de depuración y potencial de optimización.

Veredicto: Empate. Nixpacks gana para velocidad de despliegue. Docker gana para mantenibilidad a largo plazo. Elige según tu cronograma.

Tamaño de Imagen

Aquí es donde la comparación se vuelve brutal. Las imágenes de Nixpacks son grandes. No "ligeramente más grandes" -- estamos hablando de 10-17x más grandes que un Dockerfile optimizado para la misma aplicación.

Un caso bien documentado: un desarrollador migró una aplicación Next.js de Nixpacks a un Dockerfile personalizado y vio la imagen reducirse de 1.3GB a 76.83MB -- una reducción de 17x. Eso no es inusual.

La razón se reduce a la arquitectura. Nixpacks vuelca todo en /nix/store -- herramientas de compilación, compiladores, símbolos de depuración, bibliotecas que nunca necesitarás en tiempo de ejecución -- todo en una capa masiva. Las compilaciones multi-etapa de Docker te permiten descartar todo excepto los artefactos reales de ejecución.

Veredicto: Docker gana decisivamente. Esto no es un llamado cercano. Si el tamaño de la imagen importa para tu proyecto -- y casi siempre importa para producción -- Docker es la única opción real.

Velocidad de Compilación y Caché

Las primeras compilaciones con Nixpacks son típicamente más lentas porque descarga paquetes Nix desde cero. Según los propios datos de Railway, una compilación típica de Nixpacks toma alrededor de 1 minuto 27 segundos, versus 15 segundos para una compilación de Dockerfile y 6 segundos para una imagen pre-construida.

Las compilaciones subsecuentes cuentan una historia más matizada. El caché binario de Nix puede acelerar las cosas, pero es menos predecible que el caché de capas de Docker. Un cambio en tu package.json invalida el caché de Nix ampliamente, mientras que el caché de capas de Docker solo reconstruye capas desde el paso modificado en adelante.

El caché de capas de Docker también es más transparente. Puedes ver exactamente qué capas cambiaron y por qué. El caché de Nixpacks es más una caja negra -- o acierta o no, y depurar fallos de caché en el almacén Nix requiere experiencia que la mayoría de equipos no tienen.

Veredicto: Docker gana. Más predecible, más rápido tanto para compilaciones iniciales como en caché, y más fácil de depurar cuando el caché falla.

Soporte de Lenguajes y Frameworks

Nixpacks detecta automáticamente alrededor de 20 lenguajes y frameworks: Node.js, Python, Go, Rust, Java, Ruby, PHP, .NET, Elixir y más. Para stacks soportados, la detección es genuinamente impresionante -- elige la versión correcta del runtime, configura el comando de compilación y configura el comando de inicio automáticamente.

Docker soporta cualquier cosa para la que puedas escribir un Dockerfile. Eso es efectivamente ilimitado. Runtimes exóticos, cadenas de herramientas personalizadas, monorepos multi-lenguaje -- si se ejecuta en Linux, Docker lo maneja.

La diferencia de fijación de versiones importa más de lo que pensarías. Nixpacks usa versionado basado en commits para paquetes Nix. No puedes decir "Python 3.11.4" -- obtienes cualquier versión que el commit de Nix proporcione. Docker te da control exacto de versión: FROM python:3.11.4-slim es determinista.

Veredicto: Docker gana por flexibilidad. Nixpacks es conveniente si tu stack está en la lista de soportados. Docker maneja todo, con control de versión preciso.

Preparación para Producción y Seguridad

Las imágenes de Nixpacks incluyen muchos más paquetes de los que tu aplicación realmente necesita. Eso se traduce en una superficie de ataque mayor -- más binarios significa más vulnerabilidades potenciales. La capa inflada de /nix/store contiene compiladores, herramientas de compilación y bibliotecas que no tienen nada que hacer en una imagen de producción.

Docker te da opciones como Alpine (mínimo), distroless (sin shell, sin gestor de paquetes) o incluso FROM scratch para lenguajes compilados. Estas imágenes mínimas contienen solo lo que tu aplicación necesita para ejecutarse, reduciendo drásticamente la superficie de ataque.

La depuración es otra brecha. Las imágenes de Nixpacks tienen una estructura de directorios poco familiar centrada alrededor de /nix/store con rutas basadas en hash. Si algo sale mal en producción, pasarás tiempo descubriendo el diseño del sistema de archivos antes de poder siquiera empezar a solucionar problemas.

Veredicto: Docker gana para producción. Menor superficie de ataque, herramientas de depuración familiares y pipelines de escaneo de seguridad establecidos favorecen a Docker.

Experiencia de Desarrollador

Aquí es donde Nixpacks realmente brilla. Para un desarrollador que nunca ha escrito un Dockerfile, ir de código a contenedor en ejecución en un comando es mágico. nixpacks build . -- listo. Sin sintaxis que aprender, sin imagen base que elegir, sin orden de capas en que pensar.

La curva de aprendizaje de Docker no es empinada, pero es real. Escribir un Dockerfile eficiente requiere entender el caché de capas, compilaciones multi-etapa, .dockerignore y la distinción entre COPY y ADD. Es conocimiento que vale la pena, pero toma tiempo adquirirlo.

El compromiso a largo plazo vale la pena considerar. El conocimiento de Nixpacks es específico de la plataforma -- es útil en Railway, Coolify y un puñado de otras plataformas. El conocimiento de Docker es universal y transferible a cualquier trabajo, cualquier proveedor de nube, cualquier destino de despliegue.

Veredicto: Nixpacks gana para comenzar. Docker gana para utilidad de toda la carrera. Si estás aprendiendo, comienza con Nixpacks para enviar rápido, luego aprende Docker para producción.

Lado a Lado: Misma Aplicación, Ambas Formas

Veamos la diferencia práctica. Aquí hay una API de Node.js Express configurada para ambas herramientas.

Nixpacks (sin configuración -- no se necesita archivo):

# Nixpacks detecta automáticamente Node.js desde package.json
# No se requiere archivo de configuración
nixpacks build . --name express-api

# Resultado: imagen de ~900MB

Para Nixpacks, ni siquiera necesitas un nixpacks.toml si tu aplicación es estándar. Lee package.json, detecta el script de compilación y configura el comando de inicio.

Docker (Dockerfile multi-etapa optimizado):

# Dockerfile para la misma API Express
FROM node:20-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:20-alpine
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY ./src ./src
EXPOSE 3000
CMD ["node", "src/index.js"]

Ahora una aplicación FastAPI de Python:

Nixpacks (sin configuración):

# Nixpacks detecta Python desde requirements.txt
nixpacks build . --name fastapi-app

# Resultado: imagen de ~1.1GB

Docker (Dockerfile optimizado):

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY ./app ./app
EXPOSE 8000
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

Aquí está la salida lado a lado:

# Comparación de tamaño de imagen
$ docker images
REPOSITORY          TAG       SIZE
express-api-nix     latest    924MB    # Compilación Nixpacks
express-api         latest    83MB     # Docker multi-etapa
fastapi-nix         latest    1.12GB   # Compilación Nixpacks
fastapi-app         latest    92MB     # Docker slim

La versión de Nixpacks "simplemente funciona" sin ningún esfuerzo. La versión de Docker toma 10-15 minutos escribir pero produce una imagen que es 10x más pequeña, se despliega más rápido y cuesta menos almacenar y transferir.

El Problema del Tamaño de Imagen: Por Qué Nixpacks Crea Contenedores de 800MB

El inflado de la imagen no es un error que puedas configurar -- es una consecuencia fundamental de cómo funciona Nix internamente.

Qué Hay Realmente Dentro de una Imagen de 1.3GB

Cuando Nixpacks compila tu aplicación, el gestor de paquetes Nix resuelve cada dependencia (incluidas las de tiempo de compilación) y las copia en /nix/store. Ese almacén se convierte en una única capa masiva en tu imagen de contenedor. Dentro de una imagen típica de Node.js construida con Nixpacks, encontrarás:

• Compiladores de compilación (gcc, g++) que solo se necesitaban durante npm install
• Encabezados de desarrollo para módulos nativos que quizás ni siquiera uses
• Símbolos de depuración que agregan cientos de MB
• Bibliotecas del sistema no utilizadas incluidas como dependencias transitivas de Nix
• Todos los metadatos del almacén Nix -- hashes, referencias de derivación y grafos de dependencias

Por Qué No Puedes Simplemente Optimizarlo

Docker resuelve esto con compilaciones multi-etapa: compila en una etapa, copia solo la salida a una etapa de ejecución limpia. Nixpacks no tiene un mecanismo equivalente. La arquitectura de /nix/store trata todos los paquetes como una única unidad atómica. No puedes elegir selectivamente qué paquetes Nix llegan a la imagen final.

Puedes intentar limitar paquetes en nixpacks.toml siendo explícito sobre aptPkgs y paquetes Nix, pero las dependencias de runtime de Nix centrales siguen incluyéndose. El techo práctico para la optimización de Nixpacks aún te deja con imágenes 5-8x más grandes que una compilación de Docker equivalente.

El costo real de imágenes de más de 800MB: despliegues más lentos, mayores costos de almacenamiento en el registro de contenedores, arranques en frío más largos en plataformas serverless y más consumo de ancho de banda cada vez que un nodo extrae la imagen. Para una startup ejecutando 10 réplicas con despliegues frecuentes, esos gigabytes extra se suman tanto en tiempo como en dinero.

Cuando el tamaño de la imagen importa -- y importa para cualquier cosa más allá de un prototipo -- la respuesta es directa: escribe un Dockerfile.

El Factor Railpack: Por Qué Railway Abandonó Nixpacks

Este es el contexto que cambia todo sobre el debate nixpacks vs docker. En marzo de 2025, Railway -- el equipo que construyó Nixpacks y lo desplegó en 14 millones de compilaciones de aplicaciones -- anunció que seguían adelante.

Sus razones fueron específicas y técnicas:

1. Versionado basado en commits -- Los paquetes Nix no usan semver. No puedes solicitar "Node 20.11.1." Obtienes cualquier versión que un commit específico de Nix proporcione, haciendo las compilaciones reproducibles más difíciles de lo que deberían ser.
2. Tamaños masivos de imagen -- La arquitectura de /nix/store hizo la optimización estructuralmente imposible. Los más de 200,000 usuarios de Railway estaban desplegando imágenes innecesariamente infladas.
3. Caché impredecible -- El caché binario de Nix funcionaba inconsistentemente, llevando a compilaciones lentas que frustraban a los desarrolladores.

Qué Mejora Railpack Sobre Nixpacks

Railpack abandona Nix por completo. Usa una base Ubuntu con gestores de paquetes estándar (apt, herramientas específicas del lenguaje) y compilaciones multi-fase adecuadas. Los resultados son significativos:

• Imágenes de Node.js: 38% más pequeñas que Nixpacks
• Imágenes de Python: 77% más pequeñas que Nixpacks
• Soporte semver adecuado: solicita node@20 o [email protected] y obtienes exactamente eso
• Caché predecible: caché basado en capas estándar que los desarrolladores entienden

Railpack todavía está en beta. Actualmente soporta Node.js, Python, Go, PHP y HTML estático. Rust, Ruby, Java y varios otros lenguajes que Nixpacks maneja aún no están disponibles en Railpack.

Docker vs Nixpacks vs Railpack: Tabla Resumen

Soporte de Plataforma: Dónde Funciona Cada Herramienta

Tu elección de contenerización depende parcialmente de dónde estés desplegando. Aquí hay plataformas de despliegue modernas que soportan qué herramientas de compilación:

Algunas conclusiones: Docker es la única herramienta de compilación soportada en todas partes. Si la portabilidad de plataforma importa, un Dockerfile es tu apuesta más segura. El soporte de Nixpacks está concentrado en herramientas PaaS auto-hospedadas (Coolify, Dokploy) y algunas plataformas administradas (Kinsta). Railpack es exclusivo de Railway por ahora.

Cuándo Usar Cada Una: Marco de Decisión

Aquí está la matriz de decisión. Si tu situación coincide con una fila, la recomendación ha sido probada en proyectos reales.

Tres reglas generales:

1. ¿Prototipando? Usa herramientas sin configuración (Nixpacks, Railpack). No pierdas tiempo escribiendo un Dockerfile para algo que podrías desechar.
2. ¿Yendo a producción? Escribe un Dockerfile. Los 30 minutos que inviertes ahorran horas de depuración de imágenes infladas y compilaciones impredecibles.
3. ¿Ya en Nixpacks? No migres en pánico. Planifica un cambio a Railpack o Docker cuando tu proyecto alcance naturalmente un hito.

Cómo Techsy Aborda los Despliegues de Contenedores

Hemos enviado aplicaciones de producción tanto con Nixpacks como con Dockerfiles personalizados, así que aquí está nuestra opinión honesta.

Para prototipos de clientes y MVPs, a menudo comenzamos con compiladores sin configuración. Eliminan fricción durante la fase en que estás iterando sobre características diariamente y aún no sabes si el proyecto tiene piernas. Nixpacks (o ahora Railpack en Railway) es perfecto para esto -- despliega en segundos, enfócate en el producto.

En el momento en que un proyecto llega a producción, cambiamos a Dockerfiles optimizados. Nuestro proceso se ve así:

1. Auditar la imagen actual -- verificar tamaño, identificar paquetes innecesarios, escanear vulnerabilidades
2. Escribir un Dockerfile multi-etapa -- separar dependencias de compilación del runtime
3. Configurar caché de capas adecuado -- ordenar instrucciones COPY para maximizar aciertos de caché
4. Elegir la imagen base correcta -- Alpine para la mayoría de aplicaciones, distroless para servicios críticos de seguridad
5. Integrar en CI/CD -- compilar, probar, empujar al registro, desplegar

Hemos ayudado a startups a pasar de imágenes de Nixpacks de más de 1GB a imágenes de Docker de menos de 100MB, reduciendo tiempos de despliegue por 5x y ahorrando dinero significativo en costos de registro de contenedores.

¿Construyendo algo y no estás seguro sobre tu configuración de despliegue? Obtén una consulta gratuita -- te ayudaremos a elegir el enfoque correcto para tu proyecto.

Preguntas Frecuentes

¿Nixpacks está deprecado?

Sí. Nixpacks está en modo de mantenimiento desde 2025. Railway (su creador) construyó Railpack como el sucesor. Los proyectos Nixpacks existentes siguen funcionando y reciben correcciones de errores críticos, pero no se agregan nuevas características o proveedores de lenguajes. Para proyectos nuevos, considera Railpack o un Dockerfile personalizado.

¿Qué reemplazó a Nixpacks?

Railpack, construido por Railway (el mismo equipo detrás de Nixpacks). Abandona completamente la dependencia de Nix, usando compilaciones basadas en Ubuntu con gestores de paquetes estándar. El resultado: imágenes de Node.js 38% más pequeñas e imágenes de Python 77% más pequeñas comparadas con Nixpacks, con soporte de versión semver adecuado.

¿Por qué las imágenes de Nixpacks son tan grandes?

La arquitectura del almacén Nix copia todos los paquetes -- incluyendo dependencias de tiempo de compilación como compiladores y símbolos de depuración -- en una única capa grande. No hay equivalente de las compilaciones multi-etapa de Docker para eliminar archivos innecesarios. Una aplicación simple de Node.js típicamente produce una imagen de 800MB-1.3GB vía Nixpacks versus 50-100MB con un Dockerfile optimizado.

¿Debería usar Nixpacks o Docker?

Para prototipado rápido en plataformas soportadas, Nixpacks te despliega sin configuración. Para aplicaciones de producción donde el tamaño de imagen, seguridad y rendimiento de compilación importan, un Dockerfile personalizado te da imágenes 10-50x más pequeñas y mucho más control. Dado el estado deprecado de Nixpacks, Docker es la inversión más segura a largo plazo.

¿Pueden Nixpacks y Docker usarse juntos?

Sí. Nixpacks genera un Dockerfile internamente y usa el motor BuildKit de Docker para producir imágenes. Muchos equipos usan Nixpacks para entornos de desarrollo y staging (iteración rápida, sin configuración) mientras mantienen un Dockerfile personalizado para despliegues de producción.

¿Cuál es la diferencia entre Nix y Nixpacks?

Nix es un gestor de paquetes funcional y sistema de compilación enfocado en compilaciones reproducibles. Nixpacks es una herramienta de compilación creada por Railway que usa paquetes Nix para detectar automáticamente lenguajes y contenerizar aplicaciones. Son herramientas relacionadas pero diferentes -- Nix es la tecnología subyacente, Nixpacks es el envoltorio opinado construido sobre ella.

¿Railway todavía soporta Nixpacks?

Railway todavía soporta Nixpacks para proyectos existentes, pero el compilador predeterminado para proyectos nuevos es ahora Railpack. También puedes usar un Dockerfile personalizado en Railway. Para cambiar, simplemente agrega un Dockerfile a la raíz de tu proyecto -- Railway lo detecta automáticamente y lo usa en lugar de Nixpacks.

¿Nixpacks es más rápido que Docker?

Generalmente no. Las primeras compilaciones con Nixpacks son más lentas debido a las descargas de paquetes Nix (alrededor de 1 minuto 27 segundos versus 15 segundos para una compilación de Dockerfile, según benchmarks de Railway). Las compilaciones en caché pueden ser comparables para cambios simples, pero el caché de capas de Docker es más predecible y granular en general.

¿Cómo cambio de Nixpacks a un Dockerfile en Railway?

Agrega un Dockerfile a la raíz de tu proyecto. Railway lo detecta automáticamente y lo prioriza sobre Nixpacks -- no se necesitan cambios de configuración. Escribe un Dockerfile multi-etapa optimizado para tu stack, súbelo y Railway se encarga del resto.

¿Qué plataformas usan Nixpacks?

Coolify, Dokploy, Kinsta y Dokku (vía plugin) todavía usan activamente Nixpacks. Railway ha hecho la transición a Railpack como predeterminado. Render, Fly.io y Vercel usan sus propios sistemas de compilación propietarios. Docker es el único enfoque de compilación soportado en cada plataforma.

¿Nixpacks es bueno para producción?

Nixpacks es mejor para desarrollo y staging que para producción. Los tamaños de imagen grandes (más de 800MB), las opciones de optimización limitadas y el estado deprecado lo hacen una elección arriesgada para cargas de trabajo de producción. Para producción, un Dockerfile personalizado o Railpack (si estás en Railway) son opciones más sólidas.

Veredicto Final

Docker es la mejor opción para la mayoría de desarrolladores que se preocupan por la calidad de producción. Gana cinco de siete categorías, y las dos categorías que Nixpacks gana (velocidad de configuración, DX para principiantes) importan más durante el prototipado -- una fase que es temporal por definición.

Nixpacks sirvió un propósito real: demostró que la contenerización sin configuración es posible y valiosa. Pero sus limitaciones fundamentales -- imágenes infladas, caché impredecible, versionado basado en commits -- llevaron a sus propios creadores a construir algo mejor. Railpack puede eventualmente ofrecer lo mejor de ambos mundos (sin configuración con tamaños de imagen razonables), pero todavía está en beta con soporte de lenguajes limitado.

Aquí está la recomendación práctica: si estás comenzando un nuevo proyecto en Railway, deja que Railpack maneje tus compilaciones. Si estás desplegando en cualquier otro lugar, o si te diriges hacia producción, invierte los 30 minutos para escribir un Dockerfile adecuado. Ese pequeño costo inicial te ahorra depurar imágenes de 1GB, despliegues lentos y una herramienta de compilación que ya no está evolucionando.

Fuentes

• Why We're Moving on From Nix - Railway Blog
• Nixpacks Official Documentation
• Replacing Nixpack with a Docker Image on Railway - Apvarun
• Docker Best Practices - Official Documentation
• Railpack Official Documentation
• Nixpacks GitHub Repository