Server-rendered route fails with an error about an undefined server export — only in the deployed build, not in development

The error naming an internal rather than your code is the useful clue: something in your dependency tree is reaching for a server rendering entry point that does not exist in the runtime the route is executing in.

There is more than one build of the renderer — one for Node, one for the edge-style runtime, one for the browser — and they export different things. Development runs one way and the deployed build another, which is exactly why this is invisible locally.

So there are three usual causes:

1. A dependency importing a server-only rendering module while the route runs in a restricted runtime. Some libraries import a server rendering entry directly to do markup generation. In the full Node runtime that resolves fine. In the lighter runtime it resolves to a build that does not export what the library expected, and you get an undefined property on an internal.

The fix is either to move the route to the Node runtime, or to stop that dependency being pulled into the server bundle.

2. Mismatched versions between the framework and the renderer. The framework depends on a specific renderer major version, and the internal entry points it uses are not stable across those versions. A transitive dependency pinning a different renderer version, or a resolution override someone added months ago, produces two copies in the tree. Development often tolerates this; the production build does not.

Check for duplicates explicitly — your package manager can list every version of a package in the tree. Seeing two is the answer.

3. A library that is not server-safe being rendered on the server. Common with older component libraries and anything touching the DOM at module scope.

Finding which part of the tree, which is what you actually asked:

• Bisect by commenting out. Blunt and reliable. Render the route with half the tree, deploy or build locally in production mode, and narrow. Two or three rounds usually finds it.
• Build in production mode locally. This is the single most valuable habit here: run the production build and start it locally rather than relying on the development server. Most of these errors reproduce immediately and you get a stack trace with a file path instead of a deployed error page.
• Read the build output. The build reports which runtime each route was compiled for. Confirm the failing route is on the runtime you think it is — the discrepancy is frequently the whole answer.
• Mark the offending dependency as external to the server bundle if you find it and it does not need bundling. The framework has a configuration option for this and it resolves a lot of these cases without moving the route.

On "clearing the cache did not help": correct, and that is informative. This is a resolution problem, not a stale artefact, so cache clearing was never going to change it. Worth ruling out early but do not spend a second round on it.

The duplicate-version case is worth checking first because it takes thirty seconds and it is more common than people think.

One library pinning a slightly different major of a peer dependency is enough. Your package manager can print the whole tree filtered to that package; if two versions appear, that is very likely your bug, and the fix is a resolution or override forcing a single version.

Be careful with overrides though — you are asserting compatibility on the library's behalf. Check the library actually supports the version you are forcing rather than just making the error go away.

The habit of running the production build locally is the one that pays for itself repeatedly, well beyond this error.

Development and production differ in bundling, tree shaking, environment variables, runtime selection and error handling. A meaningful fraction of "works locally, breaks deployed" is really "works in development mode, breaks in production mode", and that has nothing to do with the deployment platform at all.

Building and starting locally takes a minute and turns a deploy-and-wait loop into an immediate one. Worth adding as a script so it is one command.