I was curious about this and it's apparently needed on Fly.io specifically, only to enable swap space. I assume this is due to a "quirk" of the nodejs runtime:

I was curious about this and it's apparently needed on Fly.io specifically, only to enable swap space. I assume this is due to a "quirk" of the nodejs runtime: many runtimes, not just node, tend to commit lots and lots of virtual address space for various (good) reasons to fulfill various roles, but don't necessarily need to back all that with physical memory. However, Linux will require swap space to back some of these commitments in practice (e.g. private memory mapped allocations will need to spill somewhere, so they can only be backed by swap, IIRC.) The node.js runtime almost certainly requires more virtual memory commitment than the default Fly.io runtime you pick (128Mb, I'd guess,) and it doesn't seem to provide swap out of the box, because... Fly.io simply boots a Linux kernel, and the Docker image you give it is then treated if it was full filesystem for that "instance". Whatever is in the container image is all you get. Many container environments aren't going to have init-like frameworks to initialize swap before booting the application; in fact the container only having say, node.js, a few .js files, and starting that immediately after kernel boot is actually a pretty good startup time optimization. So if you need swap space, because the runtime makes anonymous memory commitments larger than physical memory -- the only way to guarantee that is in the application path itself, like done here. You could also do a shell script I guess. You'd have to do this in any similar low-memory environment, really, if the init system didn't. Seems reasonable; nothing too suspicious or odd in the long run. It's nothing you're going to need outside of these new-fangled container-like environments (besides, in this case, the shell commands are easily auditable and not in any way user-controllable through user input, vastly reducing defect surface area.) Took 10 minutes to audit and figure out if you've had some previous exposure to runtime tuning; comments to explain this would have been nice, though...