ADR-002 : Héberger les services sur un seul VPS
Statut
Section titled “Statut”Accepté
- Date : 01/07/2026
- Auteur : Corentin Talour
Cet ADR a été rédigé a posteriori afin de documenter une décision
Contexte et problème
Section titled “Contexte et problème”La plateforme comprend plusieurs services, notamment Caddy, Docker, Penpot, Uptime Kuma et la documentation.
Ces services peuvent être hébergés sur un VPS unique ou répartis sur plusieurs serveurs. L’architecture retenue doit rester adaptée à la taille actuelle du projet, à son trafic, au budget disponible et aux capacités d’exploitation de l’équipe.
À ce stade, la plateforme ne nécessite pas de haute disponibilité et sa charge peut être supportée par un seul VPS correctement dimensionné.
Facteurs de décision
Section titled “Facteurs de décision”Les principaux critères pris en compte sont :
- le coût mensuel de l’hébergement
- la simplicité du déploiement et de la maintenance
- le faible volume de trafic attendu
- les ressources nécessaires aux applications
- le temps disponible pour administrer l’infrastructure
- l’absence actuelle de besoin de haute disponibilité
- la possibilité de reconstruire le serveur avec Ansible
Options considérées
Section titled “Options considérées”Option 1 : Héberger tous les services sur un seul VPS (choisi)
Section titled “Option 1 : Héberger tous les services sur un seul VPS (choisi)”Installer les composants d’infrastructure et les applications sur un même serveur.
Les services conteneurisés restent isolés avec Docker et Docker Compose. Caddy constitue le point d’entrée HTTP et HTTPS de la plateforme.
Cette solution réduit les coûts et simplifie l’exploitation, mais crée un point unique de défaillance.
Option 2 : Répartir les services sur plusieurs VPS
Section titled “Option 2 : Répartir les services sur plusieurs VPS”Séparer les différentes couches ou applications sur plusieurs serveurs, par exemple :
- un VPS pour le reverse proxy
- un VPS pour les applications
- un VPS pour les bases de données
- un VPS pour la supervision
Cette solution améliore l’isolation et permet de dimensionner chaque serveur indépendamment. Elle augmente cependant les coûts et la complexité du réseau, des déploiements, de la supervision et des sauvegardes.
Décision
Section titled “Décision”Tous les services de la plateforme sont hébergés sur un VPS unique.
Cette architecture est retenue parce qu’elle répond aux besoins actuels du projet tout en limitant les coûts et la charge d’administration.
Ansible doit permettre de reconstruire la configuration du serveur en cas d’incident. Les données persistantes des applications doivent faire l’objet d’une stratégie de sauvegarde distincte, car elles ne peuvent pas être recréées uniquement à partir du dépôt Ansible.
Cette décision ne vise pas à fournir de haute disponibilité. Une panne du VPS peut rendre indisponible l’ensemble de la plateforme.
Conséquences
Section titled “Conséquences”Positives
Section titled “Positives”- le coût d’hébergement est limité à un seul VPS
- l’architecture réseau reste simple
- le déploiement est centralisé
- la supervision et la maintenance nécessitent moins de ressources
- les échanges entre les services restent locaux au serveur
- Caddy peut centraliser facilement les accès HTTP et HTTPS
- l’infrastructure peut être reconstruite avec un seul inventaire Ansible
Négatives
Section titled “Négatives”- le VPS constitue un point unique de défaillance
- une panne du serveur affecte tous les services
- une maintenance ou un redémarrage peut provoquer une indisponibilité générale
- les applications partagent les mêmes ressources processeur, mémoire, stockage et réseau
- une application consommant trop de ressources peut affecter les autres
- la compromission du serveur peut exposer l’ensemble des services
- le stockage local constitue un risque si les données ne sont pas sauvegardées sur un emplacement externe
- la montée en charge est limitée par la capacité maximale du VPS