Pier incluye Railpack — el constructor open-source de Railway y sucesor de Nixpacks. Empuja código a Git, Pier detecta el lenguaje, compila con BuildKit y ejecuta la imagen resultante. Soporta 24+ lenguajes y frameworks listos para usar.
Node, Bun, Deno, Python, Go, Rust, PHP, Java, Ruby, Elixir, además de sitios estáticos Vite, Astro y Create React App como ciudadanos de primera. La detección es por archivo marcador (package.json, go.mod, Cargo.toml, requirements.txt, …), así que un repo nuevo normalmente no necesita configuración.
Railpack se construye sobre el grafo paralelo de BuildKit en vez de Dockerfiles por capas, así las imágenes Node se reducen ~38% y las Python ~77% frente a Nixpacks. Pulls más rápidos, menos disco, superficie de ataque menor.
Railway migró a Railpack en marzo de 2025 tras años ejecutando Nixpacks en más de 14M de builds de usuario. Desarrollo activo; Nixpacks está en modo mantenimiento. Pier integra Railpack directamente, así que usas el mismo builder que sostiene la producción de Railway.
Pier auto-detecta el comando de inicio y el puerto expuesto, pero puedes sobreescribirlos en el formulario de Deploy. Para control más profundo deja un railpack.json en la raíz del repo — Railpack lo detecta automáticamente sin necesidad de pegamento del lado de Pier.
Elige la nueva tarjeta junto a Dockerfile / Docker Image / Docker Compose. El formulario abre con un campo de URL de Git.
Los repos públicos funcionan directamente; los privados usan el mismo flujo de deploy-key o GitHub App que las otras fuentes Git.
Deja ambos vacíos para la autodetección de Railpack. El formulario muestra pistas bajo cada campo cuando importa.
Pier clona, entrega el árbol de trabajo a railpack build, luego ejecuta la imagen resultante como cualquier otro servicio — etiquetas Traefik, auto-SSL y subdominio generado incluidos.
Railpack es el sucesor activo — Railway migró en marzo de 2025 tras ejecutar Nixpacks en más de 14M de builds. Nixpacks sigue funcionando pero solo recibe bug fixes. Railpack produce imágenes más pequeñas y un grafo de build más rápido gracias a su LLB nativo de BuildKit.
Sí — tanto el CLI railpack como el contenedor moby/buildkit distribuyen builds linux/arm64. install.sh elige la arquitectura correcta automáticamente; el flujo de cara al usuario es idéntico a x86_64.
Al menos 4 GB de RAM (8 GB si construyes proyectos Rust) y 40+ GB libres de disco para la caché de BuildKit. Los VPS más pequeños que funcionan bien para deploys Dockerfile / Docker Image no son adecuados para Auto-build — la UI muestra un aviso fuerte cuando la RAM del host está por debajo de 4 GB.
Sí — Configuración → Auto-build (Railpack) expone el slot de builds paralelos, o pon PIER_RAILPACK_MAX_PARALLEL_BUILDS en el unit de systemd. El default es 1, lo que mantiene un host de 4 GB seguro incluso cuando varios usuarios despliegan a la vez.
Un comando instala Pier en cualquier VPS Ubuntu o Debian.
curl -fsSL https://pier.sh/install | sudo bash