15 days ago
Hello,
I am trying to migrate my backend service from Qovery to Railway.
I want to reuse my existing Docker image from AWS ECR which is: 262144723876.dkr.ecr.us-east-1.amazonaws.com/stockintent.backend:sha-9796d80
I entered this in the "edit source image" field.
I attached both logs from qovery deployment & railway deployment. Qovery is running without any issues whereas Railway is crashing, it looks like a railway runtime issue?
Can you help me fix this issue? I expect that railway would not try to rebuild the image and just run as is which should not have any issues!
Attachments
2 Replies
15 days ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • 15 days ago
14 days ago
This might be a runtime configuration issue. It could be happening because environment variables present in your Qovery setup are missing in your new Railway environment. I suggest you copy all environment variables associated with this service, and paste them into the Variables tab of your Railway service.
8 days ago
Hello,
I was able to resolve my issue after debugging deeply, though I think that I have report an unexpected behaviour of railway.
I am leaving below a summary of my findings:
Summary
Railway's container runtime does not apply Docker layer whiteouts when running images pulled from an external registry. Files and directories deleted or replaced in upper layers leak through from base image layers, resulting in a corrupted filesystem view at runtime.
Root Cause
When a Dockerfile RUN step removes or replaces files that exist in a lower layer, Docker creates whiteout markers in the upper layer. On a correct implementation, the container runtime merges the layers and hides the lower-layer files. Railway does not apply these whiteouts, lower-layer files remain visible at runtime alongside the upper-layer replacements.
Steps to Reproduce
1. Build an image with a base that ships a file or directory at a known path
2. In a subsequent RUN step, delete or replace that path (rm -rf or package reinstall)
3. Push to an external registry (I used ECR in my case)
4. Deploy on Railway pointing to that external registry image
5. SSH into the running container and inspect the path
Expected: only the upper-layer version exists
Actual: both the base image version and the upper-layer version are present
Impact
Any Railway deployment that:
- Pulls an image from an external registry
- Where a RUN layer removes or replaces files from the base image
Notes
- The same image runs correctly on other runtimes (Kubernetes/EKS, local Docker)
- The issue seems specific to Railway's container runtime, not the image build process
- Workarounds that write into existing paths (rather than deleting) are unaffected, since they don't produce whiteout markers