ssh -p 12345 monsite@nomduserveur.kinsta.com : cette simple commande, disponible dans le tableau de bord MyKinsta de chaque environnement, ouvre la voie à un déploiement automatisé sans passer par un plugin de transfert de fichiers installé côté WordPress. Kinsta expose un accès SSH standard sur chaque site hébergé, exactement comme un VPS classique, ce qui rend possible un pipeline GitLab CI qui pousse directement les fichiers du thème sans intermédiaire.
L’équipe concernée gérait jusque-là ses mises en production à la main, via un client SFTP, pour un thème à blocs personnalisé développé en interne. Chaque déploiement demandait de se souvenir des fichiers modifiés, avec le risque d’oublier une modification ou d’écraser un fichier récent par erreur. Automatiser ce déploiement via GitLab CI a supprimé cette part d’incertitude manuelle.
Récupérer les informations d’accès SSH depuis MyKinsta
Le tableau de bord MyKinsta affiche, pour chaque environnement (développement, recette, production), un onglet dédié aux informations SSH/SFTP : nom d’hôte, numéro de port spécifique à l’environnement, et nom d’utilisateur. Ce même accès permet aussi bien un client SFTP classique qu’une connexion SSH standard, ce qui ouvre la voie à des commandes comme rsync exécutées depuis un pipeline.
Créer une clé de déploiement dédiée
Plutôt que de réutiliser une clé SSH personnelle dans le pipeline, une paire de clés dédiée au déploiement automatisé a été générée spécifiquement pour ce projet. La clé publique s’ajoute dans l’onglet SSH de MyKinsta, la clé privée est stockée comme variable protégée dans GitLab CI, jamais visible dans les journaux d’exécution du pipeline.
ssh-keygen -t ed25519 -C "deploiement-gitlab-ci" -f cle_deploiement_kinsta -N ""
Dans GitLab, cette clé privée se déclare via Settings > CI/CD > Variables, en variable de type fichier, marquée protégée et masquée pour qu’elle ne s’affiche jamais dans les journaux du pipeline même en cas d’erreur de script.
Écrire le job de déploiement
Le job GitLab CI installe d’abord la clé privée dans un agent SSH, ajoute l’empreinte du serveur Kinsta aux hôtes connus, puis synchronise le dossier du thème via rsync, en excluant les fichiers qui n’ont pas leur place en production comme node_modules ou les fichiers de configuration locale.
deploiement_production:
stage: deploy
only:
- main
before_script:
- eval $(ssh-agent -s)
- echo "$CLE_DEPLOIEMENT_KINSTA" | tr -d '\r' | ssh-add -
- mkdir -p ~/.ssh
- ssh-keyscan -p 12345 nomduserveur.kinsta.com >> ~/.ssh/known_hosts
script:
- rsync -avz --delete
--exclude 'node_modules'
--exclude '.git'
-e "ssh -p 12345"
wp-content/themes/mon-theme/
monsite@nomduserveur.kinsta.com:public/wp-content/themes/mon-theme/
L’option --delete de rsync mérite une vigilance particulière : elle supprime côté serveur tout fichier absent de la version locale synchronisée, ce qui est souhaitable pour un dossier de thème entièrement versionné, mais dangereux si le dossier ciblé contient des fichiers générés directement en production (comme des médias uploadés) qui n’existent pas dans le dépôt Git.
Limiter les droits de la clé de déploiement
Kinsta ne propose pas nativement de restreindre une clé SSH à un seul répertoire du serveur, contrairement à certains hébergeurs qui offrent des comptes SFTP cloisonnés. La prudence a donc porté sur la portée du script lui-même : le job ne touche jamais qu’au dossier précis du thème, jamais à la racine du site ni aux dossiers d’extensions, pour limiter les conséquences d’une erreur de configuration du pipeline.
- Clé SSH dédiée, jamais réutilisée sur un autre projet
- Script rsync limité au dossier exact du thème concerné
- Exécution du job réservée à la branche
main, jamais sur une branche de fonctionnalité
Une automatisation qui touche à la production mérite toujours un périmètre plus restreint que ce que permettrait techniquement l’accès disponible : mieux vaut un script trop prudent qu’un script trop puissant.
En résumé
L’accès SSH standard de Kinsta suffit à construire un pipeline de déploiement fiable sans installer le moindre plugin de transfert côté WordPress. La combinaison d’une clé de déploiement dédiée, d’un script rsync limité au strict périmètre du thème, et d’une exécution réservée à la branche principale a permis à l’équipe de supprimer complètement les mises en production manuelles par SFTP, sans toucher à la gestion des sauvegardes propre à Kinsta, qui reste un sujet séparé.
