Por qué hemos creado nuestros propios Cloud Native Buildpacks sobre Ubuntu 26.04

Nodion construye las apps de Git con sus propios Cloud Native Buildpacks. Seguimos la especificación de Cloud Native Buildpacks para detect, build y launch, pero el stack, los buildpacks de cada lenguaje y las versiones de runtime son nuestros. El stack se llama nodion-26 y se basa en Ubuntu 26.04 LTS. No son los buildpacks de Paketo, Heroku ni Google. Te contamos por qué los hemos creado y qué significa eso para tus builds.

Buildpacks en 30 segundos

Un buildpack convierte el código fuente en una imagen de contenedor sin Dockerfile. Detecta el lenguaje, instala un runtime y las dependencias, hace la build de la app y define un comando de arranque. Los Cloud Native Buildpacks son el estándar abierto para todo esto. Un builder reúne los buildpacks, el lifecycle que los ejecuta y las imágenes base para la build y la ejecución. ¿Es la primera vez que oyes hablar del tema? Empieza por Cloud Native Buildpacks: qué son y cómo funcionan.

¿Por qué no reutilizar un builder existente?

Paketo, Heroku y Google publican Cloud Native Buildpacks, y son proyectos sólidos. Usar uno de ellos habría sido un atajo.

Decidimos no hacerlo porque, para una plataforma, el builder no es un detalle. Determina en qué sistema operativo se ejecuta tu app, qué versiones de runtime existen, cómo se elige una versión y qué pasa cuando una versión llega al final de su vida útil. Son decisiones de producto que nuestros usuarios notan en cada despliegue. Queríamos tenerlas en nuestras manos, documentadas en un único sitio e idénticas en todos los lenguajes.

Qué hemos construido

Un solo stack sobre Ubuntu 26.04 LTS

El stack nodion-26 tiene dos imágenes. La imagen de build lleva los compiladores y las cabeceras. La imagen de runtime lleva las librerías cliente que las apps suelen necesitar, como los clientes de Postgres y MySQL, ImageMagick y los certificados de CA. Tu proceso se ejecuta con un usuario sin privilegios de root.

Elegimos Ubuntu 26.04 porque es la versión LTS más reciente. Canonical la publicó en abril de 2026 e indica mantenimiento de seguridad estándar hasta mayo de 2031, así que la base sobre la que corre tu app tiene mucho recorrido por delante antes de la próxima gran migración.

Doce buildpacks, una sola base de código

Hay doce buildpacks: Node.js, sitios estáticos, Ruby, Python, PHP, Go, Rust, Elixir, Java y .NET, más uno para Procfiles y otro para paquetes Debian adicionales. Todos están escritos en Go sobre libcnb, la librería de Go del proyecto Cloud Native Buildpacks, y forman parte de un único módulo. Comparten una sola librería para la resolución de versiones, las descargas y los logs, así que la fijación de versiones, los mensajes de error y las comprobaciones de descarga funcionan igual en todos los lenguajes.

Una detección que entiende las apps políglotas

El builder prueba 14 grupos de arriba abajo, y gana el primer grupo que tenga presentes todos sus archivos obligatorios. En proyectos reales, el orden importa:

• Un frontend estático de JavaScript se construye con Node.js y luego lo sirve el buildpack de sitios estáticos.
• composer.json junto con package.json recibe PHP y Node.js en una sola build (por ejemplo, Laravel con Vite).
• Gemfile junto con package.json recibe Ruby y Node.js (Rails con una pipeline de JS).
• Después vienen los lenguajes individuales, un servidor Node.js independiente, un sitio estático puro y, por último, una app que solo tiene un Procfile.

Los paquetes Debian adicionales son una parte opcional de cada grupo, así que cualquier app puede añadirlos.

Nuestra propia pipeline de runtimes

Una única matriz de versiones en nuestro repositorio define qué runtimes hay. Un job que se ejecuta cada hora revisa las fechas de fin de vida y las nuevas versiones, aplica la política de soporte y abre una pull request que actualiza la matriz. Tras el merge, se compila y se publica cada versión de runtime que falte, y las apps la reciben en su siguiente build.

Ruby, Python, PHP y Erlang se compilan desde el código fuente sobre nuestra imagen de build. Los demás runtimes se reempaquetan a partir de los binarios upstream. Cuando una build descarga un runtime, contrasta el archivo con el checksum publicado antes de extraerlo.

Qué obtienes

Una política de versiones que cabe en un párrafo

Mantenemos cada línea de versión de un lenguaje mientras está vigente y hasta tres meses después de que llegue al fin de su vida útil. Si pides una versión minor, recibes el último parche publicado de esa versión. Una versión anterior a la línea publicada más antigua se rechaza por haber llegado al fin de vida; una versión más nueva que todo lo compilado hasta ahora se rechaza porque todavía no está disponible. En ambos casos, la build se detiene con un mensaje claro en lugar de usar otra versión sin avisar.

Go y Rust son la excepción: la app se compila con la toolchain más reciente publicada, y los proyectos que indican versiones anteriores en go.mod o rust-version siguen compilando.

Lenguaje	Versión por defecto	Líneas publicadas (septiembre de 2026)
Node.js	24	22, 24, 25, 26
Python	3.13	de 3.10 a 3.14
PHP	8.3	de 8.2 a 8.5
Ruby	3.4	3.3, 3.4, 4.0
Go	1.26	Toolchain más reciente (de 1.25 a 1.27)
Rust	1.96	Toolchain más reciente (de 1.95 a 1.98)
Java	21	11, 17, 21, 25, 26
.NET	10	8, 9, 10
Elixir	1.20	de 1.15 a 1.20 (Erlang/OTP de 26 a 29)

Las versiones de parche se actualizan a medida que las publicamos. La página de cada lenguaje explica cómo fijar una versión, por ejemplo con .node-version o .python-version.

Opciones para casos especiales

• Procfile: define tus propios tipos de proceso. Cada tipo se convierte en un proceso propio de la app, y los valores por defecto del lenguaje solo se aplican cuando no hay Procfile.
• Paquetes de sistema adicionales: enumera paquetes Debian en project.toml (o en un Aptfile). Se extraen en la imagen; los scripts del mantenedor no se ejecutan.
• Monorepos: configura Base directory para que apunte a la carpeta de la app.

[com.nodion.buildpacks.deb-packages]
install = ["ffmpeg", "pandoc"]

Lo que no hemos cambiado

La especificación. Detect, build y launch funcionan igual que en cualquier plataforma de Cloud Native Buildpacks, y el resultado es una imagen OCI estándar. Nodion usa su propio builder por defecto, y puedes elegir otro builder si lo prefieres. Si tu repositorio ya tiene un Dockerfile, o no es un proyecto en un lenguaje compatible, usa el Dockerfile. ¿No tienes claro qué encaja mejor? Lee Dockerfile vs buildpacks: ¿cuál deberías usar?.

Para probarlo, conecta un repositorio en Applications → New, elige Buildpacks y asegúrate de que tu app escuche en PORT. Todo lo demás está en la documentación de buildpacks.