Déployez Python sur Nodion

Déployez Python étape par étape

1. Commitez un seul fichier de dépendances Nodion choisit l'installeur d'après le premier fichier qu'il trouve : poetry.lock (Poetry), Pipfile.lock (Pipenv), requirements.txt (pip), puis un pyproject.toml seul, installé avec pip install . (ou avec Poetry s'il contient une section [tool.poetry]). Un uv.lock est ignoré, et un Pipfile sans son lockfile n'installe rien.
2. Fixez la version de Python Nodion lit .python-version, puis runtime.txt, puis requires-python dans pyproject.toml ; sans aucun d'eux, vous obtenez la 3.13. Une plage comme requires-python = ">=3.10" se résout vers la dernière version publiée, actuellement la 3.15 : fixez donc la version avec laquelle vous testez. .python-version

   3.13

3. Vérifiez la commande de démarrage par défaut Nodion examine vos dépendances dans cet ordre : Django (avec manage.py) démarre avec Gunicorn, FastAPI ou Starlette avec Uvicorn, Flask avec Gunicorn. Le serveur n'est pas ajouté à votre place : listez-le dans vos dépendances. Sans framework, Nodion exécute python app.py ou python main.py, et ce script doit écouter sur 0.0.0.0 et sur le PORT défini par Nodion.
4. Démarrez tout le reste avec un Procfile Une ligne web: remplace la commande par défaut. Sans Django, FastAPI, Flask, app.py ni main.py, le Procfile doit définir un processus, web: ou worker: ; sinon, le build s'arrête avec une erreur qui indique ce qui manque. Une ligne release: s'exécute une fois par build avant le démarrage de la nouvelle version : c'est là que vont les migrations. Procfile

   web: gunicorn myapp.wsgi --bind 0.0.0.0:$PORT
   release: alembic upgrade head

5. Créez l'app et faites un push Créez une application depuis votre dépôt GitHub, GitLab, Bitbucket ou Gitea dans la région EU Central. Les variables lues par votre build doivent avoir l'option Build cochée dans l'onglet Environment ; toutes les autres, ainsi que les bases de données rattachées comme DATABASE_URL, n'existent qu'à l'exécution. Ensuite, chaque push construit une nouvelle release.

Bon à savoir

• Workers et autres types de processusUne ligne worker: ne démarre rien à elle seule : ajoutez dans l'onglet Processes un processus du même nom, sans port. Gardez à côté une ligne web: explicite, car sans elle la première entrée du Procfile autre que release: devient la commande par défaut. Une app composée uniquement de workers, comme un bot, règle plutôt web sur 0 instance.
• La détection lit aussi les lockfilesNodion cherche Django, FastAPI et Flask dans requirements.txt, Pipfile, pyproject.toml, poetry.lock et Pipfile.lock. Les lockfiles listent aussi les dépendances indirectes : une bibliothèque qui dépend de FastAPI, comme Gradio, peut donc déclencher la commande par défaut de FastAPI. Une ligne web: lève toute ambiguïté.
• Projets uvLe lockfile d'uv n'est pas lu. Exportez vos versions verrouillées dans un requirements.txt, par exemple avec uv export --no-emit-project -o requirements.txt, et commitez-le ; sinon, Nodion installe à partir de pyproject.toml sans lockfile.

Ce que Nodion gère pour vous

• Déploiements sans interruption Faites un push sur votre branche : Nodion construit une nouvelle release. Le trafic bascule lorsque les nouvelles instances réussissent leur health check ; si la release échoue, celle en cours reste active. Les apps avec un volume local redémarrent, car le disque appartient à une seule instance.
• Bases de données à côté de l'app PostgreSQL, pgvector, MySQL, Valkey et ClickHouse managés, dans la même région. Les bases de données rattachées arrivent sous forme de DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Previews par pull request Activez les previews, et les pull requests de votre dépôt obtiennent leur propre app, avec sa propre URL et des bases de données neuves et vides, créées automatiquement ou à la main. Les pull requests issues de forks ou de bots sont ignorées.
• Workers, cron jobs et mise à l'échelle Exécutez les workers comme processus supplémentaires de la même app, planifiez des tâches dans l'onglet Cron et mettez chaque processus à l'échelle jusqu'à 16 instances.
• Étape de release Avec les buildpacks, une ligne release: du Procfile s'exécute à chaque nouveau build. Les apps Dockerfile, ainsi que les redéploiements ou les rollbacks vers une image antérieure, utilisent une commande de release définie sur l'app elle-même, qui prime aussi sur la ligne du Procfile. Sur les sites statiques, l'étape de release s'exécute dans une image qui ne contient que les fichiers générés par le build.
• Logs et métriques Logs de build, de release et d'exécution, ainsi que les métriques CPU, mémoire, disque et réseau de chaque instance, dans le dashboard.
• Domaines et HTTPS Un nom d'hôte par défaut avec HTTPS dès le premier déploiement, et des certificats automatiques pour vos propres domaines.

Pour aller plus loin

• Pourquoi nous avons créé nos buildpacks sur Ubuntu 26.04 Nos buildpacks suivent la spécification Cloud Native Buildpacks, mais la stack, les buildpacks de langage et les versions de runtime sont les nôtres. Voici pourquoi.
• Les Cloud Native Buildpacks expliqués Les buildpacks transforment votre code source en image de conteneur sans Dockerfile. Ce qu'ils sont et comment ils fonctionnent.

Python sur Nodion : questions et réponses