Hello Railway Support,

I am troubleshooting a deployment issue for a Node.js monorepo application and would appreciate your help confirming whether anything in Railway’s build or deploy environment could be contributing to this behavior.

The deployment starts the container and begins application initialization, but then crashes repeatedly with the following runtime error:

Error: Cannot find module '/app/artifacts/api-server/dist/thread-stream-worker.mjs'

A few important details:

The app is deployed with Docker and uses a final runtime path of /app/artifacts/api-server.

The startup command is:

node --enable-source-maps dist/index.mjs

The container starts far enough to show application initialization logs, then fails when a worker-thread related path appears to initialize.

We discovered that the built artifact had previously included bundled pino/thread-stream worker path overrides, which may have baked in build-time paths. We have been updating the build pipeline to externalize pino-related runtime dependencies and remove those bundled worker references.

What I need help confirming is:

Is Railway definitely deploying the newest Docker image layers after rebuild, or could an older cached artifact still be getting reused?

Is there any Railway-specific caching, build-layer reuse, or deployment behavior that could cause an outdated generated dist/index.mjs artifact to persist even after code changes?

Is there a recommended way in Railway to force a truly clean rebuild and redeploy of the container image?

If helpful, here is the recurring runtime error pattern we see in logs:

Error: Cannot find module '/app/artifacts/api-server/dist/thread-stream-worker.mjs'

The issue does not reproduce the same way in our Replit environment, which is why I am trying to rule out any container caching or deployment-image reuse on Railway’s side.

Any guidance on forcing a clean image rebuild, validating deployed image freshness, or checking whether Railway is reusing stale build layers would be appreciated.

Thank you.