Auto-build (Railpack)

Push de código, obtén un contenedor — sin Dockerfile requerido.

Application #auto#buildpack#railpack#git

Railpack es un image builder moderno estilo build-pack que auto-detecta tu lenguaje y framework, genera un plan BuildKit y produce una imagen OCI de producción. Pier lo envuelve para que puedas desplegar Node, Python, Go, Rust, Ruby, PHP, Java, Deno, Bun, Elixir y más directo desde una URL de Git — sin Dockerfile, sin lock-in de Nixpacks, sin config manual.

Desplegar con Pier

1 Abre el panel de Pier y haz clic en Add service.
2 Elige Auto-build (Railpack) en la lista de plantillas.
3 Elige la versión, asigna un nombre al servicio y Pier provisionará automáticamente el contenedor, el almacenamiento y los puertos.
4 Vincula un dominio si quieres HTTPS. Traefik genera el certificado de Let's Encrypt automáticamente.

¿Qué es Railpack?

Railpack es un image builder open-source desarrollado por Railway y liberado en 2024 como sucesor de Nixpacks. Inspecciona un repositorio Git, identifica el lenguaje y framework, y produce una imagen OCI lista para producción usando BuildKit — sin requerir Dockerfile.

El resultado es la experiencia “push de código, obtén contenedor” pionereada por Heroku y Railway, pero construida sobre infraestructura moderna — ejecución LLB paralela de BuildKit, cache de capa granular, e imágenes base mínimas específicas por lenguaje en lugar del pesado Nix store que Nixpacks shipping. Las imágenes Railpack típicas son 20-80% más pequeñas que la salida Nixpacks equivalente y rebuildean 2-5× más rápido en cache hits.

Pier envuelve Railpack como el template de servicio “Auto-build”. Le das URL Git, puerto y (opcionalmente) un comando de start — Pier clona el repo, corre Railpack, buildea la imagen y la despliega bajo Traefik con TLS. El loop entero, desde git push hasta URL en vivo, toma 30-120 segundos dependiendo del tamaño del proyecto y el estado del cache.

Cómo lo despliega Pier

Cuando creas un servicio Auto-build, Pier:

Clona la URL Git configurada en el branch elegido.
Corre railpack build sobre el source — Railpack inspecciona, planea y genera una imagen OCI taggeada para tu servicio.
Almacena la imagen en el registry local de Pier y arranca un contenedor en el puerto expuesto.
Cablea Traefik para que el servicio sea alcanzable en su dominio asignado (con TLS automático Let’s Encrypt si se adjunta un dominio custom).

Un railpack.json en la raíz del repo te deja sobrescribir cualquier cosa que Railpack auto-detecte — versión de lenguaje, paquetes de sistema, comandos install/build/start, env vars de build-time. La mayoría de proyectos necesita cero config.

Redeploys por webhook — configura tu host Git para hacer POST al webhook de redeploy de Pier para el servicio, y cada push al branch vigilado rebuildea y rola automáticamente.

Cuándo NO usar Railpack

Si ya tienes un Dockerfile que funciona, mantelo — usa el template Dockerfile. Dockerfiles finamente tuneados ganan a cualquier auto-builder en tamaño de imagen, control de capa y superficie de revisión de seguridad para una app específica.

Si tu build necesita paquetes de sistema exóticos, lógica multi-etapa custom, o artefactos no-OCI (sistemas init, stacks supervisord, distroless multi-binarios), Dockerfile es también la respuesta correcta.

Para imágenes pre-buildeadas desde un registry — usa el template Docker Image. Para stacks multi-contenedor definidos juntos — Docker Compose. Railpack brilla específicamente para “tengo un repo, quiero un contenedor, no quiero escribir líneas de Dockerfile”.

Características clave

Detección de lenguaje sin config

Detecta Node, Python, Go, Rust, Ruby, PHP, Java, Deno, Bun, Elixir, Static y más desde ficheros de paquetes (package.json, requirements.txt, go.mod, Cargo.toml, Gemfile, composer.json). Sin lista de buildpacks que memorizar.

Nativo BuildKit

Genera un plan LLB (low-level build) que BuildKit ejecuta — etapas paralelas, cache de capa granular, aislamiento de frontend. 30-80% más rápido en rebuilds vs buildpacks clásicos.

Imágenes más pequeñas que Nixpacks

La imagen Railpack típica es 20-80% más pequeña que la salida Nixpacks equivalente al saltar la capa Nix store y usar bases mínimas Debian o Alpine por lenguaje.

Framework-aware

Conoce Next.js, Astro, Vite, Nuxt, Remix, SvelteKit, Django, Flask, FastAPI, Rails, Laravel, Phoenix — elige los comandos install / build / start correctos automáticamente.

Modo sitio estático

Detecta salida estática pura (Astro, Vite, Hugo, Jekyll) y despliega un runtime `nginx` en lugar de servidor Node — imagen 5 MB, cold start microsegundos.

Friendly a overrides

Suelta un `railpack.json` en la raíz del repo para fijar versiones, añadir paquetes de sistema, sobrescribir install/build/start, setear env vars. Sobrescribe solo lo que necesitas; los defaults manejan el resto.

Casos de uso

Workflows push-to-deploy

