Hey! Memory issues can be kind of tough to pin-down and depend on a lot of things.
Node in particular is pretty memory hungry, I believe. Memory could be inflating because of one of the things you bring up or it could be just that one of the code paths you already had increases memory and is slow to (or never) frees the memory.
A couple things you could try to narrow your issue down or resolve your issue (in no particular order):
You could profile your app to get a feel for what’s causing the memory to spike. This has some good ideas: javascript - Memory leaks in Node.js - How to analyze allocation tree/roots? - Stack Overflow. Profiling can tell you a lot about what’s going on, but it might also wind up telling you you just need more memory. I think if I were dealing with this I’d do most of this profiling locally, if you develop this locally at all.
You could use something called “swap” that lets your app VMs use disk to get by on less RAM. This community post describes it pretty well: Swap memory - #3 by scottohara. We use swap for some of our default Rails templates now described in docs here: Optimizing your deployment · Fly Docs. This isn’t a stellar option but you might be able to unblock yourself if you need to get around it now.
You could increase your VM size. Here’s our docs on how to adjust memory: Scale V1 (Nomad) Apps · Fly Docs. It’s worth noting the costs here as well as that each CPU size has a memory limit: Fly App Pricing · Fly Docs. This is probably your best solution. There’s a chance there are no “memory issues” the RAM is just too small.
I was rereading your notes; are you running gitpod on the same app you have the blues-stack deployed? I would guess that’s the biggest memory hog. I recall running a gitpod requires a fair bit of memory. I’m not sure if this thing linked is the exact thing you’re running but this doc says 8GB or 16GB for a better experience: Installation requirements for Gitpod Self-Hosted