I run a small AI product on a single cheap VM, deploying it myself. One morning the homepage started throwing 500s — not always, just sometimes. The admin pages were fine. The CSS was fine. Only some routes died, and only in production.

The error in the PM2 logs was this:

Error: Could not find the module
"/tmp/riel_agent_build/src/app/page.tsx#default"
in the React Client Manifest.
This is probably a bug in the React Server Components bundler.

"Probably a bug in the bundler." It wasn't. It was me. If you're self-hosting Next.js 14 (App Router / RSC) and seeing this, here's what's actually happening — and it took me far too long to see it.

The setup that caused it

My deploy script did something that looks perfectly reasonable:

1. Build the app in a scratch directory: /tmp/riel_agent_build
2. Keep the old, running .next untouched during the build (zero downtime)
3. When the build succeeds, swap just the new .next into the live app directory /home/me/app/riel_agent

Build somewhere safe, then move only the output. Classic atomic deploy. The problem is that one of those build artifacts is not relocatable.

The real cause: RSC bakes an absolute path into the client manifest

In the Next.js App Router, React Server Components need a client manifest — a map that tells the server which client module to hydrate for each "use client" boundary. In Next.js 14, the keys in that manifest are written using the absolute path of the directory the build ran in (the build CWD).

So when I built in /tmp/riel_agent_build, the manifest was full of keys like:

/tmp/riel_agent_build/src/app/page.tsx#default

Then I moved .next to /home/me/app/riel_agent and started the server from there. At runtime, Next resolves modules relative to the real CWD — /home/me/app/riel_agent/... — but the manifest is still pointing at /tmp/riel_agent_build/.... The two no longer match. For any route that crosses a server→client boundary, the lookup fails:

Could not find the module /tmp/riel_agent_build/... in the React Client Manifest.

Why "only sometimes"? Because routes with no client component (or that were statically pre-rendered) don't hit the manifest at all. Pure-static pages render fine; the moment a route needs to hydrate a client boundary at request time, it 500s. That's why my admin pages looked healthy while the homepage flickered between working and broken.

The tell is right there in the error string: it's an absolute path that is not where your app actually lives. If you ever see /home/runner/... (GitHub Actions) or /tmp/... in this error, you have the exact same disease. (I had previously hit the /home/runner version of this and "fixed" it by moving the build to /tmp — i.e. I moved the bug, not removed it.)

The fix: build in place, into a sibling output dir

The relocation was the whole problem, so the fix is to never relocate. Build with the real app directory as the CWD, and only redirect the output folder, not the working directory.

Next.js already supports this. next.config.js reads the dist dir from an env var:

// next.config.js
module.exports = {
  distDir: process.env.NEXT_DIST_DIR || ".next",
  // ...
};

So the deploy becomes:

cd /home/me/app/riel_agent           # real CWD — same as runtime

# build into a NEW folder, leaving the live .next serving traffic
rm -rf node_modules/.cache           # drop any path-polluted cache
NEXT_DIST_DIR=.next.new npx next build

# sanity-check the output before swapping (see guard below)

# atomic swap
mv .next .next.previous
mv .next.new .next
pm2 reload riel_agent

Now the manifest keys are written as /home/me/app/riel_agent/... — which is exactly where the server runs from. The paths match, the 500s stop, and I still get a zero-downtime swap because the old .next keeps serving until the very last mv.

Two details that matter:

• Clear node_modules/.cache. Webpack/Next caches can carry the old build path forward and reintroduce the mismatch. A poisoned cache will happily rebuild the wrong absolute paths.
• The old .next stays live during the build. Because you're building into .next.new, the running app never loses its .next. The only moment of change is the mv, which is atomic on the same filesystem.

The guard rail I added so it can never ship silently again

A deploy that produces a technically successful build but a broken manifest is the worst kind — it passes "did the build exit 0?" and still takes the site down. So I added a dumb, deterministic check before the swap: grep the new server output for any path that isn't the real app directory.

# after building into .next.new, before swapping
if grep -rqE '/tmp/|/home/runner/' .next.new/server; then
  echo "FATAL: foreign build path leaked into manifest — refusing to swap"
  exit 1
fi

If any /tmp/... or /home/runner/... string made it into the server bundle, the deploy refuses to swap and the previous build keeps running. No LLM judgment, no heuristics — just a string match for "this build was made somewhere it shouldn't have been."

The lesson

The interesting part isn't the Next.js trivia. It's that a build artifact had a hidden dependency on its own location, and my "safe" deploy strategy quietly violated it. The error blamed the bundler; the real bug was an assumption in my pipeline — "build output is relocatable" — that happened to be false for exactly one file.

When a green build still breaks production, stop trusting "it compiled" and look for the thing that's environment-specific: an absolute path, a baked-in env var, a cache. The fix is rarely more code. It's removing the assumption.

I'm building aicoreutility.com in the open — a full AI product run by one person on one small VM. Most of what I write here is the unglamorous infrastructure that broke first. This one cost me a morning of 500s.