4 days ago
Building is not working because of stale snapshot. Here's your AI take on the issue:
The Docker build is failing because uv.lock is missing from the build context, even though the file exists in the repository. This appears to be an issue with Railway's incremental snapshot system not picking up a newly added file. Contact Railway support to investigate, or try pushing a small change to uv.lock to force the snapshot to recognize it.
Pinned Solution
4 days ago
Your Dockerfile seems to be correct. Since the issue is a missing uv.lock file from the build context, the only things left to check are your .dockerignore, and .gitignore files. You need to ensure uv.lock is present in the github repository. And, since you already have the root directory set to /, those are the next things you need to check. Also, does your worker build fine locally? Or is it just on Railway?
8 Replies
4 days ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • 4 days ago
4 days ago
Try to set NO_CACHE=1 in your service variables, and redeploy. You can also try to deploy latest commit, by clicking on your service, then press Ctrl+k, then select deploy latest commit.
darseen
Try to set `NO_CACHE=1` in your service variables, and redeploy. You can also try to deploy latest commit, by clicking on your service, then press Ctrl+k, then select **deploy latest commit**.
4 days ago
Tried both, still doesn't work. It keeps using a stale snapshot
Attachments
4 days ago
It looks like your project is a monorepo (indicated by apps/worker). If root directory is left at default (/), Docker uses the repository root as its build context. You can either set the root directory to apps/worker in your service settings (if your worker doesn't rely on shared packages), or modify your Dockerfile COPY commands to be something like this: COPY apps/worker/uv.lock ., instead of COPY uv.lock .
darseen
It looks like your project is a monorepo (indicated by apps/worker). If root directory is left at default (/), Docker uses the repository root as its build context. You can either set the root directory to `apps/worker` in your service settings (if your worker doesn't rely on shared packages), or modify your Dockerfile COPY commands to be something like this: `COPY apps/worker/uv.lock .`, instead of `COPY uv.lock .`
4 days ago
I actually just restructured the monorepo to use a single, root-level pyproject.toml and uv.lock (using uv workspaces) to fix some IDE resolution issues with my local shared packages. Because of this new setup, I no longer have an apps/worker/uv.lock file. My worker app does rely on the shared packages, so I need to leave the Railway root directory at / (default) so the Docker build context has access to the root lockfile and the shared package directories.
darseen
Can you share your Dockerfile?
4 days ago
Sure, here it is
Attachments
4 days ago
Your Dockerfile seems to be correct. Since the issue is a missing uv.lock file from the build context, the only things left to check are your .dockerignore, and .gitignore files. You need to ensure uv.lock is present in the github repository. And, since you already have the root directory set to /, those are the next things you need to check. Also, does your worker build fine locally? Or is it just on Railway?
4 days ago
The issue was actually in my .dockerignore file. I had it set to ignore everything except the worker and shared packages, which meant Docker was skipping the root pyproject.toml and uv.lock files. Thanks for your help!
Status changed to Solved dev • 2 days ago