It only occurs when a volume is attached.

Please share a screenshot of your past 1d memory metrics. I think you might be going over your memory limit.

I'm very under the limit:

Update: the volume is successfully staying there.

Steps I did to fix were:

Change the volume mount path from /app/data to /uploads - after deploying this, the volume crashed.

Then in my backend I changed the local provider's storage path from /app/data to /uploads, and then the deployment no longer crashed.

This leads me to think that, using /app in the mount path was the issue?

Hey amarinsam, just reminding you to mark your thread as solved.

Hello, is it possible to reopen this? The issue is happening again.

The volume was NOT mounted to /app, it was mounted to /uploads, but I'm still getting the same crash.

Attempting to open once again

Is this a dockerfile deployment ? If yes then share the dockerfile here.

It's a Volume attached to my Github deployment. I basically followed exactly what was recommended by this Railway short: https://www.youtube.com/shorts/dSLVfXYfaY8

(which by the way, demonstrates via mounting on the /app path)

If you take a look at the first screenshot, a get request to /uploads/vole1_***.webp results in 404

My guess is a permissions issue. Your node user doesn't have the permission to write to the volume so it crashes.

If you are using a dockerfile, change your workdir to /src

If not then check which directory your code is referencing for the volume, maybe its referencing /app but you dont have a /app dir so maybe change that to /uploads

NOTE: if using VsCode a quick Ctrl Shift F with "/app" search should reveal wetin dey sup

| My guess is a permissions issue. Your node user doesn't have the permission to write to the volume so it crashes.

I am able to write to the volume, in that - while the volume is up, I can write/retrieve data from the /uploads path

| If not then check which directory your code is referencing for the volume, maybe its referencing /app but you dont have a /app dir so maybe change that to /uploads

Per the above, the /uploads path works

A couple more notes: I changed my mount path back to /app, after reading Railway docs. I added a test endpoint that logged files in /app/public/uploads, and it turns that my backend is writing to this folder, not the volume, and that this folder gets cleared on rebuild.

Something is causing the volume to crash over and over.

Again the errors are here:

npm error path /app

npm error command sh -c strapi start

npm error signal SIGTERM

Strapi errors, and something is causing it to be corrupted?

Or the container launches but can't access /app due to conflict

Or a bad file is committed (e.g., missing .env, bad config)?

Here are the recent crashes

Thanks everyone for taking a look. I figured out the solve, which is that Strapi always writes to /app/data/uploads.

The deployment that was crashing was not the newly deployed deployment, but the one previous (the old one). My guess is that, my volume is always mounted to /app path. Because the volume is attached to each new deployment, the volume has to detach and attach to the new one when deployed.

I can't fully explain the mechanism behind this, because other pushes that I make don't seem to crash old deployments but I think that's what's going on. Maybe someone with more insight can share.

The volume was attaching properly, but Strapi ALWAYS sends image uploads by default to the /app/public/uploads folder, and I wasn't able to nail how to change the configuration for it otherwise. The solve was to mount the volume itself to /app/public/uploads.