Unfortunately, there is not much information in the log to investigate the issue.
Maybe adding verbose option could help to determine what is the issue.
I already added the verbose option to the command described above, I also upgraded the Node version to LTS and I am having the same intermittent issue:
Hello @jorgeramirezamora
I’ve checked the memory usage of the builder used for building your application, and the limit of 8GB has still been reached.
It seems that the limit mechanism might not have been configured correctly.
Now I see where is coming from: build.cpu_max_in_milli and build.ram_max_in_gib variables in Advanced Settings.
It is weird, I am using the right mechanism which is setting the NODE_OPTIONS environment variable to “–max_old_space_size=X” in my Dockerfile. I already using the same approach in our GitHub Actions and it works correctly there. It has similar specs if we compare it against Qovery ones:
Here is the memory usage of the builder for two deployments. The first deployment is failing, and the second one is succeeding. Would you mind setting the –max-old-space-size to 4GiB and letting me know if the issue is still occurring?
Actually, I would like if it possible that you set 4GB instead of 6GB to be sure that the option works with the npx nx run-many command . As stated in the documentation for --max-old-space-size=SIZE (in megabytes):
On a machine with 2 GiB of memory, consider setting this to 1536 (1.5 GiB) to leave some memory for other uses and avoid swapping.
I transformed all packages/libraries into buildable Vite packages/libraries.
I migrated all applications to use SWC as compiler, rather than babel.
If this is not enough, another possibility is to use Rspack rather than Webpack as bundler, but the plugin still is not as complete as the Webpack as of today, but is blazing fast tough.
