Troubleshooting Preview Page Errors in Uniform: Canvas Preview Crashes on Vercel ("Failed to load external module")

Last updated: July 28, 2026

Overview

When you open Canvas preview or in-context editing, the page fails to load and your preview endpoint (/api/preview) returns a 500 Internal Server Error. In your hosting provider's function logs you'll see an error similar to this:

[error] Failed to handle /api/preview/?secret=...&is_incontext_editing_mode=true

Error: Failed to load external module @uniformdev/canvas-next-9df04c9fc56eb9ca:

Error: Cannot find module 'next/dist/compiled/next-server/pages-turbo.runtime.prod.js'

Require stack:

- /var/task/node_modules/.pnpm/next@.../node_modules/next/dist/server/route-modules/pages/module.compiled.js

- .../next/dist/client/link.js

at Context.externalImport [as y] (.next/server/chunks/[turbopack]_runtime.js:...)

The exact module hash (@uniformdev/canvas-next-9df04c9fc56eb9ca) will differ on every build, and the "external module" may be any @uniformdev/* package used by your preview route — most commonly @uniformdev/canvas-next. The tell-tale part is Cannot find module 'next/dist/compiled/next-server/pages-turbo.runtime.prod.js'.

This applies to you if:

  • You use the Next.js Pages Router and set up preview with createPreviewHandler from @uniformdev/canvas-next (typically in pages/api/preview.js or pages/api/preview.ts).

  • You are on Next.js 16.1.0 or later (see the Next.js version note below — 16.0.x and earlier are not affected).

  • Your project is built with Turbopack (the default next build on recent Next.js versions).

  • You deploy to Vercel (or another platform that runs your site as serverless/lambda functions with file-tracing).

The preview page renders fine locally but crashes only on the deployed environment.

Why this happens

When building with Turbopack, Next.js can treat @uniformdev/canvas-next as an external module that is loaded lazily at runtime rather than bundled into your preview function. That external module depends on an internal Next.js server chunk (pages-turbo.runtime.prod.js).

When the function is packaged for deployment, the platform's file-tracing step decides which files to ship in the serverless bundle. Turbopack references the externalized package through a build-specific hashed alias — the @uniformdev/canvas-next-9df04c9fc56eb9ca you see in the error — which resolves locally through symlinks in .next/node_modules but does not survive into Vercel's serverless artifact. The internal Next.js server chunk it needs (pages-turbo.runtime.prod.js) isn't traced either, because nothing bundled directly references it. So at runtime the require fails, and /api/preview returns a 500.

This is a known Next.js/Turbopack behavior, tracked in several upstream issues (listed under References at the end of this article). It is not specific to Uniform — the same failure appears with other externalized packages such as pino, styled-components, and @aws-sdk/client-s3.

Next.js version

This failure mode was introduced with Next.js 16.1.0 — it first appears in the 16.1.0-canary.3 build (#86652, #87686). Next.js 16.0.x and earlier are not affected. It continues to affect the 16.1.x and 16.2.x lines (the original report was on next@16.2.9). It only occurs with Turbopack builds; the classic Webpack compiler externalizes packages differently and does not hit this specific error (though it has its own problems — see step 3).

A note on package managers: This is aggravated by pnpm, whose symlinked, non-flat node_modules layout is exactly the structure that makes Turbopack's hashed aliases fail to resolve after deployment (#87737, #68805, #93849). It is not exclusive to pnpm, however — the same crash has been reproduced under the Bun runtime and under npm when a prebuilt .next folder is deployed without reinstalling. Because the fix below removes the external reference entirely, it works regardless of which package manager you use.

You may see two variants of this:

  • Intermittent / one-off: Preview worked, then suddenly started failing (often right after other deploys). This is frequently a stale or corrupted build cache being restored from a previous deployment. A clean redeploy usually clears it.

  • Persistent: Preview fails on every deploy. This needs the configuration change below to fix permanently.

Resolution Steps

1. Try a clean redeploy first (for intermittent failures)

If preview was working and only recently broke, rule out a stale build cache before changing any code.

On Vercel:

  1. Open your project → Deployments tab.

  2. Find the most recent production deployment and click the ⋯ (three-dot) menu.

  3. Click Redeploy.

  4. In the dialog, uncheck "Use existing Build Cache."

  5. Click Redeploy and wait for it to finish.

(CLI/CI equivalents: vercel --force, or set the environment variable VERCEL_FORCE_NO_BUILD_CACHE=1.)

Then re-test your preview link. If the error is gone and doesn't return, you're done. If it comes back — or preview fails on every deploy — apply the permanent fix in step 2.

2. Bundle the dependency in next.config (permanent fix — recommended)

Tell Next.js to bundle your Pages Router dependencies (including @uniformdev/canvas-next) directly into the function at build time, instead of loading them as runtime externals. With the dependency bundled in, the missing-chunk crash can't happen.

Add bundlePagesRouterDependencies: true to your Next.js config.

next.config.js (CommonJS):

/** @type {import('next').NextConfig} */

const nextConfig = {

// Bundle Pages Router dependencies (e.g. @uniformdev/canvas-next) into the

// serverless function instead of loading them as runtime externals.

bundlePagesRouterDependencies: true,

};

module.exports = nextConfig;

next.config.ts (TypeScript):

import type { NextConfig } from 'next';

const nextConfig: NextConfig = {

bundlePagesRouterDependencies: true,

};

export default nextConfig;

Commit the change and redeploy. You can leave Turbopack enabled — this fix does not require switching bundlers.

Note: bundlePagesRouterDependencies bundles all server-side Pages Router dependencies. If a specific package must stay external (for example, one with native binaries), keep it out of the bundle by listing it in the serverExternalPackages option. In the vast majority of cases you won't need this.

Webpack as a workaround may not work

Building with the classic Webpack compiler (e.g. next build --webpack) introduce a separate, reproducible crash instead — require is not defined, thrown by every component loaded with next/dynamic().

We recommend keeping Turbopack on and use the bundlePagesRouterDependencies option in step 2.

Verify and prevent

  1. After redeploying, open your preview / in-context editing link and confirm the page renders.

  2. Confirm /api/preview now returns 200 instead of 500 (check your function logs).

  3. Click through a few pages / client-side navigations to make sure nothing else regressed.

To catch a regression early, consider adding an uptime/health check (for example, a Checkly monitor) that periodically requests your preview URL and alerts you if it starts returning a 500.

Additional Support

If issues persist after trying this and the other preview troubleshooting guides, please contact Uniform support for further assistance. When you reach out, include your framework and Next.js version, whether you build with Turbopack or Webpack, your hosting provider, and the full server-side error from your function logs.

References

This is an upstream Next.js/Turbopack behavior. The following issues in the vercel/next.js repository track it and confirm the root cause and version range: