# Déployer un thème à blocs sur Kinsta via GitLab CI, sans plugin SFTP

> Kinsta expose un accès SSH standard sur chaque environnement : voici comment l'exploiter pour automatiser un déploiement par GitLab CI sans plugin de transfert.

- Auteur : WordPress Développement
- Publié le : 2022-01-13
- Mis à jour le : 2022-01-13
- Catégorie : Outils & workflow
- URL : https://www.wpmoderne.fr/outils/deployer-theme-blocs-kinsta-gitlab-ci-ssh/

## L’essentiel

- Kinsta fournit un accès SSH classique, exploitable comme n'importe quel serveur
- Une clé de déploiement dédiée limite les droits au strict nécessaire
- rsync via SSH remplace avantageusement un plugin de transfert de fichiers

`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.

> L'essentiel à retenir : Kinsta fournit un accès SSH classique, exploitable comme n'importe quel serveur ; Une clé de déploiement dédiée limite les droits au strict nécessaire ; rsync via SSH remplace avantageusement un plugin de transfert de fichiers

## É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é.