Du dépôt Git à la production : guide de déploiement Dockup

Passer d’un dépôt Git à la production demande plus que de connecter un remote et de lancer un déploiement. La plateforme doit connaître le service cible, la branche, la méthode de build, la commande de démarrage, le port d’écoute, l’environnement, le health gate et la procédure de récupération. Dockup rend ces choix explicites tout en prenant en charge les builds Nixpacks automatiques et les Dockerfiles gérés dans le dépôt.

Ce guide part d’un dépôt qui n’a encore jamais été déployé et se termine avec une URL vérifiée, un historique des déploiements, des logs et une commande de rollback testée.

Que faut-il vérifier avant le premier déploiement en production ?

Vérifiez que le dépôt peut être déployé sans état local non documenté. Un clone propre doit contenir tout ce qui est nécessaire pour installer les dépendances et démarrer l’application, à l’exception des secrets.

Utilisez cette checklist :

Vérification	Résultat attendu
Branche par défaut	La branche destinée à la production existe
Lockfile des dépendances	Il est commité pour garantir des installations reproductibles
Processus de démarrage	Il écoute sur le port configuré et sur 0.0.0.0
Route de health check	Elle renvoie un succès sans effets de bord externes
Migrations de base de données	Elles disposent d’un plan d’exécution sûr et explicite
Secrets	Ils sont stockés en dehors de Git
Fichiers persistants	Ils utilisent un volume, et non le système de fichiers du conteneur
Rollback	Le déploiement précédent peut être relancé

Installez la CLI et authentifiez-vous :

npm install -g dockup-cli
export DOCKUP_TOKEN="<TOKEN>"
dockup whoami --json

Listez les services existants avant d’en créer un :

dockup services --json

Cela évite les ressources en double et confirme la convention exacte utilisée pour le workspace et la cible.

Comment la commande Dockup create prend-elle en charge le déploiement Git ?

La commande habituelle du premier déploiement crée le service, le déploie, attend le résultat et lie le répertoire courant :

dockup create api \
  --repo https://github.com/acme/api \
  --project production \
  --branch main \
  --deploy \
  --wait \
  --link \
  --json

La cible obtenue est production/api. Le lien .dockup permet aux commandes suivantes de résoudre ce service lorsqu’elles sont exécutées dans le dépôt, mais la documentation de production doit tout de même consigner la cible complète.

Après une tentative de provisioning interrompue, listez les services et inspectez la cible exacte avant de relancer la création :

dockup services --json

Si production/api existe déjà, poursuivez en lisant son statut et son historique de déploiement. Vous éviterez ainsi de transformer un résultat réseau incertain en service dupliqué. Conservez les identifiants d’accès au dépôt en dehors du contrôle de version et de la sortie des commandes.

Comment Dockup choisit-il Nixpacks ou Dockerfile ?

Si le dépôt contient un Dockerfile, Dockup l’utilise. Sinon, Nixpacks détecte l’application et la build automatiquement. Cet ordre donne donc à la définition explicite du conteneur dans le dépôt un rôle d’autorité.

Nixpacks est un bon premier choix lorsque l’application suit les conventions courantes de son écosystème et ne nécessite pas de personnalisation au niveau du système d’exploitation. Un Dockerfile est utile lorsque vous avez besoin d’une image de base spécifique, de paquets système, d’un build multi-stage, d’un utilisateur runtime personnalisé ou de limites de copie précises.

Il n’est pas nécessaire d’ajouter un Dockerfile vide simplement pour « avoir l’air prêt pour la production ». Un Dockerfile incorrect peut être moins reproductible qu’un build automatique conventionnel. Utilisez le processus de décision décrit dans Nixpacks vs Dockerfile.

Inspectez le service après sa création :

dockup info production/api --json

La réponse inclut l’URL du dépôt, la branche, le type de déploiement, le port, les paramètres de build et de démarrage, les clés d’environnement, les domaines personnalisés et les données du dernier déploiement.

Si les commandes détectées nécessitent une surcharge, utilisez les paramètres documentés :

dockup set production/api \
  --build "npm ci && npm run build" \
  --start "npm start" \
  --port 3000 \
  --json

Les paramètres s’appliquent au prochain déploiement.

Comment configurer l’environnement et le health check de production ?

Ajoutez séparément les valeurs ordinaires et les secrets :

dockup env set NODE_ENV=production \
  -s production/api \
  --json

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

