2 months ago
I’m looking for a robust pattern for deploying a Python monorepo on Railway where multiple services share a local package.
- Repo: https://github.com/smidm/railway-uv-shared-package
- Public Railway project: https://railway.com/project/a30f50df-e81b-4e1d-bad5-753598eca1b3
What I’m trying to achieve:
Two services (app, app2) both import a shared local package (common), with deployment driven by code config as much as possible.
What I observed:
1. “Elegant” service-local setup fails
When each service is deployed from a narrowed root (service folder), local relative dependency on sibling package fails (../common not
available in build context).
I can reproduce this consistently in the repo (elegant_but_broken / broken env).
2. “Ugly” workspace setup works
A root-level uv workspace + lockfile + root Railway config that dispatches by service works reliably (ugly env), but it feels less service-
local.
3. Docker variant replaces the default railpack build system, and feels unnecessary low level.
Questions for Railway team/community:
1. What is the recommended Railway pattern for Python monorepos with shared local packages?
2. If I want per-service config files and clean boundaries, how should shared local code be handled without brittle workarounds?
3. Is root-level workspace config (repo-wide) effectively the intended approach for this case?
2 Replies
2 months ago
when you set a root directory on railway, it only pulls files from that folder into the build context. so ../common will never be accessible , that's by design, not a bug.
railway docs describe two monorepo models. isolated (no shared code between services, use root directory setting) and shared (services share code from the root). for the shared type, the recommended approach is to not set a root directory, and instead use custom start commands per service pointing into the repo.
2 months ago
your workspace setup matches the shared monorepo model, so you're already doing it the right way
one thing to know ; if you use per-service railway.toml files, the path to them must be absolute from the repo root, not relative to the service folder. railway docs explicitly say the config file does not follow the root directory setting
also worth setting watch paths per service so changes in app don't trigger unnecessary rebuilds of app2