The problem
You’ve built your website using Next.js and it all builds and runs just as you’d expect in your development environment, but then you upload it to your live Plesk or cPanel environment and setup your Express.js shim as normal:
You’ve got a pretty basic NextJS config:
But your npm build run
just won’t work and breaks your build and deploy routine with an error every time:
npm run build
> [email protected] build
> next build
info - Linting and checking validity of types .node:events:505
throw er; // Unhandled 'error' event
^
Error: spawn /opt/plesk/node/16/bin/node EAGAIN
at Process.ChildProcess._handle.onexit (node:internal/child_process:283:19)
at onErrorNT (node:internal/child_process:478:16)
at processTicksAndRejections (node:internal/process/task_queues:83:21)
Emitted 'error' event on ChildProcess instance at:
at Process.ChildProcess._handle.onexit (node:internal/child_process:289:12)
at onErrorNT (node:internal/child_process:478:16)
at processTicksAndRejections (node:internal/process/task_queues:83:21) {
errno: -11,
code: 'EAGAIN',
syscall: 'spawn /opt/plesk/node/16/bin/node',
path: '/opt/plesk/node/16/bin/node',
spawnargs: [
'/var/www/vhosts/example.org/httpdocs/node_modules/next/dist/compiled/jest-worker/processChild.js'
]
}
So you have a quick Google and nothing is really coming up for you, fortunately we have the answer for you after working with one of our digital agencies to fix the problem for them.
The cause
If you’re using Plesk or cPanel on your web hosting then the cause is most likely CloudLinux, specifically the LVE limits for the number of processes and threads your user is allowed to have running at any one time.
For the average user/website these limits will rarely cause a problem providing your hosting provider has been sensible, but NextJS starts many worker threads at once to speed up your build times, and this is where the limits can be triggered.
The solution
Fortunately the solution is pretty simple, you just need to edit your next.config.js
to add:
The config change tells NextJS to disable the use of Worker Threads and to use processes instead, with 1 per configured CPU (you’ll need to set this to a value sensible for your environment).
Now when we build our site, it should all build without errors:
npm run build
> [email protected] build
> next build
warn - You have enabled experimental feature (cpus) in next.config.js.
warn - Experimental features are not covered by semver, and may cause unexpected or broken application behavior. Use at your own risk.
info - Need to disable some ESLint rules? Learn more here: https://nextjs.org/docs/basic-features/eslint#disabling-rules
info - Linting and checking validity of types
info - Creating an optimized production build
info - Compiled successfully
info - Collecting page data
info - Generating static pages (4/4)
info - Finalizing page optimization
Page Size First Load JS
┌ ○ / 5.5 kB 107 kB
├ /_app 0 B 77.1 kB
├ ○ /404 194 B 77.3 kB
├ λ /api/send 0 B 77.1 kB
└ ○ /contact 2.81 kB 104 kB
+ First Load JS shared by all 77.1 kB
├ chunks/framework-4556c45dd113b893.js 45.2 kB
├ chunks/main-7ca0c04a95757ac7.js 30.5 kB
├ chunks/pages/_app-4a09cd1a90ca64b6.js 546 B
├ chunks/webpack-69bfa6990bb9e155.js 769 B
└ css/4aee9269a78b31a4.css 3.11 kB
λ (Server) server-side renders at runtime (uses getInitialProps or getServerSideProps)
○ (Static) automatically rendered as static HTML (uses no initial props)
Hopefully we’ve saved you some head scratching on this issue.
Remember, if your host won’t help you with issues like these, then perhaps you need to work with a specialist agency host like KDAWS.