TurboRepo deployment: railway up works, GitHub deployment fails with "No projects matched the filters"
curiouskal
PROOP

a month ago

Starting Container

> storefront-v2@0.1.0 start /app/apps/storefront-v2

> next start -p ${PORT:-3000} -H 0.0.0.0

▲ Next.js 14.2.15

✓ Ready in 368msCause Analysis

The issue appears to be that Railway's GitHub deployment pipeline creates different containers for build vs runtime:

- Build container: Has access to pnpm-workspace.yaml and workspace metadata

- Runtime container: Missing workspace context files

Meanwhile, railway up packages the entire local workspace into a single container context that persists to runtime.

## What We've Tried

1. Multiple filter syntaxes --filter=./apps/storefront-v2, --filter=storefront-v2)

2. Added workspace files to watchPatterns

3. Manual Railway Dashboard configuration (bypassed toml file)

4. Switched from Nixpacks to Railpack

5. Using pnpm exec instead of package.json scripts

6. Verified all workspace files committed to git

All attempts produce identical failure at runtime.

## Expected Behavior

GitHub deployments should work identically to railway up deployments when using the same configuration. TurboRepo + pnpm workspaces is a standard modern setup that should work out of the box.

## Question

Is there a known issue with pnpm workspace metadata not being copied to runtime containers in GitHub deployments? Or is there additional configuration needed to preserve workspace context from build to runtime?

## Reproduction

1. Create monorepo with pnpm workspaces + TurboRepo

2. Configure Railway service with build command using --filter

3. Deploy via GitHub → fails with "No projects matched the filters"

4. Deploy same code via railway up → succeeds

## Additional Context

- Working commit (via railway up): a491fb15-1426-4463-a5c5-0c6e6e516553

- Failed commit (via GitHub): 9a15cf3c-b81f-4d1c-95f1-6257af7c1acd

- Both use identical configuration

- Debugging document: [Available upon request]

$20 Bounty

5 Replies

Railway
BOT

a month ago

Hey there! We've found the following might help you get unblocked faster:

If you find the answer from one of these, please let us know by solving the thread!

curiouskal
PROOP

a month ago

## UPDATE: Confirmed Bug with railway up vs GitHub

Just tested railway up with the EXACT same configuration that fails with GitHub push:

railway up (CLI upload):

GitHub Push (same config):

Configuration used (identical for both):

- Build: pnpm install --frozen-lockfile && pnpm exec turbo run build --filter=./apps/storefront-v2

- Start: pnpm --filter=storefront-v2 exec next start -p ${PORT:-3000} -H 0.0.0.0

- Builder: Railpack 0.9.1

Railpack detects workspace during build:

- railway up: "Found workspace with 3 packages"

- GitHub: "Found workspace with 2 packages"

Both builds succeed, but only railway up can resolve workspace at runtime.

This confirms the issue: Railway's GitHub deployment pipeline does not preserve workspace metadata files (pnpm-workspace.yaml, root package.json) in the runtime container, while railway up does.

curiouskal
PROOP

a month ago

Here's my current understanding: (is this correct or not correct??):
THE CORE PROBLEM

Layer 1: TurboRepo Working correctly

  • Used for BUILD orchestration

  • Not used for START (by design - start doesn't need orchestration)

Layer 2: pnpm Workspace FilterTHIS IS THE PROBLEM

  • Used for START command

  • Requires pnpm-workspace.yaml + root package.json at RUNTIME

  • Railway's GitHub pipeline doesn't preserve these in runtime container

Layer 3: Railway Deployment PipelineTHIS IS THE BUG

  • railway up: Packages entire workspace → runtime has all files

  • GitHub: Creates separate build/runtime containers → runtime missing workspace files

    ??

curiouskal
PROOP

a month ago

Hi Railway team,

We've resolved the issue - turns out it was a Git configuration problem on our end, not a Railway bug.

Root cause: Our apps/storefront-v2 directory was stuck as a "ghost submodule" in Git's index (mode 160000) even though it wasn't actually a submodule. This caused Git to not track file changes properly, so Railway was deploying stale/incomplete files from GitHub.

Fix: Removed the submodule entry from Git cache and re-added as a regular directory. GitHub deployments now work perfectly.

Apologies for the false alarm - Railway was working correctly the whole time. You can close this ticket.

Thanks!

sarahkb125
EMPLOYEE

a month ago

Glad to hear!

Status changed to Awaiting User Response Railway • about 2 months ago

Status changed to Solved sarahkb125 • about 2 months ago

Status changed to Open sarahkb125 • about 2 months ago

Loading...