Migration complète : VPS IONOS → GitLab Pages

Ce billet documente une migration complète : sortie d’un VPS IONOS, suppression du déploiement SSH via GitHub Actions, et bascule vers un workflow 100% GitLab natif.

L’objectif n’était pas uniquement économique. Il s’agissait surtout d’aligner l’architecture avec le besoin réel : un site statique généré par Astro n’a pas besoin d’une machine Linux complète exposée sur Internet.

Cette migration s’inscrit dans la même logique que le reste de mon infrastructure : supprimer les couches inutiles, réduire la surface d’attaque, et simplifier la maintenance.

1. Audit initial : étape indispensable

Avant toute migration vers un hébergement statique, vérifier :

Aucun backend Node / Python actif
Aucune base de données
Aucune API côté serveur
Aucune logique d’authentification serveur
Build purement statique

Un site qui dépend d’un backend ne survivra pas à une migration vers GitLab Pages. L’audit est donc critique.

ssh user@ip-du-vps

ps aux | grep node
systemctl list-units --type=service --state=running

Dans mon cas, le VPS servait uniquement à héberger les fichiers générés par Astro. Aucun processus applicatif actif. Migration possible.

2. Pourquoi quitter le VPS ?

Avec VPS

Maintenance OS
Mises à jour sécurité
Configuration firewall
Gestion clés SSH
Certificat SSL à surveiller
Surface d’attaque permanente

Avec GitLab Pages

Aucun serveur à maintenir
CDN intégré
SSL automatique
CI/CD natif
Rollback via Git

La question n’est pas “est-ce que ça fonctionne ?” mais “est-ce que cette couche est nécessaire ?”.

3. Migration du dépôt vers GitLab

Deux options possibles :

# méthode manuelle
git remote remove origin
git remote add origin git@gitlab.com:username/project.git
git push -u origin main

L’import GitHub intégré à GitLab permet aussi de conserver l’historique sans manipulation locale.

4. Adapter Astro à GitLab Pages

GitLab Pages sert le contenu depuis le dossier public/.

{
"scripts": {
  "build": "astro build && mv dist public"
}
}

export default defineConfig({
site: 'https://username.gitlab.io',
base: '/nom-du-projet/',
output: 'static'
});

Le paramètre base est essentiel si le projet n’est pas publié à la racine.

5. Pipeline GitLab CI/CD

Création du fichier .gitlab-ci.yml.

image: node:20-alpine

cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
  - node_modules/

stages:
- build
- deploy

build_site:
stage: build
script:
  - npm ci
  - npm run build
artifacts:
  paths:
    - public

pages:
stage: deploy
script:
  - echo "Deploy"
artifacts:
  paths:
    - public
only:
  - main

Plus de SSH, plus de clés à gérer, plus d’accès distant à un serveur. Le déploiement devient purement déclaratif.

6. DNS et validation

dig A mondomaine.fr
dig TXT _gitlab-pages-verification-code.mondomaine.fr

Une fois le domaine validé, GitLab génère automatiquement un certificat Let’s Encrypt.

7. Hardening

/*
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Content-Security-Policy: default-src 'self';

Hébergement statique ≠ absence de sécurité. Les headers HTTP restent fondamentaux.

8. Tests Lighthouse (optionnel mais pertinent)

test_lighthouse:
stage: test
script:
  - npm install -g @lhci/cli
  - lhci autorun --collect.staticDistDir=./public

Intégrer Lighthouse au pipeline permet de détecter une régression performance avant mise en production.

Conclusion

Cette migration supprime une couche d’infrastructure inutile.

Moins de maintenance
Surface d’attaque réduite
CI/CD plus propre
Architecture alignée avec le besoin réel

Le bon design n’est pas celui qui ajoute des briques, mais celui qui retire celles qui ne sont pas nécessaires.