Déploiement automatique depuis GitHub, GitLab ou Bitbucket avec rollback instantané

Le système de déploiement automatique connecte vos dépôts GitHub, GitLab, Bitbucket, Gitea/Forgejo ou de tout serveur Git accessible en HTTPS à votre hébergement, en préparant une nouvelle version du code avant de l'activer au moyen d'un lien symbolique. Vous pouvez revenir rapidement à une version conservée. La continuité de l'application dépend aussi de ses migrations, de ses fichiers partagés et de ses scripts ; le changement de code ne restaure pas ces données.

Si votre dépôt contient du React, du Vue ou un autre frontend qui aboutit à des fichiers HTML, CSS et JavaScript, consultez aussi comment héberger un site statique connecté à une API externe.

Accédez à l'outil depuis l'espace client, dans Hébergement → sélectionnez votre service → Deploy+.

Connecter un dépôt

Cliquez sur Connecter un dépôt. L'ajout se fait en trois étapes dans la même carte ; tant qu'une étape n'est pas résolue, on ne peut pas passer à la suivante : les erreurs apparaissent donc là où elles se corrigent.

Étape 1 · Dépôt

• Fournisseur : GitHub, GitLab, Bitbucket, Gitea/Forgejo ou « Autre serveur Git ». GitLab et Gitea acceptent les installations auto-hébergées : il suffit que l'URL pointe vers votre serveur.
• URL du dépôt : l'adresse https:// du dépôt, la même que celle que vous utiliseriez pour le cloner. Les URL SSH (git@servidor:cuenta/repo.git) ne conviennent pas : le déploiement clone en HTTPS avec un token.
• Token d'accès : il est stocké chiffré et sert à accéder au dépôt et, le cas échéant, à consulter l'API du fournisseur et à gérer le webhook. Pour un dépôt public, vous pouvez le laisser vide. Le menu déroulant « Comment créer le jeton » indique, pour le fournisseur choisi, où le créer et quelles permissions exactes il lui faut.
• Vérifier l'accès : consulte l'API du fournisseur et répond avec le dépôt, s'il est public ou privé, la branche par défaut et la liste des branches. S'il manque une permission au token, c'est ici qu'il le dit, et non au milieu du premier déploiement.
• Branche déployée : elle se choisit dans le menu déroulant avec les branches lues dans le dépôt.

Permissions demandées par chaque fournisseur :

Avec Autre serveur Git, il n'y a pas d'API à consulter : l'accès n'est pas vérifié, les branches ne sont pas lues et le webhook ne peut pas se créer tout seul. Le déploiement à chaque push se fait en appelant l'URL manuelle depuis votre propre intégration. On vous demandera aussi l'utilisateur avec lequel votre serveur accepte l'authentification HTTPS (consultez l'utilisateur exigé par votre fournisseur).

Créez toujours le token avec la durée de validité la plus courte qui vous convienne, révoquez-le quand vous supprimez le déploiement et renouvelez-le avant qu'il n'expire, sans élargir ses permissions. Sur GitHub, n'utilisez pas de token classic avec la portée globale repo.

Étape 2 · Destination et projet

• Type de projet : choisissez Laravel, Symfony, WordPress, PHP/Composer, Frontend compilé, HTML statique ou Autre projet. Le profil propose une racine web, des fichiers partagés et un script adaptés, que vous pouvez vérifier avant d'enregistrer.
• Nom du dépôt : un identifiant pour le reconnaître dans la liste ; il est prérempli avec le nom du dépôt.
• Dossier de publication : public_html pour le domaine principal, subdominios/app pour un sous-domaine. Sous le champ s'affichent le chemin final complet et ce que sert ce dossier.
• Racine web dans le dépôt : le profil la configure à public pour Laravel et Symfony, dist pour un frontend compilé ou la racine pour les projets qui n'utilisent pas de sous-dossier public. Modifiez-la si votre build génère un autre répertoire, comme build ou out.
• Fichiers et dossiers partagés : un chemin par ligne ; ils sont conservés en dehors de chaque version et liés dans toutes.
• Versions conservées : combien de releases précédentes sont gardées pour revenir en arrière. 5 par défaut.

