flyctl deploy: Reached heap limit Allocation failed - JavaScript heap out of memory

More or less the same issue as described in FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

I’ve tried deploying with:

flyctl deploy --remote-only --vm-size shared-cpu-4x --vm-memory 8196

Anyone any suggestions?

Thanks,
Olaf

I can’t tell whether this error is a problem with your container or the Fly build process. I’m wondering if there’s more detail that you could provide, since the question is presently rather sparse.

Can you build the container locally? Also, while I’ve not needed to do this myself, can you build the container locally and send it to Fly? I wonder if the issue is with the specific builder approach Fly is taking. Finally, there is a legacy Fly builder that has been mentioned a few times on this board recently; is that worth a try?

Thanks for you reply.

I’m fairly new to this whole thing. Deploying worked perfect until a few days ago.

What extra details could I provide?

This is the last message I get when deploying:

432.2 <--- Last few GCs --->
432.2 
432.2 [17:0x7f84b8cc0000]   429772 ms: Mark-Compact 2028.4 (2089.2) -> 2022.6 (2090.0) MB, pooled: 0 MB, 885.38 / 0.03 ms  (average mu = 0.265, current mu = 0.066) task; scavenge might not succeed
432.2 [17:0x7f84b8cc0000]   431530 ms: Mark-Compact 2031.4 (2090.5) -> 2029.6 (2097.2) MB, pooled: 0 MB, 1723.38 / 0.01 ms  (average mu = 0.114, current mu = 0.020) allocation failure; scavenge might not succeed
432.2 
432.2 
432.2 <--- JS stacktrace --->
432.2 
432.2 FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
432.2 ----- Native stack trace -----

Yes, building the container locally works. What do you mean by the legacy fly builder? I can’t seem to find that…

1 Like

Found it, it’s here: Github Action and local deploy have stopped working today "failed to fetch an image or build from source: error building: timed out connecting to machine: failed to list workers" - #3 by mayailurus. The old builder is “not Depot”, and a few people have reported problems with the new approach.

I’ll give a general answer for this rather than one for this specific case. Where someone has a programming/devops problem, it is ideal if they construct a minimal reproducible example. It’s possible that staff here will be more lenient (e.g. because they can peek at your infra or their monitors) but since volunteers lurk hereabouts, the only way we can help is if there is enough information to reproduce the problem for ourselves.

What I understood from the other thread was that their issue related to Node memory usage/behaviour inside a Docker container. So a public repo containing a crashy example would be ace; maybe a customer could pull that repo, issue the command you’ve supplied, and see if that results in the supplied error. If it does, then bingo! someone can try a few commands (e.g. adjusting the swapfile or bumping up the RAM) to help fix the issue.

are you using Vite to build? If so, it is known to over consume resources which can cause OOMs

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.