Quelle offre VPS choisir pour ce que vous exécutez ?

Vous avez choisi l'application. Vous avez maintenant devant vous quatre cartes d'offres, intitulées Pour les applications légères et les projets individuels et Pour les applications en production, alors que la documentation de votre application parle en gigaoctets et en cœurs, et les deux ne concordent pas d'eux-mêmes. Immich, par exemple, exige au minimum 6 Go de mémoire, ce qui exclut Stack 4 et ses 4 Go avant même que vous ayez installé quoi que ce soit.

Chaque ligne ci-dessous met en regard ce que publient les créateurs de l'application et l'offre qui lui convient. Il s'agit de notre estimation d'après la documentation de chaque éditeur, consultée le 2 octobre 2026. Nous n'avons pas exécuté ces applications sur les serveurs de DreamHost, mais nous avons testé une combinaison courante sur notre propre machine de test, plus bas. Lorsqu'un éditeur ne publie aucun chiffre, la ligne l'indique.

Ce que comprend chaque offre

Les quatre offres incluent un accès root complet, le choix de votre OS Linux, Docker et la bibliothèque d'applications en un clic. Elles diffèrent par le nombre de cœurs, la mémoire et le disque :

Regardez la colonne vCPU avant celle de la mémoire. Stack 8 double la mémoire et le disque de Stack 4 mais conserve les mêmes 2 vCPU : une application à court de processeur doit donc passer directement à Stack 16, la première offre avec plus de cœurs. Stack 32 les double encore, pour atteindre 8.

Trouvez votre app dans le tableau de dimensionnement

Trouvez la ligne la plus proche de ce que vous exécutez. Commencez avec l'offre indiquée dans la dernière colonne. La colonne du milieu reprend ce que publient les créateurs de l'application, avec les liens dans les sources ci-dessous. La page d'hébergement VPS de chaque application est en lien sous le tableau.

Pages d'hébergement VPS pour chaque application du tableau : LAMP Stack, Node.js, PostgreSQL, Docker et Portainer, Dokploy, n8n, GitLab, Supabase, Immich, Pelican Panel, OpenClaw, Hermes Agent, Paperclip, Ghost, Umami, Uptime Kuma.

Le minimum d'Immich est de 6 Go : Stack 4 ne figure donc pas sur sa ligne, même si Immich indique qu'un système de 4 Go peut fonctionner avec l'apprentissage automatique désactivé.

La plupart des lignes n'indiquent pas de nombre d'utilisateurs, car GitLab est le seul éditeur ici à en publier un : sa configuration à faible mémoire est prévue pour cinq développeurs au maximum.

Les applications d'un même serveur se partagent sa mémoire : additionnez donc leurs lignes et laissez de la place au système d'exploitation. Associez n8n à Immich et leurs minimums atteignent 10 Go avant même que le système d'exploitation prenne sa part, soit environ 300 Mio sur notre VM de test Ubuntu 24.04 fraîchement installée. C'est plus que ce dont dispose Stack 8 : la combinaison commence donc à Stack 16.

Consommation de ce duo sur notre VM de test

Nous avons exécuté cette combinaison le 22 octobre 2026 sur une VM de test dotée de 2 vCPU et de 8 Go de mémoire, soit le profil de Stack 8. Il s'agissait d'Immich v3.3.5 installé avec la configuration de release d'Immich, apprentissage automatique activé et sans photos, à côté de n8n 2.44.5 avec PostgreSQL à partir des fichiers Docker Compose de n8n, sans workflows. La VM tournait sur un Mac arm64 : il s'agit donc de notre machine de test, et non d'un serveur DreamHost.

Au repos, la combinaison utilisait moins de 2 Go, bien en dessous des 10 Go que totalisent leurs minimums. Mais le repos n'est pas la limite. Lors d'un test séparé sur une machine de même taille, Immich seul a atteint environ 6 Go pendant l'import de seulement 300 photos. Ajouter à ce pic les 0,4 Go de n8n au repos donne environ 6,4 Go, un simple calcul, puisque nous n'avons pas fait tourner les deux en charge en même temps. Cela laisse peu de place sur 8 Go, et c'est pourquoi nous recommandons toujours Stack 16 pour cette combinaison. Nous avons exécuté chaque configuration une seule fois, sur des installations neuves sans utilisateurs : considérez ces chiffres comme des planchers, et non comme des minimums de dimensionnement.