Étape 3 · Automatisation

• Déployer au push : si le fournisseur a une API et que le token peut gérer les webhooks, nous le créons nous-mêmes lors de la connexion du dépôt. Sinon, la fiche vous donne l'URL (et le secret, si vous demandez une signature) à coller dans la configuration des webhooks du fournisseur.
• Vérifier la signature de chaque notification : seules les notifications signées par le fournisseur sont acceptées. GitHub et Bitbucket signent en HMAC-SHA256, Gitea aussi, et GitLab envoie le secret dans l'en-tête X-Gitlab-Token.
• Programmer le scheduler de Laravel : cochée par défaut dans un projet Laravel. Une fois le premier déploiement réussi, nous ajoutons à vos tâches cron php artisan schedule:run chaque minute dans le current de l'application, avec le chemin absolu du PHP choisi pour votre compte. Nous l'expliquons dans Le scheduler de Laravel.
• Script de déploiement : vérifiez celui que propose le profil ou choisissez Compiler uniquement les assets avec Node, PHP avec Composer ou Pas de script. Vous pouvez aussi écrire vos propres commandes ; c'est le contenu de la zone de texte qui est enregistré.

L'étape se termine par un résumé de vos choix et le bouton Connecter un dépôt.

Lancer un déploiement

Quand vous cliquez sur Connecter un dépôt, le système vérifie l'accès SSH (en l'activant automatiquement si nécessaire), valide la configuration et enregistre le dépôt. Il apparaît alors dans la liste avec un bouton Déployer maintenant.

Cliquez sur Déployer maintenant pour le premier déploiement. Le chemin doit être vide : s'il contient un ancien site, le système vous demandera de le sauvegarder et de retirer ce contenu avant de continuer.

Pendant le déploiement, la carte de progression affiche les étapes l'une sous l'autre (connexion, clonage, fichiers partagés, script, activation et nettoyage), avec la durée de chacune et le total. La console est repliée derrière Voir la console : en cas d'échec, l'étape en erreur s'ouvre d'elle-même avec les dernières lignes de la sortie, une explication de ce qui s'est passé et les boutons pour réessayer ou corriger le token ou l'URL. Si l'erreur survient avant l'activation du nouveau code, la version précédente reste publiée. Examinez l'étape qui a échoué : les scripts peuvent avoir modifié des données partagées, et une erreur après l'activation oblige à vérifier quelle version sert le site.

Le détail du dépôt affiche aussi une URL de déploiement manuel pour les intégrations externes. Cette URL contient un secret capable de lancer des déploiements : ne la publiez pas, ne l'incluez ni dans des captures ni dans des journaux, et régénérez-la immédiatement si elle est exposée.

Scripts personnalisés

La plupart des projets doivent exécuter des commandes pendant le déploiement pour installer des dépendances ou compiler des assets. Ouvrez l'éditeur depuis le menu du dépôt (trois points) → Modifier le script.

Comment le script s'exécute

L'éditeur propose deux modes, et vous pouvez passer de l'un à l'autre à tout moment sans que le texte du script change :

• Une commande par ligne : le mode historique, celui que conservent tous les dépôts connectés avant l'existence de l'option. Chaque ligne s'exécute séparément, dans son propre shell et depuis le dossier de la nouvelle version : un cd ou un export n'atteint donc pas la ligne suivante. Si une commande échoue, les suivantes ne s'exécutent pas.
• Script Bash complet : le script entier s'exécute dans un seul shell Bash, de haut en bas, avec conditions, boucles, fonctions et variables qui persistent d'une ligne à l'autre. Il s'arrête à la première commande qui échoue, comme avec set -e, et le journal indique laquelle, telle qu'elle est écrite. Un échec au milieu d'un pipeline (comando | otro) ne l'arrête pas, sauf si vous commencez le script par set -o pipefail. À l'enregistrement, l'éditeur vérifie que Bash comprend le script.