Conecta tu repo a Pier, push a main → Railpack auto-buildea → el servicio rola. Sin CI YAML, sin mantenimiento de Dockerfile.

Equipos políglotas

Un template maneja cada servicio en un monorepo multi-lenguaje. Servicio backend Go, frontend Next.js, worker ML Python — mismo builder, mismo UX.

Migrando desde Heroku / Render / Railway

Apps ya diseñadas para buildpacks de Heroku / Render / Railway portan a Railpack con cero o casi cero cambios. Mismas convenciones (Procfile, scripts package.json, requirements.txt).

SSR + estático lado a lado

Un sitio Astro con `output: 'server'` corre Node SSR; el mismo repo como `output: 'static'` despliega un contenedor nginx — Railpack elige correctamente basado en el build output.

Demos y prototipos rápidos

Levanta una URL funcional desde cualquier repo GitHub en menos de un minuto. Útil para previews de PR, hackathons, demos a clientes.

Ejemplos de código

Desplegar una app Next.js (sin config) bash

# En Pier:
# 1. New service → Auto-build (Railpack)
# 2. Git URL: https://github.com/you/my-next-app.git
# 3. Branch: main
# 4. Port: 3000
# 5. Deploy.
#
# Railpack detecta Next.js, corre:
#   npm ci → npm run build → npm run start
# Resultado: imagen OCI de producción, ~120 MB.

Overrides railpack.json json

{
  "$schema": "https://schema.railpack.com",
  "provider": "node",
  "packages": {
    "node": "22",
    "pnpm": "9"
  },
  "aptPackages": ["ffmpeg", "imagemagick"],
  "buildCommand": "pnpm run build",
  "startCommand": "pnpm start",
  "env": {
    "NODE_ENV": "production"
  }
}

Monorepo multi-lenguaje (config raíz) json

{
  "provider": "python",
  "packages": { "python": "3.12" },
  "installCommand": "pip install -r requirements.txt",
  "startCommand": "uvicorn app:app --host 0.0.0.0 --port $PORT"
}

Shortcut sitio estático json

{
  "provider": "static",
  "buildCommand": "npm run build",
  "outputDirectory": "dist"
}

Comparativa

vs Dockerfile (este catálogo)	Dockerfile te da 100% control pero escribes y mantienes la lógica de build. Railpack la escribe por ti y se queda fuera del camino hasta que necesites un override. Usa Dockerfile cuando necesites paquetes de sistema exóticos o builds multi-arch; Railpack para todo lo demás.
vs Nixpacks (el builder anterior de Railway)	Nixpacks pionereó el patrón auto-detect-and-build pero produce imágenes grandes al enviar un Nix store. Railpack es el sucesor — imágenes más chicas, cache más rápida, overrides más simples, frontend BuildKit moderno.
vs Heroku Buildpacks / Cloud Native Buildpacks	CNB es un estándar abierto con ecosistema rico pero builds más lentos y curva de override más empinada (project.toml, ordering de buildpacks). Railpack es más simple, más rápido, opinado.
vs Imagen Docker manual	Un Dockerfile finamente tuneado siempre gana en tamaño + boot time para la app específica que apunta. Railpack gana en velocidad de iteración y uniformidad a través de servicios.

Preguntas frecuentes

¿Qué lenguajes soporta Railpack?

Node, Python, Go, Rust, Ruby, PHP, Java (Maven/Gradle), Deno, Bun, Elixir, y un provider "static" para salida de site pre-buildeado. Nuevos providers llegan regularmente.

¿Dónde pongo un railpack.json?

En la raíz del repo (junto a package.json / pyproject.toml / etc.). Railpack lo lee antes de la detección de lenguaje y usa sus campos como overrides. Todo en el fichero es opcional.

¿Cómo seteo variables de entorno runtime?

Usa la UI de env-vars de Pier en el servicio — se inyectan al arrancar el contenedor. El bloque `env` de `railpack.json` es solo para variables de build-time.

¿Soporta paquetes privados (npm, PyPI, etc.)?

Sí — setea NPM_TOKEN / PIP_INDEX_URL / etc. como env vars de build-time en Pier. Railpack los pasa al contexto de build de BuildKit como secrets, no horneados en la imagen final.

¿Comportamiento del cache de build?

La cache de capa BuildKit vive en el host Pier. El primer build es completo; builds siguientes reusan capas install/build mientras lockfile y hash de source coinciden. Típicamente 80%+ cache hit en pushes incrementales.

¿Cómo disparo rebuilds?

Push al branch configurado y el webhook de Pier (si está cableado) dispara un rebuild. O dale al botón "Redeploy" en la UI del servicio — tira del commit último y rebuildea.

¿Puedo ver qué decidió Railpack?

Sí — el build log imprime el provider detectado, los comandos install/build/start y el plan LLB. Si la detección elige el stack incorrecto, sobrescribe en `railpack.json`.

¿Diferencia con "Deploy desde Dockerfile"?

Con Dockerfile tú escribes la receta de build. Con Railpack la receta es inferida. Si ya tienes un Dockerfile funcionando, usa el template Dockerfile — no hay razón para cambiar.

Servicios relacionados

Desplegar en tu VPS

Desplegar este servicio →