Votre application tourne sur un VPS, et jusqu'ici tout va bien. Puis vient le moment où chaque mise à jour devient une opération à risque : SSH, récupération du code, redémarrage du service, attente. Un pipeline CI/CD sur VPS remplace cette séquence par un chemin unique, testé, rejouable et tracé. À chaque git push, le code est vérifié, construit, puis publié par un script que personne ne tape à la main un vendredi soir. Voici une architecture de référence, les pièges qui coûtent du temps et les arbitrages de coût.
Ce qu'un pipeline sur VPS met explicitement à votre charge
Sur une plateforme managée, l'intégration continue est un service inclus : vous poussez, elle construit. Sur un VPS, vous héritez de la mécanique — ce qui rend le pipeline prévisible, à condition d'assumer ce que l'on reprend.
- Le runner vous appartient. Les builds consomment processeur et mémoire par pics, un profil de charge sans rapport avec le trafic des visiteurs.
- Les secrets sont chez vous. Clés de déploiement, jetons d'API, mots de passe de base : création, stockage, rotation et révocation deviennent votre procédure.
- Le disque se remplit. Artefacts, images de conteneurs et anciennes releases s'accumulent jusqu'au jour où un build échoue sur une partition pleine.
- Le retour arrière est votre script. Personne en amont ne restaurera votre version précédente : la commande doit exister avant le premier incident.
- La traçabilité est locale. Journaux de construction, historique des déploiements et version en production restent sur la machine, à vous de les conserver.
Une architecture de référence en quatre étages
Gardez les étages séparés : chacun devient alors remplaçable sans toucher aux autres.
1. Le dépôt Git et son déclencheur
Git reste la source de vérité. Le déclencheur est un événement : une poussée sur la branche principale, une étiquette de version, une fusion validée. Évitez de construire à chaque branche : un pipeline permanent noie les vrais échecs dans le bruit.
2. Le runner : là où le travail s'exécute
Le runner reçoit une tâche et l'exécute. Le choix structurant est son emplacement : sur le VPS applicatif ou sur une machine dédiée. La cohabitation suffit à une petite équipe ; la séparation éloigne les compilations du trafic.
3. La construction : produire un artefact, pas un checkout
Une construction saine ne laisse jamais une copie de travail atterrir en production. Elle produit un artefact — archive, dossier de release ou image de conteneur — étiqueté par le commit. La production le reçoit et n'exécute jamais un git pull à l'aveugle : vous savez ce qui tourne, et pouvez le reconstruire à l'identique.
4. Le déploiement : SSH et script idempotent
Le déploiement se fait par SSH, avec une clé dédiée et un script idempotent : le lancer une ou dix fois converge vers le même état. Il copie, active, vérifie, puis conserve ou revient en arrière.
Déployer sans coupure grâce aux releases atomiques
La technique est ancienne et reste le meilleur défaut : on n'écrase jamais l'application en place. Chaque déploiement reçoit son dossier daté, et un lien symbolique bascule d'un coup.
- Construire l'artefact et le déposer dans
/srv/monapp/releases/2026-11-07-1. - Installer les dépendances et exécuter les migrations dans ce dossier, hors ligne.
- Pointer le lien
currentvers la nouvelle release, en une opération atomique. - Recharger le service applicatif (PHP-FPM, unité systemd ou conteneur) sans arrêter le serveur web.
- Appeler une URL de santé et vérifier le code de réponse et la version annoncée.
- En cas d'échec, rebasculer le lien vers la release précédente et recharger.
- Conserver les trois à cinq dernières releases, supprimer les plus anciennes.
Ce schéma couvre la majorité des déploiements, sans rendre sûre une migration destructive. Découpez ces changements en trois temps : ajouter la colonne, déployer le code qui écrit dans les deux, retirer l'ancienne plus tard.
Secrets, comptes et permissions : les règles qui évitent l'incident
Un pipeline détient les clés de la production : il se traite comme un accès privilégié, pas comme un script de confort.
- Un compte de déploiement dédié, sans shell interactif si possible, et jamais
root. - Une clé SSH par pipeline, stockée chiffrée ou protégée par phrase de passe, révocable en une commande.
- Aucun secret dans Git, même dans un commit supprimé : l'historique se relit.
- Un fichier de variables d'environnement lisible par le seul compte de déploiement, par exemple
/etc/monapp/enven droits 600. - Un runner isolé si vos builds exécutent du code de contributeurs externes.
- Un calendrier de rotation des jetons, et une révocation immédiate au départ d'un collaborateur.
Un détail rattrape les équipes tard : les journaux de build. Les variables masquées se configurent mal, et un jeton affiché une fois est un jeton exposé. Relisez un journal complet avant d'en ouvrir l'accès.
Combien de VPS faut-il pour faire tourner un pipeline ?
Voici les emplacements réalistes, avec les cinq plans VPS NVMe d'Open Vista et leurs tarifs publiés. Chaque plan inclut une IPv4 dédiée, la bande passante illimitée, les sauvegardes automatiques, la protection DDoS, la supervision 24/7, le support 6 jours sur 7 et une livraison en moins de 15 minutes.
| Emplacement | Ce qu'il contient | Plan | USD/mois | DH HT/mois |
|---|---|---|---|---|
| Tout-en-un | Application, base de données et runner | VPS-4G Avancé — 2 vCPU, 4 Go, 80 Go NVMe | 39.99 | 378.22 |
| Runner dédié | Builds et tests, isolés du trafic | VPS-1G Démarrage — 1 vCPU, 1 Go, 30 Go NVMe | 9.99 | 94.48 |
| Hôte applicatif | Application, base et proxy inverse | VPS-2G Business — 1 vCPU, 2 Go, 40 Go NVMe | 19.99 | 189.06 |
| Staging et production | Deux environnements et le runner | VPS-5G Ultra — 3 vCPU, 5 Go, 100 Go NVMe | 49.99 | 472.80 |
Le calcul ne se fait pas sur le nombre de cœurs affiché : un build de trois minutes qui culmine à un demi-gigaoctet n'a pas besoin de la machine d'une compilation complète d'actifs. Commencez petit, mesurez la mémoire au pic, puis changez de plan, le passage à une configuration supérieure se faisant sans migration douloureuse. Caractéristiques sur la page des plans VPS, prix en dirhams selon la convention 1 USD ≈ 9.46 MAD sur la page des tarifs.
Retour arrière, supervision et sauvegardes
Un déploiement ne s'arrête pas à la fin du script. Trois signaux décident s'il faut garder la version : le code de réponse de la page de santé, le taux d'erreur dans les journaux pendant dix minutes, et le temps de réponse médian. Si l'un se dégrade, le retour arrière doit être une commande, pas une réunion. Gardez aussi la correspondance entre releases et commits.
Côté infrastructure, les plans VPS incluent les sauvegardes automatiques et la supervision 24/7, avec un SLA de 99,9 % sur l'infrastructure. Ce SLA couvre la disponibilité de la machine, pas l'exactitude de votre code : la distinction mérite d'être dite clairement à votre équipe.
FAQ : pipeline CI/CD sur VPS
Faut-il un serveur séparé pour le runner ?
Pas au démarrage. Sur un VPS de 2 à 4 Go, un runner cohabite avec l'application tant que les builds restent courts. Séparez-le dès qu'une compilation provoque des ralentissements ou des erreurs de mémoire sur l'hôte de production.
Un simple script SSH suffit-il pour déployer sans coupure ?
Oui : le basculement du lien symbolique est instantané et le rechargement prend quelques secondes. Les coupures viennent presque toujours des migrations de base ou d'un service redémarré sans file d'attente.
Où stocker les secrets du pipeline ?
Dans le coffre de votre outil d'intégration s'il en propose un, sinon dans un fichier de variables d'environnement à droits restreints, hors du dépôt Git. Dans les deux cas, un compte dédié et une clé révocable restent la base.
Comment revenir à la version précédente ?
En rebasculant le lien symbolique vers la release précédente, puis en rechargeant le service. C'est pour cela que l'on garde plusieurs releases sur le disque : sans elles, le retour arrière se fait à la main, sous pression.
Prochaine étape : un VPS prévisible pour vos déploiements
Un pipeline utile ne demande ni plateforme exotique ni gros budget : un dépôt, un runner, un script idempotent et une procédure de retour arrière. Le reste est affaire de discipline, et la discipline coûte moins cher que les incidents. Les plans VPS NVMe d'Open Vista sont livrés en moins de 15 minutes, avec accès root, IPv4 dédiée, sauvegardes automatiques et supervision 24/7 — de quoi faire tourner intégration continue et production sur une machine, ou sur deux.
Comparez les cinq configurations sur la page des plans VPS, puis vérifiez les prix en dirhams sur la page des tarifs. Si vous hésitez encore entre runner dédié et tout-en-un, décrivez-nous votre stack : l'arbitrage se joue sur la mémoire au pic, pas sur le nombre de vCPU affiché.