En mode Bash, NVM se charge une fois et sert pour le reste du script :

composer install --no-dev --optimize-autoloader --no-interaction

if [[ "$HOSTSUAR_DEPLOY_TRIGGER" == "webhook" ]]; then
    php artisan migrate --force
fi

export NVM_DIR="$HOME/.nvm"
. "$NVM_DIR/nvm.sh"
npm ci --include=dev
npm run build

Un exit 0 termine le script plus tôt sans considérer le déploiement comme échoué. Une commande qui attend une réponse au clavier ne la reçoit pas : ajoutez l'option qui la rend non interactive, comme --no-interaction pour Composer.

Variables pour le script

Sous le script se trouvent deux interrupteurs indépendants. Ils fonctionnent dans les deux modes.

Informations du déploiement met ces variables à disposition du script. Il est activé dans les dépôts connectés depuis le 23 septembre 2026 ; dans les précédents, il reste désactivé jusqu'à ce que vous l'activiez.

Aucune ne contient de secrets : elles n'incluent ni le token Git ni le secret du webhook. Un rollback qui doit reconstruire une version supprimée exécute le script avec HOSTSUAR_DEPLOY_TRIGGER=rollback et le commit de cette version.

Variables du .env transmet les clés du .env partagé au script et à tout ce qu'il lance, comme un bash scripts/deploy.sh, Composer, npm ou Artisan. Le fichier n'est pas modifié et les variables n'existent que pendant le déploiement :

• Elles sont lues avec vlucas/phpdotenv, le même lecteur que celui de Laravel, avec ses règles de guillemets, de commentaires et d'interpolation ${VARIABLE}. Si Laravel n'accepterait pas le fichier, le déploiement s'arrête avant le script et le journal l'explique sans afficher son contenu.
• Une clé qui existe déjà dans l'environnement du compte, comme PATH ou HOME, conserve sa valeur, comme dans Laravel.
• Ne sont pas transmises les clés que Bash n'accepte pas comme variable (avec un point ou un tiret, ou des noms propres au shell comme IFS ou UID) ni celles qui commencent par HOSTSUAR_DEPLOY_. Le journal indique lesquelles ont été laissées de côté.
• Les valeurs passent par un fichier temporaire que seul votre compte peut lire et qui est supprimé à la fin, y compris si le déploiement échoue. Elles n'apparaissent jamais dans la ligne de commande. Si le processus est interrompu brutalement en cours de route, le fichier est supprimé lors d'un déploiement ultérieur avec cette option activée, au bout de deux heures.
• S'il n'y a pas de .env, le script s'exécute sans ces variables et le journal l'indique.

Tenez compte de deux effets avant de l'activer :

• Ce qu'affiche le script est enregistré dans l'historique. Deploy+ masque les valeurs dont les clés semblent secrètes (elles contiennent PASSWORD, SECRET, TOKEN ou KEY, entre autres) et les adresses avec utilisateur et mot de passe, comme mysql://usuario:clave@host, mais il ne peut pas toutes les reconnaître, et les valeurs de moins de 8 caractères ne sont pas masquées. N'affichez pas de secrets et n'activez pas set -x, qui montre chaque commande avec ses valeurs.
• Le framework voit aussi les variables. Avec Laravel, si APP_ENV arrive comme variable (du .env ou de votre propre compte) et que le dépôt contient un .env.production (ou le fichier qui correspond à sa valeur), pendant l'exécution du script Laravel lit ce fichier au lieu du .env, y compris dans php artisan config:cache. Mais il ne remplace pas les clés qui arrivent déjà comme variables : si le .env indique APP_DEBUG=true et le .env.production APP_DEBUG=false, c'est true qui est retenu. Le journal prévient quand il détecte ce fichier. Avec Symfony, les variables système ont priorité sur .env.local et .env.prod.local : si vous utilisez ces fichiers pour surcharger le .env, laissez cette option désactivée.

Exemples

