Déployez Docker sur Nodion

Déployez Docker étape par étape

1. Écoutez sur 0.0.0.0 et déclarez le port avec EXPOSE Nodion construit votre Dockerfile tel quel et lance le CMD ou l'ENTRYPOINT de l'image. Il ne définit pas PORT : votre serveur écoute sur toutes les interfaces, sur un port fixe, et EXPOSE indique au formulaire de création lequel. Les builds multi-stage fonctionnent ; c'est le dernier stage qui s'exécute. Dockerfile

   FROM python:3.13-slim
   WORKDIR /app
   COPY requirements.txt .
   RUN pip install --no-cache-dir -r requirements.txt
   COPY . .
   EXPOSE 8000
   CMD ["gunicorn", "app:app", "--bind", "0.0.0.0:8000"]

2. Créez l'app Dans le dashboard, créez une application depuis votre dépôt GitHub, GitLab, Bitbucket ou Gitea, et choisissez la branche et la région EU Central. Si le dépôt contient un Dockerfile, le formulaire présélectionne la stratégie Dockerfile et reprend le port de EXPOSE. Dans un monorepo, définissez le champ Base directory (le contexte de build) et le nom du Dockerfile.
3. Transmettez les valeurs de build sous forme de build args Les variables avec l'option Build dans l'onglet Environment arrivent dans le build comme build args Docker : déclarez-les donc avec ARG dans le stage qui les lit. Toutes les autres variables, ainsi que les bases de données rattachées comme DATABASE_URL, n'existent qu'une fois le conteneur lancé. Dockerfile

   FROM node:24-slim AS build
   ARG VITE_API_URL
   WORKDIR /app
   COPY . .
   RUN npm ci && npm run build

4. Exécutez les migrations une fois par déploiement Définissez votre commande de migration comme commande de release de l'app : elle s'exécute une fois par déploiement depuis la nouvelle image, avant le démarrage de la nouvelle version, et si elle échoue, le déploiement s'arrête tandis que la version en cours reste en ligne. Définissez-la avec le champ d'API release_command ; dans le dashboard, le champ n'apparaît pour l'instant dans les paramètres de l'app qu'une fois les environnements de preview activés. Lancer les migrations dans l'entrypoint ou la commande de démarrage fonctionne aussi, mais chaque instance les exécute alors à chaque démarrage.
5. Poussez pour déployer Chaque push sur la branche construit une nouvelle image à Francfort. Le trafic bascule vers elle dès que le processus web renvoie un code 2xx ou 3xx sur le chemin du health check (/ par défaut). Un HEALTHCHECK Docker dans l'image est ignoré.

Bon à savoir

• Pas de variable PORTSi votre serveur lit PORT, définissez cette variable vous-même, avec ENV PORT=8000 dans le Dockerfile ou comme variable dans l'onglet Environment, et gardez-la identique au port du processus web.
• Images préconstruitesSans passer par un build depuis Git, déployez une image issue de Docker Hub, du GitHub Container Registry, du registre Nodion ou d'un registre privé dont vous avez enregistré les identifiants dans Nodion. Les mêmes règles s'appliquent au port et au health check.
• USER, .dockerignore et le commitLe USER de l'image est respecté, un .dockerignore dans le contexte de build s'applique, et .git n'est jamais envoyé au build. Déclarez ARG NODION_GIT_SHA pour inscrire le hash du commit dans l'image.

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

• Dockerfile vs buildpacks : lequel choisir ? Les deux transforment votre code en image de conteneur. La différence, c'est qui écrit les étapes du build, et cela détermine le contrôle, la maintenance et les mises à jour de sécurité.
• Alternatives à Railway en Europe : 5 options comparées Conteneurs et bases de données facturés à l'usage, avec une entreprise ou une région dans l'UE : cinq alternatives à Railway comparées par facturation, bases de données et localisation.

Docker sur Nodion : questions et réponses