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

4 months 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 white_check_mark emoji

- Runtime container: Missing workspace context files x emoji

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

## What We've Tried

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

2. white_check_mark emoji Added workspace files to watchPatterns

3. white_check_mark emoji Manual Railway Dashboard configuration (bypassed toml file)

4. white_check_mark emoji Switched from Nixpacks to Railpack

5. white_check_mark emoji Using pnpm exec instead of package.json scripts

6. white_check_mark emoji 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

4 months 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

4 months ago

## UPDATE: Confirmed Bug with railway up vs GitHub

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

white_check_mark emojirailway up (CLI upload):

x emojiGitHub 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" white_check_mark emoji

- GitHub: "Found workspace with 2 packages" white_check_mark emoji

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

4 months ago

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

Layer 1: TurboRepowhite_check_mark emoji Working correctly

  • Used for BUILD orchestration

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

Layer 2: pnpm Workspace Filterx emojiTHIS 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 Pipelinex emojiTHIS IS THE BUG

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

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

    ??

curiouskal
PROOP

4 months 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

4 months ago

Glad to hear!

Status changed to Awaiting User Response Railway • 4 months ago

Status changed to Solved sarahkb125 • 4 months ago

Status changed to Open sarahkb125 • 4 months ago

Loading...