Buildpacks et auto-détection
Comment la plateforme construit votre image à partir de votre code. Langages supportés, versions, override.
La plateforme construit votre image OCI à partir de votre code source via les Cloud Native Buildpacks. Pour les apps standard (Python/Django, Node, Ruby, Go), la détection automatique fonctionne sans Dockerfile. Pour les apps avec dépendances système particulières ou stack moins courante, ajoutez un Dockerfile à la racine — la plateforme l'utilisera en priorité sur le buildpack auto-détecté.
Détection automatique
Selon les fichiers présents à la racine du repo, le buildpack approprié est sélectionné.
| Fichier détecté | Buildpack appliqué |
|---|---|
| requirements.txt, Pipfile, pyproject.toml | Python |
| package.json | Node.js |
| Gemfile | Ruby |
| composer.json | PHP |
| go.mod | Go |
| Cargo.toml | Rust |
| pom.xml, build.gradle | Java |
| mix.exs | Elixir |
| *.csproj, *.fsproj | .NET |
| Dockerfile | Build OCI direct (sans buildpack) |
Langages supportés et versions
| Langage | Versions supportées | Versions LTS recommandées |
|---|---|---|
| Python | 3.10 → 3.13 | 3.12 |
| Node.js | 18 → 22 | 20 LTS, 22 LTS |
| Ruby | 3.1 → 3.3 | 3.3 |
| PHP | 8.1 → 8.4 | 8.3 |
| Go | 1.21 → 1.23 | 1.23 |
| Rust | stable, 1.75+ | stable |
| Java | 11, 17, 21 | 21 LTS |
| Elixir | 1.15+ | 1.16, 1.17 |
| .NET | 6, 8 | 8 LTS |
Pour fixer une version précise, ajoutez un fichier .python-version, .nvmrc, .ruby-version, .go-version, etc., ou la déclarez dans votre fichier de configuration habituel (package.json engines, Pipfile python_version, etc.).
Override du buildpack
Si la détection automatique ne convient pas, forcez un buildpack précis dans paas.toml :
buildpack = "paketo/python"
Cloud Native Buildpacks
Nous utilisons les Cloud Native Buildpacks (CNB), un standard ouvert maintenu par la CNCF. Cela vous donne :
- Reproductibilité : mêmes inputs, même image, partout
- Cache de couches intelligent, partagé entre les builds
- Sécurité : SBOM (Software Bill of Materials) généré automatiquement, signé
- Portabilité : si vous voulez partir, vos buildpacks fonctionnent ailleurs (CircleCI, GitHub Actions, autres PaaS)
Dockerfile
Si vous avez un Dockerfile, nous l'utilisons à la place du buildpack. C'est utile pour les cas où vous avez besoin d'un contrôle total : binaires natifs, dépendances système exotiques, runtime non standard.
Le Dockerfile reste votre dernier recours, pas le défaut. Les buildpacks sont plus rapides à builder, plus sécurisés à maintenir, et nous savons les faire évoluer pour vous (mise à jour OS, patches sécurité). Avec un Dockerfile, vous reprenez la responsabilité.