# Combien de RAM faut-il pour héberger Next.js sur un VPS ?

Il n’existe pas une quantité de RAM qui convienne à toutes les applications Next.js. Une page statique, un tableau de bord avec sessions et une page générant de gros tableaux ne sollicitent pas le même travail. Le nombre de visiteurs mensuels, pris seul, aide peu à choisir un VPS.

La bonne question est plus précise : quelle mémoire faut-il pour votre application, avec ses dépendances, ses pointes simultanées et sa manière de déployer ? Voici une méthode pour établir ce budget sans confondre la compilation avec le serveur qui répond aux visiteurs.

## Séparer build, repos et charge

Le build transforme les sources et peut produire des pages à l’avance. Le serveur au repos garde son moteur et les modules chargés. Sous charge, plusieurs rendus, appels réseau et réponses peuvent être actifs en même temps. Ce sont trois états à mesurer séparément.

Si le build s’exécute en CI, son pic ne dimensionne pas directement le VPS de production. S’il tourne sur le même serveur que le site, il faut additionner les besoins pendant cette période. Un déploiement avec ancienne et nouvelle release simultanées ajoute encore un cas à tester.

## Choisir une mesure qui couvre les bons processus

Le heap JavaScript ne représente qu’une partie de la mémoire de Node. Le RSS inclut les pages résidentes du processus, dont des allocations natives. Sous Linux, la PSS répartit les pages partagées proportionnellement et permet une comparaison plus informative d’un arbre de processus.

Pour un service systemd, observez aussi la mémoire du cgroup : elle couvre le groupe avec sa propre comptabilité, différente de la PSS. Notez la métrique utilisée et gardez-la d’un essai à l’autre. Mesurer seulement un worker oublie le parent, les autres workers et les composants natifs.

```sh
systemctl show my-next-app.service -p MemoryCurrent -p MemoryPeak
ps -eo pid,ppid,rss,comm --sort=-rss
```

## Mesurer vos routes et vos pointes

Relevez le repos après quelques visites pour charger les chemins courants. Rejouez ensuite une charge progressive sur une page dynamique, une API et les routes les plus coûteuses. Vérifiez le contenu obtenu : une page d’erreur légère peut afficher un débit flatteur tout en masquant un échec.

Conservez la mémoire maximale observée, la latence, le taux d’échec et le niveau de concurrence. Ajoutez un parcours connecté si votre application dépend des sessions. Une charge anonyme sur la page d’accueil ne décrit pas nécessairement l’espace client. Une mesure courte sert de point de départ, pas de preuve de stabilité pendant des semaines.

## Construire le budget du serveur entier

Additionnez le système, le proxy, la base de données éventuelle, les applications et la marge nécessaire aux pointes et aux déploiements. Faites ce calcul avec des mesures sur le serveur cible ou un environnement représentatif. Une limite mémoire protège une frontière ; elle ne garantit pas que l’application dispose d’assez de place.

Exemple fictif : sur 2 048 Mio, vous réservez 500 Mio au système et aux services communs, puis 400 Mio aux pointes et aux déploiements. Il reste 1 148 Mio pour les applications. Ces nombres illustrent le calcul et ne constituent ni un minimum Next.js ni une recommandation universelle. Remplacez-les par vos relevés.

## Lire les benchmarks avec leur configuration

Dans notre campagne PRNext contre Next.js, la page SSR courante sur le petit VPS utilise 113,88 Mio de PSS pour PRNext contre 101,38 Mio pour Next.js. Avec le budget de 2 CPU sur l’autre machine, les valeurs sont 117,50 et 173,30 Mio. Le classement dépend donc du contexte.

Ces résultats portent sur le candidat identifié de PRNext 0.1.18-alpha, une application de test et des fenêtres courtes. Ils ne mesurent pas votre application, son build ou les archives finales de la version. La mise en veille constitue encore un autre état : elle réduit la mémoire des workers inactifs et impose un réveil.

[Consulter les configurations et les données du benchmark](/fr/blog/prnext-vs-nextjs-benchmarks-vps)

[Comprendre la mémoire au repos et le coût du réveil](/fr/blog/prnext-mode-sleep-memoire)

## Décider à partir du facteur limitant

Une mémoire suffisante n’empêche pas un CPU saturé de faire monter la latence. Inversement, ajouter du CPU ne résout pas une accumulation d’objets ou une base qui manque de mémoire. Cherchez la ressource qui se dégrade au moment des ralentissements.

Après chaque changement, rejouez la même charge. Si la consommation croît sans se stabiliser à travail comparable, passez au diagnostic mémoire. Si les pointes sont légitimes, revoyez le placement du build, le nombre de processus ou la capacité disponible.

[Diagnostiquer une consommation mémoire Next.js élevée](/fr/blog/diagnostiquer-consommation-memoire-nextjs)

## Sources

[Next.js: memory usage](https://nextjs.org/docs/app/guides/memory-usage)

[Node.js: process.memoryUsage()](https://nodejs.org/api/process.html#processmemoryusage)

[Linux: proc filesystem memory metrics](https://docs.kernel.org/filesystems/proc.html)

[systemd: resource control](https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html)

Published: 2026-10-30

Modified: 2026-10-30

Author: PRNext

---

Language: fr

Canonical: https://prnext.dev/fr/blog/nextjs-ram-dimensionner-vps

Index: https://prnext.dev/llms.txt