nelnaa.fr

← Toutes les notes

infra · 2 juillet 2026 · 2 min de lecture

Déployer un site Next.js sur un VPS OVHcloud avec PM2 et GitHub Actions

Le setup complet que j'utilise pour elydox.fr : un push sur GitHub, et le site est en production deux minutes plus tard. Sans Vercel ni Docker, sans prise de tête.

C'est le setup que j'utilise pour elydox.fr. L'objectif : je pousse sur main, et deux minutes plus tard c'est en prod. Voici les pièces du puzzle.

L'architecture

  • VPS OVHcloud (Debian) : le serveur
  • PM2 : garde le process Next.js en vie et le relance en cas de crash
  • nginx : reverse proxy devant Next.js, gère le SSL
  • GitHub Actions : se connecte en SSH au VPS à chaque push et déploie

PM2 en deux commandes

npm install -g pm2
cd /var/www/elydox
pm2 start npm --name "elydox" -- start
pm2 save && pm2 startup

Le pm2 startup génère la commande systemd pour que tout redémarre après un reboot du VPS. À ne pas oublier. Je l'ai appris à mes dépens.

Le workflow GitHub Actions

Le cœur du système, dans .github/workflows/deploy.yml :

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USER }}
          key: ${{ secrets.VPS_SSH_KEY }}
          port: 2244
          script: |
            cd /var/www/elydox
            git fetch origin
            git reset --hard origin/main
            npm install --production
            npm run build
            pm2 reload elydox --update-env

Les identifiants sont dans GitHub Secrets (Settings → Secrets and variables → Actions), jamais dans le code.

Deux pièges rencontrés

git pull qui casse tout

Au début j'utilisais git pull dans le script. Dès qu'un fichier avait été modifié directement sur le VPS (même un package-lock.json régénéré), le pull partait en conflit et le déploiement échouait silencieusement. La solution : git fetch + git reset --hard origin/main. Le VPS est un miroir de GitHub, point. On ne modifie jamais rien directement dessus.

Le port SSH non standard

Par sécurité, mon SSH n'écoute pas sur le port 22. Il faut penser à le préciser dans le workflow (port: 2244), sinon l'action tourne dans le vide jusqu'au timeout sans message d'erreur clair.

Pourquoi pas Vercel ?

Vercel est excellent et gratuit pour ce genre de site. Mais mes données et celles de mes clients restent en France, sur une infra que je contrôle. C'est le positionnement d'Elydox, alors autant qu'il s'applique à moi-même. Et gérer son propre serveur, c'est comme ça qu'on apprend.


Des questions sur ce setup ? Écris-moi.

← Toutes les notes
Me contacter →