Pourquoi nous avons créé nos propres Cloud Native Buildpacks sur Ubuntu 26.04

Nodion construit les apps Git avec ses propres Cloud Native Buildpacks. Nous suivons la spécification Cloud Native Buildpacks pour detect, build et launch, mais la stack, les buildpacks de langage et les versions de runtime sont les nôtres. La stack s'appelle nodion-26 et repose sur Ubuntu 26.04 LTS. Ce ne sont pas les buildpacks de Paketo, Heroku ou Google. Voici pourquoi nous les avons créés et ce que cela change pour vos builds.

Les buildpacks en 30 secondes

Un buildpack transforme du code source en image de conteneur sans Dockerfile. Il détecte le langage, installe un runtime et les dépendances, fait le build de l'app et définit une commande de démarrage. Les Cloud Native Buildpacks sont le standard ouvert pour tout cela. Un builder regroupe les buildpacks, le lifecycle qui les exécute et les images de base pour le build et l'exécution. Vous découvrez le sujet ? Commencez par Les Cloud Native Buildpacks expliqués.

Pourquoi ne pas réutiliser un builder existant ?

Paketo, Heroku et Google publient tous des Cloud Native Buildpacks, et ce sont des projets solides. En adopter un aurait été plus simple.

Nous y avons renoncé parce que, pour une plateforme, le builder n'est pas un détail. Il détermine sur quel système d'exploitation tourne votre app, quelles versions de runtime existent, comment une version est choisie et ce qui se passe quand une version arrive en fin de vie. Ces décisions produit ont un effet sur chaque déploiement. Nous voulions les maîtriser, les consigner à un seul endroit et les appliquer de la même manière à tous les langages.

Ce que nous avons construit

Une seule stack sur Ubuntu 26.04 LTS

La stack nodion-26 comporte deux images. L'image de build contient les compilateurs et les fichiers d'en-tête. L'image d'exécution (run image) contient les bibliothèques client dont les apps ont souvent besoin, comme les clients Postgres et MySQL, ImageMagick et les certificats CA. Votre processus tourne sous un utilisateur non root.

Nous avons choisi Ubuntu 26.04 parce que c'est la version LTS la plus récente. Canonical l'a publiée en avril 2026 et annonce une maintenance de sécurité standard jusqu'en mai 2031 : la base sous votre app a donc de la marge avant la prochaine grande migration.

Douze buildpacks, une seule base de code

Il y a douze buildpacks : Node.js, sites statiques, Ruby, Python, PHP, Go, Rust, Elixir, Java et .NET, plus un pour les Procfiles et un pour les paquets Debian supplémentaires. Tous sont écrits en Go avec libcnb, la bibliothèque Go du projet Cloud Native Buildpacks, et vivent dans un seul module. Ils partagent une même bibliothèque pour la résolution des versions, les téléchargements et les logs : l'épinglage d'une version, un message d'erreur ou un contrôle de téléchargement fonctionnent donc de la même façon dans chaque langage.

Une détection qui connaît les apps polyglottes

Le builder essaie 14 groupes de haut en bas, et le premier groupe dont tous les fichiers requis sont présents l'emporte. Dans des projets concrets, l'ordre compte :

• Un frontend JavaScript statique est construit avec Node.js, puis servi par le buildpack des sites statiques.
• composer.json avec package.json donne PHP et Node.js dans un même build (Laravel avec Vite, par exemple).
• Gemfile avec package.json donne Ruby et Node.js (Rails avec un pipeline JS).
• Viennent ensuite les langages seuls, un serveur Node.js autonome, un site purement statique et enfin une app qui n'a qu'un Procfile.

Les paquets Debian supplémentaires sont une partie optionnelle de chaque groupe : n'importe quelle app peut donc en ajouter.

Notre propre pipeline de runtimes

Les runtimes disponibles sont définis dans une seule matrice de versions, dans notre dépôt. Un job horaire vérifie les dates de fin de vie et les nouvelles releases, applique la politique de support et ouvre une pull request qui met la matrice à jour. Une fois celle-ci mergée, chaque version de runtime manquante est construite et publiée, et les apps récupèrent les nouvelles versions lors de leur prochain build.

Ruby, Python, PHP et Erlang sont compilés depuis les sources sur notre image de build. Les autres runtimes sont reconditionnés à partir des binaires des projets d'origine. Quand un build télécharge un runtime, il vérifie le fichier avec son checksum publié avant de l'extraire.

Ce que vous y gagnez

Une politique de versions qui tient en un paragraphe

Nous conservons une branche de langage tant qu'elle n'est pas en fin de vie, et jusqu'à trois mois après. Demandez une version mineure et vous obtenez le dernier patch publié de cette version mineure. Une version plus ancienne que la plus ancienne branche publiée est refusée pour fin de vie, et une version plus récente que tout ce qui a déjà été construit est refusée comme pas encore disponible. Dans les deux cas, le build s'arrête avec un message clair au lieu d'utiliser discrètement une autre version.

Go et Rust font exception : la toolchain publiée la plus récente fait le build de l'app, et les valeurs plus anciennes dans go.mod ou rust-version compilent toujours.

Langage	Par défaut	Branches publiées (septembre 2026)
Node.js	24	22, 24, 25, 26
Python	3.13	3.10 à 3.14
PHP	8.3	8.2 à 8.5
Ruby	3.4	3.3, 3.4, 4.0
Go	1.26	Toolchain la plus récente (1.25 à 1.27)
Rust	1.96	Toolchain la plus récente (1.95 à 1.98)
Java	21	11, 17, 21, 25, 26
.NET	10	8, 9, 10
Elixir	1.20	1.15 à 1.20 (Erlang/OTP 26 à 29)

Les patchs suivent au fil de nos publications. La page de chaque langage explique comment fixer une version, par exemple avec .node-version ou .python-version.

Des options de personnalisation quand vous en avez besoin

• Procfile : définissez vos propres types de processus. Chaque type devient un processus distinct de l'app, et les valeurs par défaut du langage ne s'appliquent que s'il n'y a pas de Procfile.
• Paquets système supplémentaires : listez des paquets Debian dans project.toml (ou un Aptfile). Ils sont extraits dans l'image ; les scripts de mainteneur ne s'exécutent pas.
• Monorepos : faites pointer le paramètre Base directory vers le dossier de l'app.

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

Ce que nous n'avons pas changé

La spécification. Detect, build et launch fonctionnent comme sur n'importe quelle plateforme Cloud Native Buildpacks, et le résultat est une image OCI standard. Nodion utilise son propre builder par défaut, et vous pouvez en choisir un autre si vous préférez. Si votre dépôt contient déjà un Dockerfile, ou n'est pas un projet dans un langage pris en charge, utilisez plutôt le Dockerfile. Vous hésitez ? Lisez Dockerfile vs buildpacks.

Pour essayer, connectez un dépôt sous Applications → New, choisissez Buildpacks et vérifiez que votre app écoute sur PORT. Les autres détails se trouvent dans la documentation des buildpacks.