Le disque peut s'épuiser avant la mémoire. Une photothèque ou un serveur Git peut le remplir alors que la mémoire semble encore suffisante.

Si vous transférez une photothèque, mesurez-la d'abord et ajoutez la marge d'Immich avant de la comparer au disque de l'offre. Le chiffre de GitLab ne couvre que l'application, et GitLab demande en plus un espace de stockage pour les dépôts au moins égal à la taille cumulée de tous vos dépôts.

Les apps dont les éditeurs demandent plus que Stack 8

GitLab

GitLab est le cas difficile. Ses propres pages donnent des seuils différents. La page de configuration requise de GitLab fixe 8 vCPU et 16 Go comme référence pour une installation sur un seul nœud, et seule l'offre Stack 32 dispose de 8 vCPU. Stack 16 offre les 16 Go avec la moitié des cœurs. La même page indique que GitLab peut fonctionner avec au moins 8 Go lorsque la mémoire est limitée, et c'est le seul chiffre de processeur ou de mémoire de la page que Stack 8 atteint. Son guide pour les environnements à mémoire limitée descend encore plus bas, à 2 Go plus 1 Go de swap pour cinq développeurs au maximum dont les dépôts restent sous 100 Mo.

Les deux pages divergent aussi sur le swap. Pour une installation standard, GitLab recommande de désactiver le swap ou de prévoir assez de mémoire pour que GitLab ne l'utilise jamais, tandis que la configuration à faible mémoire suppose que le serveur utilise le swap en fonctionnement normal. Pour le serveur GitLab d'une petite équipe, nous recommandons Stack 16, qui vous donne la mémoire de référence et 4 des 8 cœurs : elle reste donc en dessous de la référence de GitLab, et un essai doit montrer qu'elle suit le rythme. GitLab conseille d'exécuter les runners CI sur une machine distincte de GitLab. Prévoyez un second serveur pour vos pipelines. Une équipe qui a besoin de toute la configuration de référence passe à Stack 32. L'hébergement VPS GitLab inclut GitLab CE sur toutes les offres Stack.

Supabase

La documentation d'auto-hébergement de Supabase juge son minimum de 4 Go, 2 cœurs et 40 Go de SSD adapté au développement et aux charges de production petites à moyennes, et Stack 4 comme Stack 8 l'atteignent. La configuration recommandée demande 4 cœurs ou plus, et comme Stack 16 est notre plus petite offre à en avoir 4, c'est là que nous ferions tourner un projet de production chargé.

Immich

Stack 8 atteint les 8 Go de mémoire recommandés par Immich, avec les 2 cœurs minimum. Stack 16 atteint les deux recommandations. Son disque de 250 Go accueille aussi une photothèque plus grande que les 150 Go de Stack 8, ce qui peut compter autant que la mémoire une fois que vous importez des années de photos de famille et de vidéos prises au téléphone.

Palworld et autres serveurs de jeu

Le guide serveur de Palworld indique 16 Go de mémoire et recommande 4 cœurs : Stack 16 répond donc à ses exigences. Il précise qu'un serveur de 8 Go démarre, mais risque davantage de planter lorsqu'il manque de mémoire, c'est pourquoi Stack 8 ne figure pas sur la ligne de Palworld. Le guide recommande aussi plus de 32 Go. Stack 32 dispose d'exactement 32 Go et c'est la plus grande offre Stack : un serveur Palworld qui a besoin de la mémoire recommandée a donc sa place sur une machine dédiée.

Ce que coûte une offre trop grande au départ

Si vous commencez trop petit, la solution est un changement d'offre : vous choisissez l'offre supérieure dans le panel, et votre environnement vous suit. Commencer trop grand n'a pas de solution équivalente. Le centre d'aide de DreamHost indique qu'il n'est actuellement pas possible de passer à une offre Stack inférieure. La marche à suivre consiste donc à vérifier que vos données tiennent, à provisionner un nouveau serveur sur l'offre inférieure, à tout y transférer, à vérifier que tout fonctionne, puis à résilier le serveur d'origine.

D'ici là, vous payez chaque mois de la mémoire et des cœurs que votre application n'utilise pas. Le centre d'aide de DreamHost indique qu'un VPS n'inclut pas de garantie de remboursement de 30 jours : vous ne disposez donc d'aucune période de remboursement sur laquelle compter. Commencez avec la plus petite offre qui respecte le minimum de votre application, et changez d'offre lorsque les vérifications ci-dessous montrent qu'elle arrive à ses limites.

