Hello,

For a shared monorepo you do not want to be setting a root directory as your application will not be able to access data outside of that directory.

For shared monorepos you would want to leave your service(s) deploying from the root, and use filtered build and start commands to run individual packages within the shared monorepo.

Thank you.

We understand we should deploy from the root without setting a root directory. Could you confirm if this is the correct approach for our shared monorepo:

• Move the railway.toml to the root directory

• Remove the Dockerfile and use Railway's built-in Node.js builder

• Use commands like this in railway.toml:
  
  ```
  [build]

  builder = "nixpacks"

  buildCommand = "yarn workspace @wavenotes/shared build && yarn workspace @wavenotes/api build"

  [deploy]

  startCommand = "yarn workspace @wavenotes/api start"
  ```
  
  Also, should we keep our current watch patterns, or would you recommend a different approach for monitoring changes in a monorepo structure?
  
  Here are our current watch patterns from packages/api/railway.toml:
  watchPatterns = [

  # Match all files in api and shared packages

  "/packages/api/**/*",

  "/packages/shared/**/*",

  # Match specific config files

  "/package.json",

  "/yarn.lock",

  "/tsconfig*.json",

  "/packages/*/package.json",

  "/packages/*/tsconfig.json"

  ]
  
  These patterns are designed to:

  • Watch all files in the API and shared packages

  • Watch root-level package.json and yarn.lock

  • Watch all tsconfig files at root level

  • Watch package.json and tsconfig.json files in all package directories

Hello,

> Move the railway.toml to the root directory

Yes.

> Remove the Dockerfile and use Railway's built-in Node.js builder

Not if you don't want to, there's nothing wrong with using your own Dockerfile.

> Use commands like this in railway.toml:

Assuming you will only ever be running your API on Railway this is fine, but doing is like that prevents you from running other packages on Railway given you are hardcoding the build and start command in the repo, for the most versatility you would want only set the build and start commands in the service settings.

But you can also run your frontend on Railway! we run railway.com on Railway with great success and its a Next.JS app.

> should we keep our current watch patterns, or would you recommend a different approach for monitoring changes in a monorepo structure?

I'm not familiar with your project structure to say anything about that, but if it works, then I don't see any point in changing!

Ah, great. This is very helpful.

I have both an API and a Worker service – should I have separate railway.toml files for each in the root, or should I handle both in a single file?

I'll consider the frontend on railway as well, thanks!

My recommendation would be to omit the railway.toml file entirely and set the needed commands in the service settings.

Great. We're in the process of that, and now we're running into a new issue:

Question: When using a Dockerfile with Node.js 18-slim as the base image, why isn't corepack/yarn being persisted between RUN commands despite using corepack enable && corepack prepare yarn@stable --activate? Is there a recommended way to ensure Yarn is available throughout the build process when using multi-stage builds?

Context:
We're using Yarn workspaces, where our API service depends on a shared package that needs to be built first. (We've moved away from manual file copying to a workspace-based approach.)

Our Dockerfile uses a multi-stage build with node:18-slim, and we're trying to leverage Railway's cache mounts for both Yarn and TypeScript builds.

The issue occurs during the TypeScript compilation stage where Yarn commands fail with 'yarn: command not found', despite having installed it via corepack in an earlier RUN command. This is preventing us from building our workspace packages in sequence (@wavenotes/shared followed by @wavenotes/api).

Here's an example build error:

```
/bin/bash: line 1: yarn: command not found

Jan 25 13:24:45

✕ [stage-0 8/10] RUN --mount=type=cache,id=s/93639891-0c51-46aa-a652-efa751156ca8-node_modules/cache,target=/app/node_modules/.cache rm -rf packages/*/dist packages/*/tsconfig.tsbuildinfo && yarn workspace @wavenotes/shared tsc --build --verbose && yarn workspace @wavenotes/api tsc --build --verbose

process "/bin/bash -ol pipefail -c rm -rf packages/*/dist packages/*/tsconfig.tsbuildinfo && \\ yarn workspace @wavenotes/shared tsc --build --verbose && \\ yarn workspace @wavenotes/api tsc --build --verbose" did not complete successfully: exit code: 127

Jan 25 13:24:45

Dockerfile:24

Jan 25 13:24:45

-------------------

Jan 25 13:24:45

22 | # build phase

Jan 25 13:24:45

23 | COPY . /app/.

Jan 25 13:24:45

24 | >>> RUN --mount=type=cache,id=s/93639891-0c51-46aa-a652-efa751156ca8-node_modules/cache,target=/app/node_modules/.cache rm -rf packages/*/dist packages/*/tsconfig.tsbuildinfo && \ yarn workspace @wavenotes/shared tsc --build --verbose && \ yarn workspace @wavenotes/api tsc --build --verbose

Jan 25 13:24:45

25 |

Jan 25 13:24:45

26 |

Jan 25 13:24:45

-------------------

Jan 25 13:24:45

ERROR: failed to solve: process "/bin/bash -ol pipefail -c rm -rf packages/*/dist packages/*/tsconfig.tsbuildinfo && \\ yarn workspace @wavenotes/shared tsc --build --verbose && \\ yarn workspace @wavenotes/api tsc --build --verbose" did not complete successfully: exit code: 127

Jan 25 13:24:45

Error: Docker build failed
```

