Déployer sur son VPS avec GitHub Actions

Ce guide s'appuie sur la documentation de GitHub, relue le 14 octobre 2026 : utiliser des secrets et la syntaxe des workflows. L'exemple déploie une application Docker Compose dont le code est déjà cloné sur le serveur, dans ~/app.

Les étapes, dans l'ordre :

1. Créer une clé réservée au déploiement.
2. Ajouter sa clé publique au serveur.
3. Relever la clé du serveur.
4. Ranger les secrets dans le dépôt.
5. Écrire le workflow.
6. Essayer.

1. Créer une clé réservée au déploiement

Sur votre ordinateur, créez une paire de clés à part, sans phrase de passe puisque le workflow l'utilise sans vous :

ssh-keygen -t ed25519 -f deploiement -N "" -C "github-actions"

Vous obtenez deploiement, la clé privée, et deploiement.pub, la clé publique. Ne réutilisez jamais votre clé personnelle : une clé dédiée se retire seule le jour où le dépôt change de mains.

2. Ajouter la clé publique au serveur

Ajoutez le contenu de deploiement.pub sur une nouvelle ligne de ~/.ssh/authorized_keys, sur le compte qui déploie ; la marche à suivre est dans Ajouter une clé SSH sur un serveur Linux.

Pour limiter ce que la clé permet, la page de manuel de sshd décrit des options à placer en tête de la ligne. restrict coupe le transfert de ports, d'agent et de fenêtres, ainsi que l'ouverture d'un terminal ; command="..." force une commande unique quelle que soit celle demandée. Avec une commande forcée, le workflow ne peut lancer que votre script de déploiement.

3. Relever la clé du serveur

Le workflow doit reconnaître le serveur, sans quoi SSH demande une confirmation que personne ne donnera. Depuis votre ordinateur :

ssh-keyscan -t ed25519 adresse-du-serveur

La commande rend la clé publique d'hôte du serveur. Avant de lui faire confiance, affichez son empreinte avec ssh-keyscan -t ed25519 adresse-du-serveur | ssh-keygen -lf - et comparez-la à celle que vous avez acceptée lors de votre première connexion : c'est ce contrôle qui protège contre un faux serveur.

4. Ranger les secrets dans le dépôt

Sur GitHub, ouvrez le dépôt, puis Settings, Secrets and variables, Actions, onglet Secrets, et New repository secret. Créez trois secrets :

Supprimez ensuite le fichier deploiement de votre ordinateur, ou rangez-le dans votre gestionnaire de mots de passe : il n'a pas à traîner sur un disque.

5. Écrire le workflow

Créez le fichier .github/workflows/deployer.yml dans le dépôt :

name: Déployer
on:
  push:
    branches: [main]
concurrency:
  group: deploiement
  cancel-in-progress: false
jobs:
  deployer:
    runs-on: ubuntu-latest
    steps:
      - name: Préparer SSH
        env:
          SSH_PRIVATE_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
          SSH_KNOWN_HOSTS: ${{ secrets.SSH_KNOWN_HOSTS }}
        run: |
          mkdir -p ~/.ssh
          printf '%s\n' "$SSH_PRIVATE_KEY" > ~/.ssh/id_ed25519
          printf '%s\n' "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts
          chmod 600 ~/.ssh/id_ed25519
      - name: Mettre à jour le serveur
        env:
          SSH_HOST: ${{ secrets.SSH_HOST }}
        run: |
          ssh "$SSH_HOST" 'cd ~/app && git pull && docker compose up -d --build'

Le bloc concurrency empêche deux déploiements de se chevaucher. Les secrets passent par des variables d'environnement, comme le conseille GitHub : sur une ligne de commande, ils pourraient être visibles des autres processus de la machine.

6. Essayer

Envoyez un commit sur main, puis suivez l'exécution dans l'onglet Actions du dépôt. En cas d'échec, le journal de l'étape montre l'erreur de SSH ou de la commande distante.

Sur un VPS Hubspace

Le port 22 est ouvert depuis Internet, ce dont les machines de GitHub ont besoin pour joindre le serveur. Le compte à utiliser est admin, qui lance Docker sans sudo ; la connexion se fait par clé seulement, ce qui convient au workflow. fail2ban bloque une heure une adresse qui échoue cinq fois en dix minutes : un secret mal recopié peut donc faire bloquer temporairement les serveurs de GitHub. Les serveurs VPS décrivent ce qui est livré.

Questions fréquentes