Comment savoir si votre offre est devenue trop petite

Avant de payer une offre supérieure, déterminez si c'est la mémoire, le processeur ou le disque qui manque, car chacun appelle une mise à niveau différente. Le centre d'aide de DreamHost indique que les tableaux de bord Performance et Logs ne sont disponibles que sur le VPS géré : sur un VPS, vous vérifiez donc en ligne de commande pendant que l'application est sollicitée. Ces commandes effectuent les vérifications rapides :

free -h
cat /proc/pressure/memory
uptime
df -h

1. Vérifiez la mémoire disponible

   Exécutez free -h en utilisation normale. La colonne available estime la quantité de mémoire que de nouveaux programmes peuvent obtenir sans recourir au swap. Si elle reste proche de zéro, ou si l'utilisation du swap ne cesse d'augmenter, l'application manque probablement de mémoire. Les journaux de l'application le montrent aussi : n8n écrit JavaScript heap out of memory dans ses journaux lorsqu'un workflow manque de mémoire.

2. Vérifiez la pression mémoire

   Exécutez cat /proc/pressure/memory. La ligne full indique la part du temps pendant laquelle toutes les tâches en cours attendaient la mémoire en même temps. Selon la documentation du noyau, une charge de travail qui reste longtemps dans cet état subit un effondrement des performances (thrashing). Si c'est le cas, passez au forfait supérieur pour obtenir plus de mémoire : de Stack 4 à 8, de 8 à 16 ou de 16 à 32.

3. Comparez la charge à vos cœurs

   Exécutez uptime et lisez le troisième nombre, la charge moyenne sur 15 minutes. La charge n'est pas rapportée au nombre de cœurs : comparez-la donc au nombre de vCPU de votre forfait, soit 2 sur Stack 4 et Stack 8, 4 sur Stack 16 et 8 sur Stack 32. En règle générale, nous considérons qu'une charge sur 15 minutes qui reste au-dessus de ce nombre pendant plusieurs jours indique que vous manquez de CPU. Depuis Stack 4 ou Stack 8, c'est le signe qu'il faut passer à Stack 16.

4. Examinez le temps volé (steal time)

   Exécutez vmstat 5 et surveillez la colonne st, qui correspond au temps que l'hyperviseur a pris à votre serveur. En règle générale, si ce temps volé (steal) reste au-dessus de quelques pour cent, interrogez le support avant de payer un forfait plus important.

5. Vérifiez l'espace disque
   Exécutez df -h pour voir le taux de remplissage de chaque système de fichiers.
6. Passez à l'offre supérieure dans le panel

   Le centre d'aide de DreamHost indique la marche à suivre : allez dans Manage Account, trouvez votre VPS sous Active Plans, cliquez sur Manage, puis sur Select Plan sous Change Plan, et enfin sur Submit Order.

Un swap qui grossit peut aussi servir d'alerte précoce. Comme l'a fait remarquer un commentateur sur Hacker News, surveiller l'utilisation du swap peut vous signaler un problème avant que le noyau ne commence à tuer des processus faute de mémoire.

Si un pic de trafic est à l'origine de la charge, consultez comment gérer un pic de trafic avant de passer au forfait supérieur.

Quand un autre produit DreamHost convient mieux

Si vous préférez que nous gérions le serveur, DreamPress, le VPS géré ou l'hébergement sur serveur dédié géré vous conviendront peut-être mieux. Si vous ne savez pas si vous avez réellement besoin d'un serveur, commencez par lire avez-vous vraiment besoin d'un VPS.

Le serveur dédié géré vous offre un serveur géré avec accès root, et son forfait Enhanced va jusqu'à 128 Go de mémoire : lisez donc quand passer à un serveur dédié une fois que Stack 32 ne vous suffit plus. Pour les sites nouveaux ou simples, l'hébergement web est le bon point de départ : son forfait Launch couvre 25 sites web et environ 40 000 visites mensuelles (estimation). Si c'est une base de données MySQL qui ralentit vos sites sur VPS géré, le module complémentaire MySQL VPS lui fournit des ressources de base de données isolées, sous forme de service distinct.

FAQ sur le dimensionnement d'un VPS