Please share your Dockerfile

Attached.

Can you try it without the cache mounts?

We're seeing that even after removing cache mounts from our Dockerfile, Railway appears to be injecting its own cache configuration (--mount=type=cache). Could this cache injection be affecting our environment setup, specifically the availability of Yarn between commands? We're still getting yarn: command not found despite installing it via corepack in an earlier stage.

Updated docker attached. We removed cache mounts from:
- # Install Dependencies
- # Build Packages

For reference here's the error in context:
```
[stage-0 8/10] RUN --mount=type=cache,id=s/93639891-0c51-46aa-a652-efa751156ca8-node_modules/cache,target=/app/node_modules/.cache rm -rf packages/*/dist packages/*/tsconfig.tsbuildinfo && yarn workspace @wavenotes/shared tsc --build --verbose && yarn workspace @wavenotes/api tsc --build --verbose

/bin/bash: line 1: yarn: command not found

✕ [stage-0 8/10] RUN --mount=type=cache,id=s/93639891-0c51-46aa-a652-efa751156ca8-node_modules/cache,target=/app/node_modules/.cache rm -rf packages/*/dist packages/*/tsconfig.tsbuildinfo && yarn workspace @wavenotes/shared tsc --build --verbose && yarn workspace @wavenotes/api tsc --build --verbose

process "/bin/bash -ol pipefail -c rm -rf packages/*/dist packages/*/tsconfig.tsbuildinfo && \\ yarn workspace @wavenotes/shared tsc --build --verbose && \\ yarn workspace @wavenotes/api tsc --build --verbose" did not complete successfully: exit code: 127

Dockerfile:24

-------------------

22 | # build phase

23 | COPY . /app/.

24 | >>> RUN --mount=type=cache,id=s/93639891-0c51-46aa-a652-efa751156ca8-node_modules/cache,target=/app/node_modules/.cache rm -rf packages/*/dist packages/*/tsconfig.tsbuildinfo && \ yarn workspace @wavenotes/shared tsc --build --verbose && \ yarn workspace @wavenotes/api tsc --build --verbose

25 |

26 |

-------------------

ERROR: failed to solve: process "/bin/bash -ol pipefail -c rm -rf packages/*/dist packages/*/tsconfig.tsbuildinfo && \\ yarn workspace @wavenotes/shared tsc --build --verbose && \\ yarn workspace @wavenotes/api tsc --build --verbose" did not complete successfully: exit code: 127

Error: Docker build failed
```

I've been using Railway for many years, so I'm confident in saying that Railway will not inject cache mounts into the Dockerfile if its using your Dockerfile.

If there are cache mounts after using a Dockerfile it would be because your Dockerfile includes them.

Thanks, we dealt with the cache mounts.

Now, we're encountering an issue with Yarn 3.6.4 workspaces in our Dockerfile build. While yarn workspaces list correctly shows all workspaces (including our shared package), subsequent workspace commands fail with "Internal Error: @wavenotes/shared@workspace:.: This package doesn't seem to be present in your lockfile". This happens despite:

> 1. Running yarn install --no-immutable followed by yarn install --immutable

> 2. Explicitly updating the lockfile with yarn install --mode update-lockfile

> 3. Having the workspace dependency correctly declared in package.json ("@wavenotes/shared": "workspace:*")

Is there something specific about Railway's build environment that might affect how Yarn 3 handles workspace references in the lockfile?

Railway's build system doesn't have anything out of the ordinary going for it, your build is done with buildkit.

I'm able to get my dockerfile to build locally, but when I try to build on Railway I get this error: The executable `cd` could not be found.

I have attached my dockerfile and package.json. Any ideas?

That would be a completely separate issue, please open a new thread.