Un VPS à 9,99 $ par mois peut porter cinq sites vitrines et une boutique sans difficulté. La limite n'est presque jamais la machine : ce sont les décisions du premier jour — comment les domaines arrivent, où vivent les bases, qui sauvegarde quoi. Voici comment héberger plusieurs sites sur un VPS sans que le troisième casse le premier.
Pourquoi mutualiser plusieurs sites sur un seul VPS
Chaque plan VPS NVMe inclut une IPv4 dédiée, la bande passante illimitée, l'accès root, un panneau de gestion, les sauvegardes automatiques, un pare-feu avec protection DDoS, la supervision 24/7, le support six jours sur sept et un SLA de 99,9 % sur l'infrastructure. Payer cinq serveurs pour cinq sites à faible trafic, c'est réserver cinq fois la même capacité.
Une adresse unique suffit : grâce au SNI, nginx présente le bon certificat selon le nom demandé, et plusieurs domaines cohabitent sur la même IPv4.
Ce que la mutualisation fait bien
- Portfolio d'agence. Cinq ou six sites de clients, même socle, un seul endroit à mettre à jour.
- Vitrine et boutique légère. Trafic irrégulier, pointes courtes, base de quelques centaines de mégaoctets.
- Recette et refonte. Un clone à côté du site en production, fermé aux moteurs de recherche par une authentification ou une balise
noindex.
Ce qu'elle ne fait pas
Un serveur partagé n'isole pas d'une fuite de mémoire : un site qui sature le processeur ralentit les autres, et il n'isole pas juridiquement si un client exige une machine dédiée. Il ne pardonne pas non plus l'improvisation : trois sites installés à la main dans /var/www produisent une plateforme que plus personne n'ose mettre à jour.
Vhosts nginx ou conteneurs : quelle isolation pour vos sites
Un vhost par site
Chaque site reçoit son bloc server, sa racine, ses journaux et, s'il tourne en PHP, son propre pool PHP-FPM avec un utilisateur système distinct. C'est l'approche la plus légère : aucune couche supplémentaire, un diagnostic direct dans les journaux, une empreinte minimale. En contrepartie, tous les sites partagent la même version de PHP ; une montée de version majeure se prépare, elle ne s'improvise pas.
Un conteneur par site
Chaque site embarque son environnement : l'ancienne version de PHP pour le site de 2019, la version courante pour le nouveau, Node pour l'application métier. Les plafonds se posent conteneur par conteneur, un redémarrage ne touche qu'un site, et une image reconstruite rejoue la même configuration. Le prix à payer : un démon Docker, une couche réseau à comprendre et des gigaoctets d'images sur le NVMe.
| Critère | Vhost nginx | Conteneur par site |
|---|---|---|
| Mémoire | Minimale, un seul PHP-FPM | Une image et un runtime par site |
| Versions de runtime | Une seule, partagée | Une par site, sans conflit |
| Incident sur un site | Tout le monde subit | Plafonds et redémarrage ciblé |
| Mise à jour | Fichiers remplacés sur place | Image reconstruite, retour arrière immédiat |
| Quand la choisir | Trois à cinq sites simples | Sites hétérogènes, clients distincts |
La base de données partagée : le vrai point de rupture
Une instance unique reste défendable pour cinq sites : PostgreSQL comme MariaDB gèrent plusieurs schémas. Ce qui casse, c'est le compte d'administration recopié dans tous les fichiers de configuration. Une injection SQL sur le site le plus ancien, et l'attaquant lit les tables du client le plus récent. Quatre règles suffisent :
- Un utilisateur par site, limité à son propre schéma.
- Un schéma par site, nommé sans ambiguïté, pour que l'export reste ciblé.
- Des exports séparés, sinon restaurer un site fait reculer tous les autres.
- Une version applicative compatible : deux CMS qui réclament des versions majeures différentes cohabitent mal.
TLS et DNS : automatiser pour chaque domaine
Un certificat oublié reste la panne la plus évitable du métier, et elle devient mécanique avec huit domaines. La séquence : le DNS pointe vers l'IPv4 du serveur, le vhost répond en HTTP, puis l'outil de certification demande le certificat pour ce nom.
- Un renouvellement vérifié.
systemctl list-timersdonne la prochaine exécution. HTTP-01 suffit pour un domaine par site ; un wildcard exige DNS-01. - Attention au proxy. Derrière un CDN en mode proxy, le certificat d'origine doit rester valide pour chaque nom, sinon le visiteur reçoit une erreur 525 alors que le site fonctionne en local.
Après chaque ajout, curl -sI https://exemple.ma doit renvoyer 200 ou 301, et openssl s_client -servername exemple.ma doit présenter le bon nom.
Sauvegardes et supervision : une vue par site
Les sauvegardes automatiques de chaque plan couvrent la panne de la machine : disque qui lâche, hyperviseur en défaut, erreur de manipulation. Elles ne remplacent pas un export applicatif cohérent : une copie brute prise pendant une écriture peut être inutilisable. La bonne unité reste le site :
- Un export par site et par nuit, base et fichiers, avec une rotation claire.
- Une copie hors du serveur, sinon la sauvegarde disparaît avec ce qu'elle protège.
- Une restauration testée au moins une fois par site : une archive jamais relue reste une hypothèse.
La supervision 24/7 et le SLA de 99,9 % portent sur l'infrastructure. Ce qui tourne dans vos sites reste votre responsabilité : ajoutez une sonde par domaine, qui vérifie le code de réponse et le contenu.
Dimensionner : quel plan pour combien de sites
Les cinq offres, aux prix publics en dollars et en dirhams HT, avec l'usage réaliste de chacune. Estimations pour des vitrines ou des boutiques de faible trafic, cache activé :
| Offre | vCPU | RAM | NVMe | USD/mois | DH HT/mois | Sites réalistes |
|---|---|---|---|---|---|---|
| VPS-1G Démarrage | 1 | 1 Go | 30 Go | 9,99 | 94,48 | Un site, ou deux très légers |
| VPS-2G Business | 1 | 2 Go | 40 Go | 19,99 | 189,06 | Trois ou quatre vitrines |
| VPS-3G Performance | 2 | 3 Go | 50 Go | 34,99 | 330,93 | Quatre à six sites, une boutique |
| VPS-4G Avancé | 2 | 4 Go | 80 Go | 39,99 | 378,22 | Six à huit sites, deux boutiques |
| VPS-5G Ultra | 3 | 5 Go | 100 Go | 49,99 | 472,80 | Huit à dix sites, builds et recette |
Des ordres de grandeur, pas des garanties : mesurez avant de choisir, puis gardez 30 % de marge. Le passage à une offre supérieure se fait à tout moment sans migration douloureuse. L'hébergement est assuré depuis New York (moins de 5 ms sur place, 10 à 20 ms à Montréal) ; un datacenter à Rabat est annoncé mais pas encore ouvert.
Quand arrêter de mutualiser
La mutualisation devient une mauvaise idée quand elle coûte plus cher que la séparation. Cinq signaux :
- Un site sature la machine. Un domaine prend la majorité du processeur aux heures de pointe.
- Les sauvegardes se chevauchent. Un export nocturne encore en cours à l'ouverture signale un serveur trop chargé.
- Un client exige une séparation. Données sensibles, audit, clause contractuelle : la question n'est plus technique.
- Les environnements divergent. Deux applications réclament des versions incompatibles et les contournements s'empilent.
- Un incident devient collectif. Une attaque sur un site met les autres hors ligne.
La sortie est simple : un second VPS, une copie des fichiers et de la base, un changement d'enregistrement DNS.
FAQ
Combien de sites puis-je héberger sur un VPS à 1 Go ?
Un site vitrine avec cache tient, deux si l'un des deux est statique. Au-delà, la mémoire manque : chaque pool PHP-FPM, chaque processus de base et chaque démon ajoutent leur part. Le plan à 2 Go est le départ réaliste pour trois ou quatre petits sites.
Faut-il une adresse IPv4 par site ?
Non. Chaque plan inclut une IPv4 dédiée, et le SNI permet de servir plusieurs domaines sur cette adresse avec un certificat distinct par domaine. Une adresse supplémentaire se justifie rarement : un client qui exige la sienne, ou un courrier à réputation séparée.
Les sauvegardes automatiques suffisent-elles pour plusieurs sites ?
Elles couvrent la panne de la machine, pas l'erreur applicative. Si un site corrompt sa base, la sauvegarde du serveur vous rend une machine saine avec une base corrompue. Gardez un export par site et testez la restauration.
Puis-je donner à chaque client un accès séparé ?
Oui, au niveau du système de fichiers et du pool PHP-FPM, avec un utilisateur par site. Mais l'accès root reste unique : qui l'obtient voit tous les autres sites. Pour une séparation réelle, il faut un serveur par client.
Héberger plus de sites sans reconstruire la plateforme
Commencez par un inventaire écrit : domaines, runtime de chaque site, bases, fenêtre de sauvegarde, pic de trafic. Ce tableau décide du reste — vhosts si les sites se ressemblent, conteneurs dès que les environnements divergent. Si vous gérez les sites de vos clients, l'offre d'hébergement en marque blanche est faite pour ce cas de figure ; pour la machine elle-même, comparez les offres VPS NVMe, leurs prix et leurs caractéristiques.