Les valeurs secrètes sont masquées lors de l’affichage de l’environnement. Elles peuvent être définies ou remplacées, mais la valeur enregistrée n’est pas renvoyée.

Les changements d’environnement nécessitent un nouveau déploiement, car le process en cours d’exécution ne peut pas recevoir rétroactivement un nouvel environnement. Le cycle de vie complet est expliqué dans les variables d’environnement et les secrets.

Configurez un health gate représentatif de l’état ready :

dockup health production/api \
  --path /healthz \
  --interval 5 \
  --timeout 3 \
  --retries 5 \
  --json

Dockup utilise un flow blue-green sans downtime et n’envoie du trafic vers le nouveau déploiement qu’une fois la readiness validée. Lorsqu’aucun chemin HTTP n’est configuré, le gate peut se replier sur la readiness du port TCP.

Une route de health check doit vérifier que le process applicatif est prêt à traiter les requêtes. Évitez de lui faire exécuter des vérifications destructrices ou des tests complets coûteux. Des vérifications approfondies des dépendances peuvent créer de fausses pannes lorsqu’un service facultatif est dégradé.

Comment déployer, suivre et vérifier la production ?

Déclenchez la release et attendez un état terminal :

dockup deploy production/api --wait --json

Le timeout par défaut est de 900 secondes. Le code de sortie 0 indique un succès. deploy_failed et deploy_timeout produisent des résultats non nuls : les scripts shell et les systèmes CI s’arrêtent donc correctement.

Pour suivre le build au format NDJSON :

dockup logs production/api --build -f --json

Le flux se termine en cas de succès ou d’échec. Si le build réussit mais que le conteneur plante, inspectez les logs runtime :

dockup logs production/api --json

Après une release réussie, vérifiez l’état de la plateforme et le comportement public :

dockup status production/api --json
dockup uptime production/api --hours 24 --json
dockup security production/api --json

Les probes d’uptime s’exécutent chaque minute et indiquent le temps de réponse moyen et p95. Le scan de sécurité vérifie les CVE de l’image et la configuration. Ajoutez un smoke test spécifique à l’application pour l’endpoint métier réel : la readiness de la plateforme est nécessaire, mais elle ne suffit pas.

La méthode détaillée pour consulter les logs est disponible dans le débogage des logs de build et runtime.

Comment introduire les déploiements automatiques et les previews ?

Effectuez la première release de production manuellement, en observant suffisamment chaque étape. Une fois le build, le health gate et la procédure de rollback maîtrisés, activez le déploiement sur push :

dockup auto-deploy production/api --on --json

Le déploiement automatique doit suivre une branche protégée et une politique de code review. Un push déclenche la production : les permissions du dépôt deviennent donc des permissions d’infrastructure.

Les previews de pull request et de branche fournissent des URLs et des environnements isolés :

dockup pr-preview production/api --on --json
dockup preview branch feature/login production/api --json

Dans un projet utilisant un réseau privé, les previews rejoignent le réseau du projet. Elles peuvent accéder à la même base de données de production via <slug>.internal, mais Dockup crée automatiquement un utilisateur de base de données en lecture seule pour la preview. Celle-ci peut consulter des données représentatives de la production sans les modifier.

Cela ne supprime pas les obligations en matière de confidentialité. L’accès aux previews doit rester limité, audité et utilisé uniquement lorsque la lecture des données de production est autorisée.

Comment effectuer un rollback après un mauvais déploiement ?

Conservez les éléments de preuve avant la récupération. Consultez les logs de build en cas d’échec du build et les logs runtime en cas de crash. Listez ensuite l’historique des déploiements :

dockup deployments production/api -n 20 --json

Sélectionnez un ID de déploiement dont le statut et l’horodatage sont connus, puis relancez-le :

dockup rollback <deploymentId> production/api --json

Un rollback doit être une action d’incident explicite. Consignez l’ID du déploiement en échec, l’ID de récupération sélectionné, la raison et la correction à apporter. Si une migration de base de données n’est pas rétrocompatible, le rollback de l’application seul peut ne pas rétablir la compatibilité ; la conception des migrations doit faire partie du plan de release.

Le guide du déploiement sans downtime explique le basculement du trafic, tandis que la référence de la CLI Dockup documente tous les flags des commandes.

Fiche de fin du premier déploiement

À la fin du workflow du dépôt Git à la production, consignez :

