Prisma + SQLite causes an out of memory error on deploy

Questions / Help
1

My Remix app uses the solution outlined in this post, where the prisma migrations are run at app boot.

That solution works for me, but causes OOM on deploys with the 256MB instance, which is enough for running my app.

The OOM error happens when prisma is installed before the migration - logs below:

sea [info] + npx prisma migrate deploy
sea [info] npm WARN exec The following package was not found and will be installed: prisma@4.10.1
sea [info] [ 18.368134] Out of memory: Killed process 604 (node) total-vm:11174852kB, anon-rss:124780kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:1472kB oom_score_adj:0

Does anyone have ideas on how to avoid this OOM on deploy?

Also, I don’t have a great understanding of where the Fly.io experimental.cmd fits vs. the Dockerfile - why isn’t prisma already installed at that point?

Since the Remix indie stack recommends Fly.io, it would be sweet if it was possible to deploy an app under the hobby plan with 256MB of RAM.

1 Like
2

Running into same problem - Basically everything on fly.io is broken lately - Really disappointing - I wasted so much time on this - was ready to host my app on a dedicated server but everything is so unreliable - I’ve wasted so much time, I feel like this whole app is one big sunk cost

I ended up scaling up and that seemed to work - another issue I had to deal with was just destroying one of my apps and rebuilding from scratch

1 Like
3

I had the same issue with the remix tutorial when deploying. You can add a swap file to help with the memory limit during the build.

Here is my start.sh file

set -ex

fallocate -l 512M /swapfile
chmod 0600 /swapfile
mkswap /swapfile
echo 10 > /proc/sys/vm/swappiness
swapon /swapfile
echo 1 > /proc/sys/vm/overcommit_memory
npx prisma migrate deploy
npm run start

i took the code from the fly.io docs : Optimizing your deployment · Fly Docs

3 Likes
4

@polkach Awesome. This helped a lot. I ended with this:

fallocate -l 256M /swapfile
chmod 0600 /swapfile
mkswap /swapfile
echo 10 > /proc/sys/vm/swappiness
swapon /swapfile
npx prisma migrate deploy
swapoff /swapfile
rm /swapfile
npm run start

I’m not sure if it’s necessary to turn the swap off and remove the allocated space. I figured that this would mean the prod app would be using the swapfile too (and thus would have less persistent storage). Does that sound right? I also removed the overcommit since I’m not sure it’s necessary here.

5

Hi @sastreen,

Is it in the entrypoint.sh ? Can you share your fly.toml as well ?

I currently have:

[deploy]
  release_command = "npx prisma migrate deploy"

But I feel I need to change that, correct ?

1 Like
6

Hey Binajmen, I have the same question. Did you end up finding a solution?

7

Hi… That’s the old way of doing swap, actually, :snowflake:.

The new swap_size_mb is much easier. (Just be sure to put it near the top of the fly.toml file—i.e., not under a [section] delimiter.)

Hope this helps!

1 Like
8

Thank you for the reply. I tried using that option. It’s still giving me a similar error with prisma.

2025-05-15T21:09:19.203 app[d8d4d16ce32e58] fra [info] 2025/05/15 21:09:19 INFO SSH listening listen_address=[fdaa:14:a800:a7b:3db:20c2:ca57:2]:22

2025-05-15T21:09:21.582 app[d8d4d16ce32e58] fra [info] npm WARN exec The following package was not found and will be installed: prisma@6.8.1

2025-05-15T21:09:30.974 app[d8d4d16ce32e58] fra [info] <--- Last few GCs --->

2025-05-15T21:09:30.974 app[d8d4d16ce32e58] fra [info] [646:0x2579a850] 11668 ms: Mark-sweep (reduce) 253.6 (258.2) -> 253.4 (258.9) MB, 174.3 / 0.0 ms (+ 45.8 ms in 15 steps since start of marking, biggest step 4.3 ms, walltime since start of marking 230 ms) (average mu = 0.525, current mu = 0.213) alloc[646:0x2579a850] 11901 ms: Mark-sweep (reduce) 254.4 (258.9) -> 254.3 (259.9) MB, 229.4 / 0.0 ms (average mu = 0.329, current mu = 0.017) allocation failure; scavenge might not succeed

2025-05-15T21:09:30.974 app[d8d4d16ce32e58] fra [info] <--- JS stacktrace --->

2025-05-15T21:09:30.975 app[d8d4d16ce32e58] fra [info] FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

I suspect swap memory wouldn’t resolve the issue since it’s a heap memory allocation issue.

9

Hm… I’d suggest creating a new top-level thread for this (via the New Topic button), since the current thread has already been marked Solved—and the local JavaScript experts might not wade back in…

Generally speaking, it’s not a good idea to mix mark-sweep GC with swap, so this might take a lot of effort to get really working well (particularly in the age of CPU throttling).

1 Like