Exemples pour des projets qui incluent leurs fichiers de verrouillage (composer.lock ou package-lock.json) et les scripts de compilation indiqués. npm ci --include=dev installe aussi les outils de build ; il exige que le fichier de verrouillage soit synchronisé. Vérifiez d'abord les versions de PHP et de Node dont le projet a besoin :

Laravel avec Composer et npm :

composer install --no-dev --optimize-autoloader
php artisan config:cache
php artisan route:cache
php artisan view:cache
export NVM_DIR="$HOME/.nvm" && . "$NVM_DIR/nvm.sh" && npm ci --include=dev
export NVM_DIR="$HOME/.nvm" && . "$NVM_DIR/nvm.sh" && npm run build

N'ajoutez pas php artisan queue:restart : le script s'exécute avant l'activation de la version, et Deploy+ redémarre déjà vos workers ensuite. Nous l'expliquons dans Workers et processus persistants.

WordPress avec npm :

export NVM_DIR="$HOME/.nvm" && . "$NVM_DIR/nvm.sh" && npm ci --include=dev
export NVM_DIR="$HOME/.nvm" && . "$NVM_DIR/nvm.sh" && npm run build

Projet PHP simple :

composer install --no-dev

Les scripts s'exécutent dans la nouvelle version avant son activation : un échec du script empêche donc d'activer ce nouveau code. Malgré tout, leurs opérations sur une base de données, des services externes ou des chemins partagés peuvent affecter le site publié et ne sont pas annulées automatiquement. L'éditeur n'enregistre pas un script qui utilise des commandes bloquées comme sudo, chmod 777, dd, mkfs, fdisk, shutdown, reboot ou halt : il indique la ligne pour que vous la retiriez. Il accepte en revanche pkill et kill, qui n'affectent que les processus de votre compte. Vous n'en avez pas besoin pour redémarrer les workers de files d'attente : php artisan queue:restart leur fait terminer proprement la tâche en cours avant de s'arrêter. Jusqu'au 23 septembre 2026, ces lignes étaient supprimées sans prévenir à l'enregistrement, ainsi que d'autres qui contenaient seulement ces lettres à l'intérieur d'un mot, comme git add. Si vous avez enregistré votre script avant cette date, ouvrez-le et vérifiez qu'il conserve toutes les lignes prévues.

Deploy+ vérifie Node.js avant d'exécuter ces commandes et l'installe automatiquement s'il manque. Si le projet exige une version précise, sélectionnez-la d'abord dans le gestionnaire de paquets.

Fichiers partagés et .env

Le fichier .env est conservé automatiquement d'un déploiement à l'autre. Pour partager des fichiers ou dossiers supplémentaires, ouvrez Fichiers partagés (menu → Fichiers partagés) et indiquez les chemins relatifs, un par ligne.

Par exemple :

storage/app
storage/logs
uploads

Les fichiers partagés sont conservés dans ~/deploy/nombre-repo/shared/ et liés automatiquement dans chaque version. Vous pouvez modifier le .env directement depuis le menu → Modifier le .env. Le fichier partagé est mis à jour immédiatement et, pour les applications Laravel, les caches sont vidés automatiquement. Pour un frontend compilé, les variables intégrées au JavaScript ne changent qu'avec un nouveau build : vous devez donc lancer ensuite un autre déploiement.

L'option de variables d'environnement de Deploy+ gère ce fichier .env ; ce n'est pas un magasin global de variables du serveur et elle n'exporte pas automatiquement ses valeurs vers tous les processus. Chaque application doit charger le fichier avec le mécanisme de son framework ou avec une bibliothèque équivalente. Laravel, par exemple, utilise vlucas/phpdotenv. Un PHP web ou une tâche cron peut lire les valeurs s'il démarre l'application ou son chargeur de configuration ; une commande indépendante qui ne charge pas le .env ne les recevra pas comme variables système. L'exception est le script de déploiement : avec l'interrupteur Variables du .env activé, ses commandes reçoivent les valeurs comme variables (voir la section Variables pour le script).

