Perché abbiamo creato i nostri Cloud Native Buildpacks su Ubuntu 26.04

Nodion fa la build delle app Git con Cloud Native Buildpacks propri. Seguiamo la specifica Cloud Native Buildpacks per detect, build e launch, ma lo stack, i buildpack dei linguaggi e le versioni dei runtime sono nostri. Lo stack si chiama nodion-26 ed è basato su Ubuntu 26.04 LTS. Non sono i buildpack di Paketo, Heroku o Google. Ecco perché li abbiamo costruiti e cosa significa per le tue build.

I buildpack in 30 secondi

Un buildpack trasforma il codice sorgente in un'immagine container senza Dockerfile. Riconosce il linguaggio, installa un runtime e le dipendenze, fa la build dell'app e imposta un comando di avvio. I Cloud Native Buildpacks sono lo standard aperto per tutto questo. Un builder raccoglie i buildpack, il lifecycle che li esegue e le immagini di base per la build e il runtime. Se non conosci ancora l'argomento, parti da Cloud Native Buildpacks: cosa sono e come funzionano.

Perché non riutilizzare un builder esistente?

Paketo, Heroku e Google pubblicano tutti dei Cloud Native Buildpacks, e sono progetti solidi. Prenderne uno sarebbe stata la scorciatoia.

Abbiamo deciso di non farlo perché, per una piattaforma, il builder non è un dettaglio. Decide su quale sistema operativo gira la tua app, quali versioni dei runtime esistono, come viene scelta una versione e cosa succede quando una versione arriva a fine vita. Sono decisioni di prodotto che i nostri utenti sentono a ogni deploy. Volevamo averle nelle nostre mani, scritte in un unico posto e identiche per tutti i linguaggi.

Cosa abbiamo costruito

Un solo stack su Ubuntu 26.04 LTS

Lo stack nodion-26 ha due immagini. L'immagine di build contiene compilatori e header. L'immagine di runtime contiene le librerie client che servono spesso alle app, come i client Postgres e MySQL, ImageMagick e i certificati CA. Il tuo processo gira come utente non root.

Abbiamo scelto Ubuntu 26.04 perché è la release LTS più recente. Canonical l'ha pubblicata ad aprile 2026 e indica la manutenzione di sicurezza standard fino a maggio 2031. La base su cui gira la tua app durerà quindi a lungo prima del prossimo grande aggiornamento.

Dodici buildpack, un'unica base di codice

I buildpack sono dodici: Node.js, siti statici, Ruby, Python, PHP, Go, Rust, Elixir, Java e .NET, più uno per i Procfile e uno per i pacchetti Debian aggiuntivi. Sono tutti scritti in Go su libcnb, la libreria Go del progetto Cloud Native Buildpacks, e vivono in un unico modulo. Condividono una sola libreria per la risoluzione delle versioni, i download e il logging, quindi un pin di versione, un messaggio di errore o un controllo sui download funziona allo stesso modo in ogni linguaggio.

Un rilevamento che conosce le app poliglotte

Il builder prova 14 gruppi dall'alto verso il basso, e vince il primo gruppo di cui sono presenti tutti i file richiesti. Nei progetti reali l'ordine conta:

• Un frontend JavaScript statico viene costruito con Node.js e poi servito dal buildpack per i siti statici.
• composer.json insieme a package.json riceve PHP e Node.js in un'unica build (per esempio Laravel con Vite).
• Gemfile insieme a package.json riceve Ruby e Node.js (Rails con una pipeline JS).
• Poi i singoli linguaggi, un server Node.js standalone, un sito statico puro e infine un'app con il solo Procfile.

I pacchetti Debian aggiuntivi sono una parte opzionale di ogni gruppo, quindi qualsiasi app può aggiungerli.

La nostra pipeline dei runtime

Quali runtime esistono lo definisce un'unica matrice di versioni nel nostro repository. Un job orario controlla le date di fine vita e le nuove release, applica la policy di supporto e apre una pull request che aggiorna la matrice. Dopo il merge, ogni versione di runtime mancante viene compilata e pubblicata, e le app la ricevono alla build successiva.

Ruby, Python, PHP ed Erlang vengono compilati dal sorgente sulla nostra immagine di build. Gli altri runtime vengono reimpacchettati dai binari upstream. Quando una build scarica un runtime, confronta il file con il checksum pubblicato prima di estrarlo.

Cosa ottieni

Una policy delle versioni spiegata in un paragrafo

Manteniamo una linea di un linguaggio finché non è a fine vita, e fino a tre mesi dopo. Chiedi una versione minor e ottieni l'ultima patch pubblicata di quella minor. Una versione precedente alla linea pubblicata più vecchia fallisce come versione a fine vita, e una versione più recente di tutto ciò che abbiamo già compilato fallisce come versione non ancora disponibile. In entrambi i casi la build si ferma con un messaggio chiaro invece di usare in silenzio una versione diversa.

Go e Rust sono l'eccezione: l'app viene compilata con la toolchain più recente pubblicata, e il codice che indica versioni precedenti in go.mod o rust-version continua a compilare.

Linguaggio	Versione predefinita	Linee pubblicate (settembre 2026)
Node.js	24	22, 24, 25, 26
Python	3.13	da 3.10 a 3.14
PHP	8.3	da 8.2 a 8.5
Ruby	3.4	3.3, 3.4, 4.0
Go	1.26	Toolchain più recente (da 1.25 a 1.27)
Rust	1.96	Toolchain più recente (da 1.95 a 1.98)
Java	21	11, 17, 21, 25, 26
.NET	10	8, 9, 10
Elixir	1.20	da 1.15 a 1.20 (Erlang/OTP da 26 a 29)

Le patch si aggiornano man mano che le pubblichiamo. La pagina di ogni linguaggio spiega come fissare una versione, per esempio con .node-version o .python-version.

Opzioni per le esigenze particolari

• Procfile: definisci i tuoi tipi di processo. Ogni tipo diventa un processo a sé sull'app, e le impostazioni predefinite del linguaggio valgono solo quando non c'è un Procfile.
• Pacchetti di sistema aggiuntivi: elenca i pacchetti Debian in project.toml (o in un Aptfile). Vengono estratti nell'immagine; gli script di manutenzione non vengono eseguiti.
• Monorepo: imposta la base directory sulla cartella dell'app.

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

Cosa non abbiamo cambiato

La specifica. Detect, build e launch funzionano come su qualsiasi piattaforma Cloud Native Buildpacks, e il risultato è una normale immagine OCI. Nodion usa il proprio builder per impostazione predefinita, ma puoi sceglierne un altro. Se il tuo repository ha già un Dockerfile o non è un progetto in un linguaggio supportato, usa il Dockerfile. Non sai cosa scegliere? Leggi Dockerfile vs buildpack: quale usare.

Per provarlo, collega un repository in Applications → New, scegli Buildpacks e assicurati che la tua app sia in ascolto su PORT. Trovi tutti i dettagli in Buildpack.