Memory limits, out of memory errors and Node heap size
Fix JavaScript heap out of memory, Killed and exit code 137 on Schokr by sizing your server and tuning --max-old-space-size.
Updated · 2 min read
Every Schokr server has a memory limit that you choose from your team's pool. If your app uses more, it is killed, often with Killed or exit code 137 in the console. Node.js can also hit its own heap limit first, which shows as JavaScript heap out of memory.
Two different problems
| Message | What happened |
|---|---|
FATAL ERROR: ... JavaScript heap out of memory | Node.js reached its internal heap limit |
Killed, exit code 137, or the server simply stops | The whole process exceeded the server's memory limit |
MemoryError (Python) | Python could not allocate more memory |
Check and raise your server's memory
The free package gives each team 6 GB of memory to split across up to 4 servers. If one app needs more, lower another server's memory or buy more in the store (1 GB for 450 credits). Typical needs:
| App | Memory |
|---|---|
| Small API or bot | 256 to 512 MB |
| Express or FastAPI with moderate traffic | 512 MB to 1 GB |
| Next.js build | 1 to 2 GB |
| Django with several gunicorn workers | 512 MB to 1.5 GB |
Set the Node.js heap size
Node.js sizes its heap based on available memory, but in containers it may pick a value that is too large (process gets killed) or too small (heap errors). Set it explicitly to about 75% of your server's memory:
node --max-old-space-size=768 index.js
That suits a 1 GB server. You can also set it through an environment variable, which works for npm run build and other tools that start Node themselves:
NODE_OPTIONS=--max-old-space-size=768
Leave headroom: Node uses memory outside the heap for buffers, native addons and code.
Builds use the most memory
next build, vite build and TypeScript compiles often use several times more memory than the running app. Options:
- Temporarily increase the server's memory for the build, then lower it.
- Build on your own computer and upload the output. See Next.js deployment.
Python tips
- Each gunicorn or uvicorn worker is a full copy of your app. Fewer workers means less memory.
- Process large files in chunks instead of reading them fully into memory.
- Use generators and pagination when querying databases.
Find a memory leak
If memory climbs steadily until the app is killed:
- Log memory periodically:
console.log(process.memoryUsage().rss)in Node.js, or usetracemallocin Python. - Look for caches, arrays or maps that grow forever, event listeners added on every request, and timers that are never cleared.
- As a stopgap, use your server's Schedules to restart the app daily. See scheduled jobs.
Check your server's Resources view in the console to see memory use over time.