LiteSpeed et PHP Selector n'offrent pas, au sein du compte, de gestionnaire de secrets partagé entre le PHP web, cron et Deploy+. Les variables que l'administrateur du serveur peut fournir au PHP web ne sont pas pour autant transmises aux deux autres contextes. Deploy+ n'inclut pas non plus actuellement d'intégration native avec des gestionnaires externes comme 1Password : si l'application en utilise un, c'est à elle d'implémenter sa consultation et de fournir les valeurs à chaque processus.

Les variables sont chargées dans chaque processus et ne se transmettent pas d'elles-mêmes à d'autres applications. Cependant, toutes les applications d'un même compte cPanel s'exécutent avec le même utilisateur : un processus de ce compte pourrait lire le .env s'il connaît son emplacement. Le stocker en dehors de la racine web empêche de le télécharger en HTTP, mais ne crée pas de frontière de sécurité entre les applications du compte. Pour une isolation complète, il faut un service d'hébergement distinct, avec un autre utilisateur système.

Pour vérifier les trois contextes, vous pouvez d'abord utiliser une variable sans information secrète. Le test doit faire démarrer le même chargeur par le PHP web, le cron et la commande de déploiement ; inutile de modifier de vrais identifiants ou de redémarrer le serveur. Si un contexte ne charge pas le fichier, l'absence de la variable décrit ce processus, et non une perte du .env partagé.

Préparez le contenu persistant avant de le publier. Un chemin partagé existant l'emporte sur le fichier qui arrive dans le dépôt ; l'ajouter à la liste ne fusionne pas automatiquement les deux versions. N'incluez pas dans un dossier partagé du code que vous voulez mettre à jour à chaque déploiement. Évitez de partager node_modules si vous utilisez npm ci : cette commande supprime et reconstruit le dossier, ce qui pourrait affecter d'autres releases qui pointeraient vers lui. Gardez une sauvegarde avant de modifier cette configuration.

Le .env partagé affecte l'application active. Dans une installation Laravel existante, conservez son APP_KEY ; la changer ne fait pas partie d'un déploiement habituel. N'introduisez pas de secrets dans les variables qu'un frontend compile dans le JavaScript public. Avant de modifier le .env, gardez-en une copie privée : le rollback change le code publié, mais ne récupère pas une version antérieure de ce fichier.

Historique et rollback

L'Historique des déploiements s'ouvre depuis le menu du dépôt et apparaît dans sa propre fiche, sous la forme d'un tableau avec la date, le déclencheur (Manuel, Push, Rollback ou Programmé), le commit déployé avec son message et son auteur, la durée et l'état. Le filtre Tous / Échoués permet de ne voir que ce qui a échoué. Cliquez sur Voir le détail pour déplier les étapes avec leurs durées et la sortie complète de la console.

Pour faire un rollback vers une version précédente, repérez le déploiement dans l'historique et choisissez Revenir à cette version dans son menu ; une confirmation est demandée avant toute modification. Le système vérifie que la version existe, modifie le lien symbolique pour qu'il pointe vers elle et met à jour le répertoire. Quand la release est toujours disponible, il n'a pas besoin de recloner le code et le changement est généralement rapide. Vérifiez ensuite que les pages et opérations principales fonctionnent avec les données actuelles.

Si la version n'est plus sur le serveur parce que le nettoyage automatique l'a supprimée, le système la reconstruit : il clone le dépôt et demande ce commit précis à votre fournisseur Git. C'est plus long qu'un rollback normal, et il faut que le fournisseur permette de récupérer le commit et que les identifiants soient toujours valides. Le script configuré est aussi exécuté de nouveau : il doit rester compatible avec ce code et ses dépendances.

Revenir à une version toujours présente sur le serveur n'exécute pas le script. Les processus persistants de l'application passent en revanche à la version restaurée : Deploy+ les redémarre à la fin, comme après un déploiement, et le journal de ce retour en arrière indique l'état de chacun.

Le rollback ne restaure ni la base de données, ni le .env, ni les fichiers partagés. Prévoyez séparément la récupération d'une migration ou de données modifiées. Les versions conservées ne remplacent pas une sauvegarde.

