node container exits 137 under load on a 2gb vps with mem_limit 512m Dockerfile

Node doesn't know about your cgroup limit. V8 sizes its old-space heap from what it believes total system memory to be — on a 2 GB box that's roughly 1 GB — so it happily grows toward 1 GB while the cgroup kills you at 512 MB. It isn't failing to GC, it thinks it has plenty of room left.

Tell it the truth:

environment:
  NODE_OPTIONS: --max-old-space-size=384
mem_limit: 512m

Leave headroom, because old space isn't the whole RSS — buffers, the code cache, native modules and stacks all live outside it. 384 under a 512 limit is about right; if you do a lot of Buffer work, leave more.

Then watch it. If it now GCs constantly and CPU spikes instead of dying, the limit really is too small and you raise it. Nine times out of ten this is the entire bug.

To be precise about the diagnostic, because it's worth having for next time: 137 is 128 + 9, so SIGKILL. That on its own doesn't mean OOM — you also get it when compose gives up waiting during docker stop and kills the container. The thing that told you it was OOM is the OOMKilled: true you already checked, so good instinct.

If it had been the stop-timeout case, the fix would be handling SIGTERM properly rather than touching memory at all.

Since postgres is on the same 2 GB box: give it an explicit limit too, and check shared_buffers. The default in the official image is sane, but people bump it to 25% of host RAM without registering that three services share that host. Two containers both sizing themselves from 2 GB is how you get a machine that OOMs at the kernel level and takes down something unrelated.

Also check whether you have any swap. Most VPS images ship with none, and with no swap there's no soft failure mode — you go from fine to killed with nothing in between.

Measure before you tune. docker stats for the crude version, or run cAdvisor and get real numbers. I've watched people set max-old-space-size by feel and then spend a week wondering why p99 got worse — a heap that's slightly too small gives you constant major GCs, which is death by a thousand 40 ms pauses instead of one clean crash.

Also worth confirming there isn't a real leak underneath the misconfiguration, because 300 MB idle is high for a small API. Take two heap snapshots ten minutes apart under steady load and diff retained size. If it's flat, you're fine and this was purely heap sizing.

just drop mem_limit, the box has 2gb and the kernel will sort it out

Set restart: unless-stopped at minimum while you sort this out, so a kill at 3am is a four-second blip rather than your morning.