• La cible exacte project/service.
• Le dépôt et la branche de production.
• La méthode de build : Nixpacks ou Dockerfile.
• Les commandes de build et de démarrage lorsqu’elles sont surchargées.
• Le port d’écoute et le chemin du health check.
• L’ID du déploiement et son statut terminal.
• L’URL de production et le plan de domaine personnalisé.
• La vérification de l’uptime et de la sécurité.
• L’ID du déploiement à utiliser pour le rollback ou la règle de sélection.

Cette fiche transforme le deuxième déploiement en opération courante plutôt qu’en nouvel exercice de découverte.

Séparez l’état de l’application de l’image du conteneur

Le système de fichiers inscriptible à l’intérieur d’un conteneur de service doit être considéré comme remplaçable. Un nouveau déploiement crée une nouvelle version et un rollback relance une ancienne image ; les fichiers écrits uniquement dans l’ancien conteneur ne constituent donc pas une stratégie durable pour les données.

Utilisez des bases de données managées pour les données relationnelles, documentaires ou de cache, et attachez un volume pour les fichiers qui doivent persister entre les déploiements. Vérifiez les chemins de montage avant la première release de production. Un répertoire d’uploads conteneurisé qui n’a jamais été monté peut sembler fonctionner correctement jusqu’au déploiement suivant, qui supprimera les données.

Consultez les volumes persistants et les snapshots avant de déplacer des fichiers générés par les utilisateurs. Pour les données de base de données, utilisez le système de sauvegarde propre à la base plutôt que de considérer un snapshot à chaud du volume comme une sauvegarde cohérente au niveau transactionnel.

Estimez le premier mois sans inventer un coût fixe d’instance

Dockup mesure la consommation de CPU, de RAM et de disque chaque minute et soustrait l’utilisation du solde du plan. Le plan Free inclut un crédit de départ de 10 $ et jusqu’à trois déploiements ; le plan Pro recommandé coûte 20 $ par mois et inclut 20 $ de crédit d’utilisation.

Une fois que le service reçoit un trafic réel, consultez sa consommation de CPU, de RAM et de disque dans app.dockup.ai. Appuyez-vous sur la consommation observée par minute — et non sur un maximum estimé — pour décider si le service, la base de données ou le disque persistant doit être ajusté.

Vérifiez la propreté du deuxième déploiement

Après la première release, apportez une modification anodine validée par review, puis déployez-la. Vous vérifierez ainsi que le lien vers le dépôt, les hypothèses du build cache, le health gate, l’environnement et l’historique fonctionnent dans la durée, et pas uniquement lors du provisioning initial.

Gardez la cible explicite

Consignez la chaîne finale project/service.

Conservez l’URL de la release

Consignez l’URL de production à côté de l’ID du déploiement.

Confirmez le prochain déclencheur

Indiquez si les futures releases seront manuelles ou utiliseront l’option de déploiement sur push. Les permissions du dépôt, la protection des branches et les attentes liées à la production resteront ainsi alignées après le premier déploiement.

Commencez par un déploiement vérifiable

Choisissez un petit dépôt avec une commande de démarrage et une route de health check claires, puis documentez la cible exacte et l’ID de rollback après la première release réussie.

Commencez gratuitement sur app.dockup.ai. Le plan Free coûte 0 $ par mois, inclut 10 $ de crédit de départ et prend en charge un workspace, trois bases de données et trois déploiements.

FAQ

Dockup peut-il déployer un dépôt sans Dockerfile ?

Oui. Lorsqu’aucun Dockerfile n’est présent, Dockup utilise Nixpacks pour détecter et builder automatiquement l’application.

Que fait dockup create --link ?

Cette commande écrit un lien .dockup dans le répertoire courant afin que les commandes suivantes puissent résoudre la cible project/service associée.

Pourquoi le premier déploiement doit-il utiliser --wait ?

Cette option maintient la commande attachée jusqu’à ce que le déploiement atteigne un état de succès, d’échec ou de timeout, et renvoie un code de sortie qui représente fidèlement le résultat terminal.

Les changements de variables d’environnement s’appliquent-ils immédiatement ?

Non. Ils s’appliquent à un nouveau conteneur lors du prochain déploiement. Redéployez donc le service après avoir modifié la configuration d’environnement.

Comment Dockup effectue-t-il le rollback d’une application ?

Listez l’historique des déploiements, identifiez un ID de déploiement précédent connu, puis utilisez dockup rollback avec cet ID et la cible exacte du service.