a month ago
Project: khram-spas (ID c65ce4b9-3751-4e7e-a0e5-e16cc673e018), Service: khram-spas (ID a8a6b1ac-7189-4713-8868-0d69329ea5d3), env: production. Live URL: https://khram-spas-production.up.railway.app
SUMMARY
A specific subset of Next.js 16 (App Router, Turbopack) routes return HTTP 404 in production, even though:
- They're correctly listed in .next/server/app-paths-manifest.json
- The compiled route module (.next/server/app//{page,route}.js) exists on disk and require()s without error
- The build completes successfully (next build exits 0, no TS errors)
- Other routes in the same deployment work fine (200)
Not a caching issue: cache-control: private, no-cache, no-store, max-age=0, must-revalidate; cache-busting query string makes no difference. NIXPACKS_NO_CACHE=true already set.
AFFECTED (404 right now): GET /baptism, /api/baptism-slots, /api/debug-routes, /api/admin/run-migration
WORKING (same deployment): /book, /login, /psalter -> 200; /api/backup, /api/cron/reminders -> 401 (route resolves, just auth-gated); /api/telegram/webhook, /api/push/subscribe, /api/max/webhook -> 405 (POST-only, route resolves)
RULED OUT
- Browser/CDN caching (no-store headers, cache-buster tested)
- Nixpacks build cache (NIXPACKS_NO_CACHE=true already on)
- Route content/complexity - reproduced with a trivial page (app/test123/page.tsx, zero imports). Still 404s.
- Importing a 'use server' action into a Route Handler - inlined the query directly instead. Still 404s.
- Full git revert of ALL our session's changes back to a commit from 2026-06-19 (before we touched anything), rebuilt, redeployed - same 4 routes still 404, including two (/test123, /api/debug-routes) that are unrelated to our feature and were themselves diagnostic tools from a PAST debugging session weeks ago.
- General /api/* breakage - most other API routes work fine.
Via read-only railway ssh: app-paths-manifest.json correctly lists all 4 broken routes -> valid .js paths; those .js files exist with the same structure as working routes; require()-ing the route module directly works, no load error. Could not fully reproduce internally - the ssh session is a separate ephemeral container without production env vars (middleware throws a Supabase-env error there that never happens on the live site).
KEY FINDING - looks like a hard date cutoff, not a code issue
- /book (last touched 2026-06-12) and /psalter (last touched 2026-06-01) -> work today
- /baptism, /api/baptism-slots, /api/debug-routes, /test123 - ALL first added 2026-06-19 -> all 404
- No new route has been successfully added to this app since 2026-06-19, period. Every route from before that date still resolves; every route added on/after it 404s, regardless of commit or content.
This points to something changed 2026-06-19 in this service's routing/proxy/domain config on Railway's side (e.g. a route table snapshot not refreshed for new paths), not our Next.js code.
ADDITIONAL: railway domain list returns "No domains found for service khram-spas in environment production" - yet khram-spas-production.up.railway.app is actively serving traffic right now. The live domain may be orphaned from current domain-management tooling, which could explain why its route table isn't picking up new paths.
QUESTION
Manifest and build artifacts are demonstrably correct, but the live server 404s for this route subset regardless of content. Is there a known issue with how production resolves App Router routes on this pipeline (Nixpacks + Next 16 Turbopack)? Can support see logs/diagnostics from the actual live instance (not the ephemeral ssh container) showing why these routes fail to resolve despite a valid manifest? Happy to share deployment IDs / full build logs / temporary access.
9 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 2 months ago
a month ago
Hey! Which version of Nextjs are you using? There's a know issue with 16.2.9 or canary that looks similar to what you're experiencing, try upgrading to 16.3.
Another thing which is important to mention is that Nixpacks is deprecated, you should be using Railpack instead.
medim
Hey! Which version of Nextjs are you using? There's a know issue with 16.2.9 or canary that looks similar to what you're experiencing, try upgrading to 16.3. Another thing which is important to mention is that Nixpacks is deprecated, you should be using [Railpack](https://railpack.com/) instead.
a month ago
Hey! We're on Next.js 16.2.6. Upgrading to 16.3 now, will report back if the 404 issue is resolved.
medim
Hey! Which version of Nextjs are you using? There's a know issue with 16.2.9 or canary that looks similar to what you're experiencing, try upgrading to 16.3. Another thing which is important to mention is that Nixpacks is deprecated, you should be using [Railpack](https://railpack.com/) instead.
a month ago
Hey! We're on Next.js 16.2.6. I checked the registry — there's no stable 16.3.0 release yet, only canary/preview builds (latest stable is 16.2.10). Could you confirm which exact version/channel fixed this for you? Don't want to pin a prerelease build in production if avoidable.
a month ago
I was talking about upgrading to the preview version 16.3, but you can also try downgrading the version.
Issue link on github: https://github.com/vercel/next.js/issues/94802
medim
I was talking about upgrading to the preview version 16.3, but you can also try downgrading the version. Issue link on github: https://github.com/vercel/next.js/issues/94802
a month ago
Tried 16.3.0-preview.5 — no change, /baptism and /api/baptism-slots
still 404 while older routes (/book, /psalter, /login) work fine.
Also checked issue #94802 — that looks like a different, intermittent
issue (fixed by refresh), ours is a hard, consistent 404 for any route
added after ~June 19, regardless of code. Reverted back to stable
16.2.6 since the version wasn't the cause. Could you help look into
this from the platform side — possibly the production domain
(khram-spas-production.up.railway.app) or build manifest?
a month ago
I would suggest getting rid of Nixpacks and making sure you're on the latest stable version of node.
a month ago
Письмо в поддержку Railway (скопируй в тред):
Hi, following up with everything we've tried — none of it fixed
the issue, and I think I found the actual root cause.
What we tried (all deployed and tested on production):
-
Next.js version: upgraded from 16.2.6 to 16.3.0-preview.5,
redeployed, confirmed in build logs. /baptism and
/api/baptism-slots still 404. Reverted back to stable 16.2.6.
-
Builder: switched railway.json from "NIXPACKS" to "RAILPACK".
Build succeeded cleanly under Railpack. Still 404.
-
Node version: found a stale .nvmrc pinning Node 20, which
Railpack was honoring over our engines.node setting. Fixed
.nvmrc to 24.18.0 (latest LTS), confirmed Node 24 in the build
log. Still 404.
None of these changed anything — /baptism, /api/baptism-slots, and
/test123 (an old unrelated diagnostic route) are all still 404,
while /book, /psalter, and /login (routes that existed before
~June 19) work fine on the exact same deployment.
What I think is actually going on: I ran railway domain list and
it returns an empty list — but khram-spas-production.up.railway.app
is live right now and serving real traffic (200s on /book etc). So
the production domain isn't showing up in your domain management
system at all, even though it's actively routing requests. My guess
is this domain got orphaned from the current domain-management
system at some point, and it's still running on a frozen/stale
routing configuration that never picked up routes added after that
point — regardless of what we deploy.
I also tested this: created a brand new service domain
(railway domain), and it correctly synced (status: ACTIVE) but
returned 500 Internal Server Error on every route, including ones
that work fine on the old domain — possibly because the new domain
wasn't associated with a target port. I deleted the test domain
afterward.
Could someone on your end look at how
khram-spas-production.up.railway.app is currently attached to the
service? It seems to exist outside the normal domain management
flow. Happy to provide the deployment ID or any other details you
need.
a month ago
Have you tried deleting the stale domain through the dashboard instead of the CLI?
Does it show there? If it still doesn't shows on the service settings, can you try deleting and recreating the service?
medim
Have you tried deleting the stale domain through the dashboard instead of the CLI? Does it show there? If it still doesn't shows on the service settings, can you try deleting and recreating the service?
a month ago
Confirmed in the dashboard too — Settings → Networking → Public
Networking shows no domain at all for the service, only
"Generate Domain / Custom Domain / TCP Proxy" buttons. So it's not
a CLI-only issue — the Railway UI itself doesn't know about
khram-spas-production.up.railway.app, even though it's live and
serving real traffic right now.
Before we delete and recreate the whole service, I want to be
careful — that's a production system used by church staff daily,
and I need to make sure we can safely restore all environment
variables (Supabase, Telegram, Max bot tokens, cron secrets) before
taking it down. Is there a way to fix the domain attachment without
recreating the service? If not, we'll plan a maintenance window for
that.