Si un déploiement est en cours et que vous devez l'annuler, cliquez sur Annuler le déploiement. Attendez que l'état confirme l'annulation et vérifiez le site. La demande peut arriver alors qu'une opération est déjà en cours ; annuler ne défait pas ses modifications de données et ne remplace pas un rollback après l'activation.

Le scheduler de Laravel

Les tâches que Laravel programme dans routes/console.php ne s'exécutent que si quelque chose lance php artisan schedule:run chaque minute. Lorsque vous connectez un projet Laravel, Programmer le scheduler de Laravel est coché : une fois le premier déploiement réussi, nous ajoutons cette tâche à votre cron, et le journal de ce déploiement le confirme.

* * * * * /opt/alt/php84/usr/bin/php /home/tu_usuario/deploy/nombre-repo/current/artisan schedule:run >/dev/null 2>&1 # hostsuar-deploy-12

Elle utilise la version de PHP choisie pour votre compte au moment de sa programmation, et le numéro final identifie le dépôt. Comme elle passe par current, chaque exécution utilise la version publiée à ce moment-là : inutile d'y toucher à chaque déploiement. C'est une tâche à vous comme n'importe quelle autre : vous la voyez dans cPanel > Tâches Cron / Cron Jobs et vous pouvez la modifier ou la supprimer. Si vous changez ensuite la version de PHP du compte, la tâche garde la sienne : modifiez-la aussi à cet endroit.

Si votre cron contient déjà une tâche avec schedule:run, par exemple celle de l'installation précédente, nous n'en ajoutons pas d'autre : avec deux, chaque tâche programmée s'exécuterait deux fois. Le journal du déploiement vous indique laquelle il a trouvée et quelle commande mettre. S'il s'agit de celle de l'installation précédente, modifiez-la pour qu'elle pointe vers le current de Deploy+. Celles d'autres applications publiées avec Deploy+ sur le même compte ne comptent pas.

Si vous supprimez la configuration du dépôt, la tâche reste, tout comme le site publié.

Workers et processus persistants

Sur les plans Avanza, Max et Elastic, un worker de files d'attente, Horizon ou une commande personnalisée peuvent rester en fonctionnement en tant que processus persistants, depuis Outils > Processus. Pour une application publiée avec Deploy+, le dossier du processus est deploy/nombre-repo/current : à chaque démarrage, il entre dans current, qui pointe toujours vers la version active.

Un worker charge le code au démarrage et ne le relit plus. C'est pourquoi, dès que chaque déploiement se termine, Deploy+ redémarre les processus persistants qui travaillent sur cette application, ceux dont le dossier est son current ou un dossier à l'intérieur. Il le fait aussi lors d'un retour à une version précédente depuis l'historique. Chaque worker termine la tâche en cours et redémarre en une seconde avec le code publié.

Le journal du déploiement le détaille avec une ligne par processus, par exemple « Redémarré « Worker de commandes » : en service avec la nouvelle version ». Si l'un d'eux n'a pas pu redémarrer, la ligne l'indique et le déploiement reste considéré comme terminé, puisque la version est déjà publiée : redémarrez-le depuis Outils > Processus.

Si l'application a des processus, sa fiche dans Deploy+ les affiche dans le bloc Processus de cette application, avec leur état et ce qu'ils exécutent. Dans un projet Laravel sans worker, le menu du dépôt (la flèche à côté de Déployer maintenant) propose Ajouter un worker de files d'attente, qui ouvre la création dans Processus avec le dossier de l'application et la version de PHP de votre compte déjà renseignés. En connectant un nouveau projet Laravel, vous pouvez cocher Garder un worker de files d'attente en marche : il est créé une fois le premier déploiement réussi, avec la file default, et le journal de ce déploiement le confirme ou explique pourquoi il n'a pas pu être créé, par exemple s'il ne reste plus de processus libres dans le plan.

