« JavaScript heap out of memory » à la compilation, et les arrêts pour mémoire insuffisante ensuite.
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory veut dire que Node a atteint sa propre limite de tas, pas que la machine manque de RAM. Montez la limite avec NODE_OPTIONS=--max-old-space-size seulement si le conteneur a vraiment cette mémoire. Sinon, allégez la compilation ou donnez-lui plus de mémoire.
Faits vérifiés le
Deux échecs qui se ressemblent
Une compilation peut manquer de mémoire à deux endroits, et les correctifs vont en sens contraire. Vérifiez lequel vous avez avant de toucher à quoi que ce soit.
# The shape of a heap-limit failure (trimmed)
<--- Last few GCs --->
... Mark-Compact ... MB ...
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
1: ... node::Abort() ...
...
# the process then exits with code 134| Ce que vous voyez | Code de sortie | Qui l’a arrêtée | Ce qui aide |
|---|---|---|---|
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory (ou Ineffective mark-compacts near heap limit), avec une trace de pile † † † | 134 (128 + SIGABRT) | V8, à sa limite de tas. Le conteneur a peut-être encore de la mémoire libre | Un --max-old-space-size plus élevé, si le conteneur a de la marge; ou une compilation plus légère |
Aucune erreur de Node. Le journal s’arrête, parfois avec Killed † † | 137 (128 + SIGKILL) | Le noyau, parce que le conteneur a dépassé sa limite de mémoire | Plus de mémoire pour le conteneur, ou une compilation plus légère. Monter la limite du tas aggrave les choses |
† Les détails sur les concurrents proviennent des pages publiées par chaque fournisseur aux dates indiquées; les prix et forfaits changent, vérifiez auprès du fournisseur avant de décider. `FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory` (ou `Ineffective mark-compacts near heap limit`), avec une trace de pile (2026-10-29) · `FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory` (ou `Ineffective mark-compacts near heap limit`), avec une trace de pile (2026-10-29) · `FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory` (ou `Ineffective mark-compacts near heap limit`), avec une trace de pile (2026-10-29) · Aucune erreur de Node. Le journal s’arrête, parfois avec `Killed` (2026-10-29) · Aucune erreur de Node. Le journal s’arrête, parfois avec `Killed` (2026-10-29)
Régler --max-old-space-size sans empirer la situation
L’option fixe la taille de l’ancienne génération du tas de V8, en Mio. Node l’accepte dans NODE_OPTIONS, donc elle atteint chaque processus Node lancé par votre script de compilation :
- Restez sous la mémoire du conteneur. La documentation de Node suggère 1536 sur une machine de 2 Gio, pour laisser de la place à tout ce qui vit hors du tas. Modules natifs, tampons et cartes de source gardées hors de V8 consomment aussi de la mémoire.
- Trop haut, vous échangez le code 134 contre le 137. Le tas grossit au-delà de ce que permet le conteneur et le noyau tue la compilation sans le moindre message.
- Trop bas, c’est vous qui causez l’erreur. Un
NODE_OPTIONScopié d’un vieux README, comme--max-old-space-size=2048, plafonne une compilation qui disposait de 6 Go.
# One build, any shell that sets env vars this way (Linux, macOS)
NODE_OPTIONS=--max-old-space-size=3072 npm run build
# Check the limit Node is actually using, in MB
node -e "console.log(v8.getHeapStatistics().heap_size_limit / 1048576)"La mémoire de compilation sur Canner
Chaque compilation s’exécute dans son propre bac à sable, avec un budget de mémoire fixé par votre forfait. Canner passe lui-même --max-old-space-size à la compilation, calibré sur ce budget moins 200 Mo pour la mémoire hors du tas : la plupart des projets n’ont rien à régler. La documentation des forfaits et limites donne les chiffres; la page des tarifs compare les forfaits.
- Trouvez le pic. Après chaque étape, le journal affiche une ligne comme
[canner] build used up to 3.4 GB of memory. Comparez-la à votre budget avant de décider quoi changer. - Quand la compilation est tuée, le message est
build ran out of memory and was killed. On large projects this is often the type-checking or bundling step, suivi du correctif Next.js présenté plus bas. - Quand votre propre NODE_OPTIONS est en cause, Canner le dit : « Your NODE_OPTIONS environment variable limits Node's heap to 2048 MB, well below the memory this build was given, so the build ran out of memory at that limit. Remove --max-old-space-size from NODE_OPTIONS (or raise it) and deploy again. » La relance automatique est alors sautée, puisque plus de mémoire n’y changerait rien.
- Une compilation relancée le signale. Son journal commence par
[canner] the last build ran out of memory, so this one runs with more: 6 GB instead of your plan's 4 GB (once a month).
| Mémoire de compilation | Notes | |
|---|---|---|
| Démarrage | Jusqu’à 4 Go | Forfait gratuit |
| Live | Jusqu’à 6 Go | La RAM d’application ajoute 1 Go de mémoire de compilation par Go attribué au projet |
| Relance automatique | 4 → 6 Go sur Démarrage, 6 → 8 Go sur Live | Une fois par mois par organisation, pour une compilation de production depuis GitHub qui a manqué de mémoire. Pas pour les aperçus, les téléversements ni les déploiements par l’interface en ligne de commande |
Alléger la compilation
Plus de mémoire cache le problème jusqu’à ce que le projet grossisse encore. Pour Next.js, ces réglages viennent de son propre guide sur la mémoire :
| Réglage | Ce qu’il économise | Contrepartie |
|---|---|---|
typescript: { ignoreBuildErrors: true } dans next.config, plus tsc --noEmit en intégration continue † | La vérification de types, souvent le plus gros pic d’un grand projet | La compilation n’attrape plus les erreurs de types; faites la vérification ailleurs avant de fusionner |
productionBrowserSourceMaps: false et experimental.serverSourceMaps: false † | La génération des cartes de source | Des traces de production plus difficiles à lire |
experimental.webpackMemoryOptimizations: true (Next.js 15 et plus) † | Le pic de mémoire de webpack | Une compilation un peu plus lente |
next build --experimental-debug-memory-usage † | Rien en soi; affiche l’usage du tas pendant la compilation et prend des instantanés près de la limite | Pour le diagnostic seulement |
† Les détails sur les concurrents proviennent des pages publiées par chaque fournisseur aux dates indiquées; les prix et forfaits changent, vérifiez auprès du fournisseur avant de décider. `typescript: { ignoreBuildErrors: true }` dans `next.config`, plus `tsc --noEmit` en intégration continue (2026-10-29) · `productionBrowserSourceMaps: false` et `experimental.serverSourceMaps: false` (2026-10-29) · `experimental.webpackMemoryOptimizations: true` (Next.js 15 et plus) (2026-10-29) · `next build --experimental-debug-memory-usage` (2026-10-29)
Mémoire insuffisante après le déploiement
L’appli en marche a sa propre limite, distincte de la compilation : 512 Mo sur Démarrage et 2 Go sur Live. C’est un plafond strict. Au-delà, le noyau tue le processus, et le graphique Trafic et mémoire de la vue d’ensemble du projet marque le moment : Mémoire insuffisante, arrêt forcé. Le même graphique trace la mémoire par rapport à la limite, avec chaque compilation indiquée : une montée régulière entre deux déploiements (une fuite) ne ressemble pas à des sauts qui suivent le trafic (un vrai besoin).
Canner prévient aussi avant d’en arriver là. Quand une appli reste à 90 % ou plus de sa limite de mémoire pendant 10 minutes, le propriétaire de l’organisation reçoit un courriel, au plus une fois par déploiement et une fois par semaine par projet.
Pour que Node récupère la mémoire plus énergiquement avant que le noyau intervienne, fixez une limite de tas sous la mémoire de l’appli, par exemple --max-old-space-size=1536 pour une appli de 2 Go. Ajoutez NODE_OPTIONS dans Variables d’environnement avec la portée exécution seulement : elle atteint l’appli en marche, jamais une compilation, donc elle ne peut pas plafonner le tas de vos compilations. Monter la limite ne corrige pas une fuite; ça ne fait que retarder le plantage.
Ajouter de la mémoire : RAM d’application ou RAM dédiée
Sur un forfait payant, vous pouvez ajouter de la mémoire à un projet sans changer de forfait. Les deux modules se comportent différemment :
| RAM d’application | RAM dédiée | |
|---|---|---|
| Prix | 4 $ / Go / mois | 19 $ / Go / mois |
| Garantie | Non : mémoire groupée. Quand le serveur est occupé, l’appli ralentit sans être coupée | Oui : réservée et jamais survendue |
| Mémoire de compilation | +1 Go par Go attribué | Inchangée |
| Pour | Un site ou une API qui a besoin de plus de marge | Postgres, charges d’IA, tout ce qui exige une performance constante |
Questions
Quelle est la différence entre les codes de sortie 134 et 137?
134, c’est 128 + 6 (SIGABRT) : Node s’est arrêté lui-même à sa limite de tas en affichant JavaScript heap out of memory. 137, c’est 128 + 9 (SIGKILL) : quelque chose d’extérieur a tué le processus, en général le noyau quand un conteneur dépasse sa limite de mémoire. Monter --max-old-space-size peut régler le premier et aggraver le second.
Faut-il définir NODE_OPTIONS=--max-old-space-size sur Canner?
Pas pour les compilations : Canner calibre déjà le tas sur le budget de mémoire de la compilation, et une valeur plus basse de votre part l’emporte et cause l’erreur. Pour l’appli en marche, une valeur sous sa limite de mémoire, avec la portée exécution seulement, est raisonnable.
Combien de mémoire une compilation reçoit-elle sur Canner?
Jusqu’à 4 Go sur Démarrage et 6 Go sur Live. Sur Live, la RAM d’application ajoute 1 Go de mémoire de compilation par Go attribué. Une fois par mois, une compilation de production depuis GitHub qui manque de mémoire est relancée automatiquement avec la mémoire du palier suivant.
Plus de mémoire corrige-t-elle une fuite de mémoire?
Non. Elle retarde le plantage. Si la mémoire monte régulièrement entre deux déploiements et ne redescend qu’au redémarrage de l’appli, cherchez d’abord la fuite avec un instantané du tas.
Des compilations à la mesure de vrais projets.
Jusqu’à 4 Go de mémoire de compilation sur le forfait gratuit, avec le pic affiché dans chaque journal.