Inutile d'ajouter php artisan queue:restart ou horizon:terminate au script : le script s'exécute dans la nouvelle version avant son activation, et un redémarrage lancé à ce moment-là relancerait le worker sur la version précédente.

Si vous n'avez pas de processus persistants et que vous traitez la file depuis le scheduler, chaque exécution démarre avec le code publié à ce moment-là et il n'y a rien à redémarrer.

Version de PHP

La version de PHP d'un site publié avec Deploy+ ne se change pas depuis la section PHP de l'espace client, car chaque déploiement remplace le dossier publié. Fixez-la dans le .htaccess de la racine web de votre dépôt ou utilisez la version par défaut du compte. Nous l'expliquons dans Version de PHP d'un site publié avec Deploy+.

Fonctionnement de l'outil de déploiement

Le système crée une structure dans ~/deploy/nombre-repo/ avec trois répertoires principaux : releases/ contient chaque version déployée avec un horodatage, current est un lien symbolique vers la version active, et shared/ contient les fichiers partagés comme .env et storage/. Votre répertoire web (public_html ou un autre) pointe vers current, qui pointe à son tour vers la version active dans releases/.

Quand vous lancez un déploiement, un nouveau dossier est créé dans releases/, le code est cloné, les scripts sont exécutés et, quand tout est prêt, current est mis à jour pour pointer vers la nouvelle version. Le changement du lien est rapide, mais il ne garantit pas à lui seul que toutes les requêtes, tous les processus ou changements de schéma soient compatibles pendant la publication. Le rollback fonctionne de la même façon : il fait simplement pointer current vers une version précédente qui existe déjà.

Le clonage se fait en profondeur 1 : chaque version reçoit les fichiers du dernier commit de la branche, pas l'historique du dépôt. Dans un dépôt de plusieurs années, l'historique pèse bien plus que le code lui-même : le déploiement est donc nettement plus rapide et chaque version occupe moins d'espace sur votre compte. Si votre script de déploiement a besoin de l'historique (par exemple git describe ou git rev-list --count pour générer un numéro de version), il ne le trouvera pas. S'il vous suffit d'identifier le commit, utilisez $HOSTSUAR_DEPLOY_COMMIT ou $HOSTSUAR_DEPLOY_COMMIT_SHORT ; si vous avez besoin d'un numéro de version, enregistrez-le dans un fichier depuis votre système d'intégration continue ou calculez-le autrement.

Résolution des problèmes

Le compte n'a pas d'accès SSH : l'outil essaie de l'activer automatiquement. Si le serveur refuse la clé même après sa réinstallation, relancez le déploiement et contactez l'assistance avec le journal ; l'outil utilise une clé gérée et ne dépend pas du mot de passe de cPanel. Un déploiement est déjà en cours : il ne peut y avoir qu'un déploiement actif par dépôt ; attendez qu'il se termine ou annulez-le. Les scripts personnalisés échouent : consultez le journal du déploiement pour identifier la commande qui a échoué ; en mode Bash, la dernière ligne indique la commande exacte sur laquelle il s'est arrêté. Si un script écrit pour Bash échoue en mode une commande par ligne (un cd ou un export qui n'atteint pas la ligne suivante, un if réparti sur plusieurs lignes), passez en mode Script Bash complet. Un échec avant l'activation empêche de publier le nouveau code ; vérifiez aussi les éventuelles modifications des données partagées. Le webhook ne se déclenche pas : vérifiez dans la configuration des webhooks du fournisseur (sur GitHub, Settings → Webhooks) qu'il est bien créé et consultez les livraisons récentes. Si la fiche du dépôt indique « Webhook en attente », utilisez Installer ; si elle indique « Webhook manuel », copiez l'URL qui apparaît dans le détail et collez-la vous-même chez le fournisseur. Le fournisseur refuse le token au clonage : chaque plateforme le dit à sa façon (« HTTP Basic: Access denied » sur GitLab, une 403 sur GitHub, « Invalid or expired token » sur Bitbucket). Le journal du déploiement traduit ces messages et indique quelle permission manque ou si le token a expiré.