Next.js 16.1 build fails with EEXIST error: Turbopack creates symlinks in .next/node_modules that Amplify bundler cannot handle

[yamaaaaaa31]

Environment

• Hosting: AWS Amplify
• Framework: Next.js 16.1.0
• Node.js version: 22.x
• Package manager: pnpm 10.26.1
• Region: ap-northeast-1

Describe the bug

When deploying a Next.js 16.1.0 application to AWS Amplify, the build succeeds but the bundling phase fails with an EEXIST error related to symlinks in .next/node_modules/.

Root Cause

Next.js 16.1 introduced changes to Turbopack's module resolution that creates hashed symlinks in the .next/node_modules/ directory during the build process.

For example:

.next/node_modules/pino-3de069a0e16ae0ec -> ../../node_modules/pino

This behavior change was introduced between Next.js 16.0.10 and 16.1.0 (see vercel/next.js#87402 for similar Turbopack symlink issues).

AWS Amplify's bundler cannot handle these symlinks properly, causing EEXIST errors when it attempts to create directories that conflict with existing symlinks during the compute bundle process.

Note: This may be related to the Improved Handling of serverExternalPackages feature in Next.js 16.1, which enhanced Turbopack's handling of transitive dependencies.

Build Logs

2025-12-19T16:24:11.137Z [INFO]: # Starting caching...
2025-12-19T16:24:11.142Z [INFO]: # Creating cache artifact...
2025-12-19T16:24:11.146Z [INFO]: # Created cache artifact
2025-12-19T16:24:11.147Z [INFO]: # Uploading cache artifact...
2025-12-19T16:24:11.253Z [INFO]: # Uploaded cache artifact
2025-12-19T16:24:11.253Z [INFO]: # Caching completed
2025-12-19T16:24:31.471Z [ERROR]: !!! We failed to bundle your application due to an unexpected error. Please try again. If the issue persists, please contact AWS support.
2025-12-19T16:24:31.591Z [ERROR]: !!! Error: EEXIST: file already exists, mkdir '/codebuild/output/src210259080/src/****/frontend/amplify-compute-bundle-output/compute/default/.next/node_modules/pino-3de069a0e16ae0ec'
2025-12-19T16:24:31.592Z [INFO]: # Starting environment caching...
2025-12-19T16:24:31.592Z [INFO]: # Environment caching completed

Expected behavior

Amplify's bundler should correctly handle symlinks created by Next.js 16.1+ Turbopack, or dereference them during the bundling process.

Steps to reproduce

1. Create a Next.js 16.1.0 application (Turbopack is enabled by default)
2. Include a package that Turbopack externalizes (e.g., pino, jsdom, or other native modules)
3. Deploy to AWS Amplify
4. Build succeeds, but bundling phase fails with EEXIST error

Workaround

We resolved this by adding a post-build script that resolves symlinks to actual directories before Amplify's bundler runs.

amplify.yml:

version: 1
applications:
  - appRoot: frontend
    frontend:
      phases:
        preBuild:
          commands:
            - corepack enable
            - pnpm install --frozen-lockfile
        build:
          commands:
            - pnpm build
            # Next.js 16.1 Turbopack creates hashed symlinks that Amplify can't handle
            - node scripts/resolve-next-symlinks.js
      artifacts:
        baseDirectory: .next
        files:
          - "**/*"
      cache:
        paths:
          - node_modules/**/*
          - .next/cache/**/*

scripts/resolve-next-symlinks.js:

/**
 * Next.js 16.1 Turbopack Symlink Resolver for AWS Amplify
 *
 * Next.js 16.1's Turbopack creates hashed symlinks for externalized packages
 * (e.g., pino-3de069a0e16ae0ec -> ../../node_modules/pino)
 *
 * AWS Amplify's bundler cannot handle these symlinks properly, causing
 * "EEXIST: file already exists" errors during deployment.
 *
 * This script resolves symlinks to real directories and copies their dependencies.
 */

const fs = require('fs');
const path = require('path');

const nextModules = path.join(__dirname, '..', '.next', 'node_modules');
const rootModules = path.join(__dirname, '..', 'node_modules');

function resolveDependencyPath(depName, parentPkgPath) {
  const directPath = path.join(rootModules, depName);
  try {
    const stat = fs.lstatSync(directPath);
    if (stat.isSymbolicLink()) {
      return fs.realpathSync(directPath);
    }
    if (stat.isDirectory()) {
      return directPath;
    }
  } catch {
    // Not found at root level
  }

  // For pnpm's isolated mode, check the parent package's node_modules
  if (parentPkgPath) {
    const parentNodeModules = path.dirname(parentPkgPath);
    const pnpmDepPath = path.join(parentNodeModules, depName);
    try {
      const stat = fs.lstatSync(pnpmDepPath);
      if (stat.isSymbolicLink()) {
        return fs.realpathSync(pnpmDepPath);
      }
      if (stat.isDirectory()) {
        return pnpmDepPath;
      }
    } catch {
      // Not found in parent's node_modules
    }
  }

  return null;
}

function copyPackageWithDeps(pkgPath, destPath, copiedSet, originalPkgPath) {
  const pkgName = path.basename(destPath);

  if (copiedSet.has(pkgName)) {
    return 0;
  }

  copiedSet.add(pkgName);

  console.log(`  Copying: ${pkgName}`);
  fs.cpSync(pkgPath, destPath, { recursive: true, dereference: true });
  let count = 1;

  const pkgJsonPath = path.join(destPath, 'package.json');
  if (fs.existsSync(pkgJsonPath)) {
    const pkg = JSON.parse(fs.readFileSync(pkgJsonPath, 'utf8'));
    const deps = Object.keys(pkg.dependencies || {});

    for (const dep of deps) {
      const depDest = path.join(nextModules, dep);

      if (!fs.existsSync(depDest) && !copiedSet.has(dep)) {
        const depSrc = resolveDependencyPath(dep, originalPkgPath || pkgPath);
        if (depSrc) {
          count += copyPackageWithDeps(depSrc, depDest, copiedSet, depSrc);
        } else {
          console.log(`  Warning: Could not find dependency ${dep}`);
        }
      }
    }
  }

  return count;
}

function main() {
  if (!fs.existsSync(nextModules)) {
    console.log('No .next/node_modules directory found, skipping.');
    return;
  }

  const entries = fs.readdirSync(nextModules);
  let resolved = 0;
  const copiedSet = new Set();

  for (const name of entries) {
    const linkPath = path.join(nextModules, name);
    const stat = fs.lstatSync(linkPath);

    if (stat.isSymbolicLink()) {
      const target = fs.realpathSync(linkPath);
      console.log(`Resolving: ${name} -> ${target}`);

      fs.rmSync(linkPath);
      copyPackageWithDeps(target, linkPath, copiedSet, target);
      resolved++;
    }
  }

  console.log(`\nResolved ${resolved} symlinks, copied ${copiedSet.size} packages total.`);
}

main();

Suggested Fix

AWS Amplify should either:

1. Dereference symlinks during bundling - Use --dereference or equivalent when copying/bundling the .next directory
2. Update the bundler to properly handle symlinks created by modern build tools like Turbopack
3. Document this limitation for Next.js 16.1+ users until a fix is available

Related Issues

• vercel/next.js#87402 - Turbopack symlink creation issue in Next.js 16.1 (Windows)
• aws-amplify/amplify-js#14600 - Next.js 16 Support request

Additional Context

• This affects any Next.js 16.1+ project where Turbopack externalizes packages (e.g., pino, jsdom, native modules)
• The issue is specific to AWS Amplify's bundler, not the Next.js build itself
• The Next.js build completes successfully; the failure occurs during Amplify's compute bundle phase
• The workaround works for npm, yarn, and pnpm package managers
• Turbopack is enabled by default in Next.js 16, so this will affect most Next.js 16.1+ deployments

[kachkaev]

Still seeing a problem in Next.js 16.1.1 (where a symlink-related issue fixed for Windows: vercel/next.js#87606).

Getting this error after next build:

2025-12-23T10:20:22.486Z [ERROR]: !!! CustomerError: The size of the build output (452346123) exceeds the max allowed size of230686720 bytes. Please reduce the size of your build output and try again.

So it is reported that our next app weights 450+MB which seems quite far from truth. Builds with Next.js 16.0.10 work just fine. Incorrectly reported size may be the result of some symlinks, but not 100% sure.

We use pnpm with nodeLinker: hoisted (no symlinks to central store).

[bgw]

I think the symlink creation for serverExternalPackages is the root cause. Prior to 16.1, Next.js didn't write any symlinks when performing tracing. After 16.1 it does.

This is the same root cause that caused the Windows privilege errors, but that was due to a plaform-specific quirk in Windows that should not impact AWS Amplify. So the fix in 16.1.1 is unrelated.

It's likely that Amplify's adapter just doesn't know how to process symlinks, because that codepath wasn't exercised before now. We're happy to help on the Next.js side if needed, but I think this would need to be fixed on the AWS Amplify side.

The changes in 16.1 are mostly performance improvements to Turbopack. If 16.0 is working for you, please feel free to roll back to 16.0 until this is sorted out!
(we very much appreciate the bug reports and feedback though)

[yamaaaaaa31]

Thanks @bgw for the analysis and @kachkaev for the additional report!

Agree — this should be fixed on the Amplify side. The symlink behavior in Next.js 16.1+ is intentional for serverExternalPackages.

I've shared a workaround script in the issue description that works for us. Happy to improve it if anyone runs into edge cases.

[andrejpavlovic]

@yamaaaaaa31 Thanks for the workaround! It worked almost perfect, but it misses nested packages such as @prisma/client. I asked AI to adjust the script to account for nested packages and now it's working perfectly. Thanks again!

Here's the updated script:

resolve-next-symlinks.js

/**
 * Next.js 16.1 Turbopack Symlink Resolver for AWS Amplify
 *
 * Next.js 16.1's Turbopack creates hashed symlinks for externalized packages
 * (e.g., pino-3de069a0e16ae0ec -> ../../node_modules/pino)
 *
 * AWS Amplify's bundler cannot handle these symlinks properly, causing
 * "EEXIST: file already exists" errors during deployment.
 *
 * This script resolves symlinks to real directories and copies their dependencies.
 */

import fs from 'fs';
import path from 'path';
import { fileURLToPath } from 'url';

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

const nextModules = path.join(__dirname, '..', '.next', 'node_modules');
const rootModules = path.join(__dirname, '..', 'node_modules');

function resolveDependencyPath(depName, parentPkgPath) {
  const directPath = path.join(rootModules, depName);
  try {
    const stat = fs.lstatSync(directPath);
    if (stat.isSymbolicLink()) {
      return fs.realpathSync(directPath);
    }
    if (stat.isDirectory()) {
      return directPath;
    }
  } catch {
    // Not found at root level
  }

  // For pnpm's isolated mode, check the parent package's node_modules
  if (parentPkgPath) {
    const parentNodeModules = path.dirname(parentPkgPath);
    const pnpmDepPath = path.join(parentNodeModules, depName);
    try {
      const stat = fs.lstatSync(pnpmDepPath);
      if (stat.isSymbolicLink()) {
        return fs.realpathSync(pnpmDepPath);
      }
      if (stat.isDirectory()) {
        return pnpmDepPath;
      }
    } catch {
      // Not found in parent's node_modules
    }
  }

  return null;
}

function copyPackageWithDeps(pkgPath, destPath, copiedSet, originalPkgPath) {
  const pkgName = path.relative(nextModules, destPath);

  if (copiedSet.has(pkgName)) {
    return 0;
  }

  copiedSet.add(pkgName);

  console.log(`  Copying: ${pkgName}`);
  fs.cpSync(pkgPath, destPath, { recursive: true, dereference: true });
  let count = 1;

  const pkgJsonPath = path.join(destPath, 'package.json');
  if (fs.existsSync(pkgJsonPath)) {
    const pkg = JSON.parse(fs.readFileSync(pkgJsonPath, 'utf8'));
    const deps = Object.keys(pkg.dependencies || {});

    for (const dep of deps) {
      const depDest = path.join(nextModules, dep);

      if (!fs.existsSync(depDest) && !copiedSet.has(dep)) {
        const depSrc = resolveDependencyPath(dep, originalPkgPath || pkgPath);
        if (depSrc) {
          count += copyPackageWithDeps(depSrc, depDest, copiedSet, depSrc);
        } else {
          console.log(`  Warning: Could not find dependency ${dep}`);
        }
      }
    }
  }

  return count;
}

function main() {
  if (!fs.existsSync(nextModules)) {
    console.log('No .next/node_modules directory found, skipping.');
    return;
  }

  const entries = fs.readdirSync(nextModules);
  let resolved = 0;
  const copiedSet = new Set();

  for (const name of entries) {
    const linkPath = path.join(nextModules, name);
    const stat = fs.lstatSync(linkPath);

    if (stat.isSymbolicLink()) {
      const target = fs.realpathSync(linkPath);
      console.log(`Resolving: ${name} -> ${target}`);

      fs.rmSync(linkPath);
      copyPackageWithDeps(target, linkPath, copiedSet, target);
      resolved++;
    } else if (stat.isDirectory() && name.startsWith('@')) {
      const scopeEntries = fs.readdirSync(linkPath);
      for (const scopeName of scopeEntries) {
        const scopeLinkPath = path.join(linkPath, scopeName);
        const scopeStat = fs.lstatSync(scopeLinkPath);

        if (scopeStat.isSymbolicLink()) {
          const target = fs.realpathSync(scopeLinkPath);
          console.log(`Resolving: ${name}/${scopeName} -> ${target}`);

          fs.rmSync(scopeLinkPath);
          copyPackageWithDeps(target, scopeLinkPath, copiedSet, target);
          resolved++;
        }
      }
    }
  }

  console.log(`\nResolved ${resolved} symlinks, copied ${copiedSet.size} packages total.`);
}

main();

[kachkaev]

I tried the above script but it did not resolve the issue for me. Although symlinks copy without errors, the resulting .next/node_modules folders becomes so large that Amplify can no longer deploy it:

The size of the build output (945923853) exceeds the max allowed size of 230686720 bytes

(945 MB vs 230 MB max)

Here is what've been getting previously when on 16.0.10 (Turbopack):

rm -rf .next
pnpm build

du -hs .next
echo "----"
du -hs .next/* | grep 'M[[:space:]]'

↓

387M    .next
----
 76M    .next/server
142M    .next/standalone
168M    .next/static

The total size of the .next folder is greater than Amplify's limit but it seems to be fine with it. I guess it's because Amplify only takes standalone parts of the output and maybe compresses everything before measuring size.

Just changing the version to 11.1.1 puts me here:

390M    .next
----
 77M    .next/server
144M    .next/standalone
168M    .next/static

Not much of a change so far, .next/node_modules is 0B (just symlinks). If I dereference symlinks with the script, I end up here:

1.1G    .next
----
712M    .next/node_modules
 77M    .next/server
144M    .next/standalone
168M    .next/static

And such amount of build artifacts produces the error:

The size of the build output (945923853) exceeds the max allowed size of 230686720 bytes

If I don't dereference symlinks in .next/node_modules, the error is still there for Next.js 16.1.1:

The size of the build output (452346123) exceeds the max allowed size of 230686720 bytes

Our app is an enterprise SAAS which is not too massive, but is also not a 'hello world' deployment. If anyone has ideas on how else to upgrade, happy to try them out.

[nmb0032]

I tried the above script but it did not resolve the issue for me. Although symlinks copy without errors, the resulting .next/node_modules folders becomes so large that Amplify can no longer deploy it:

The size of the build output (945923853) exceeds the max allowed size of 230686720 bytes

(945 MB vs 230 MB max)

Here is what've been getting previously when on 16.0.10 (Turbopack):

rm -rf .next
pnpm build

du -hs .next
echo "----"
du -hs .next/* | grep 'M[[:space:]]'

↓

387M    .next
----
 76M    .next/server
142M    .next/standalone
168M    .next/static

The total size of the .next folder is greater than Amplify's limit but it seems to be fine with it. I guess it's because Amplify only takes standalone parts of the output and maybe compresses everything before measuring size.

Just changing the version to 11.1.1 puts me here:

390M    .next
----
 77M    .next/server
144M    .next/standalone
168M    .next/static

Not much of a change so far, .next/node_modules is 0B (just symlinks). If I dereference symlinks with the script, I end up here:

1.1G    .next
----
712M    .next/node_modules
 77M    .next/server
144M    .next/standalone
168M    .next/static

And such amount of build artifacts produces the error:

The size of the build output (945923853) exceeds the max allowed size of 230686720 bytes

If I don't dereference symlinks in .next/node_modules, the error is still there for Next.js 16.1.1:

The size of the build output (452346123) exceeds the max allowed size of 230686720 bytes

Our app is an enterprise SAAS which is not too massive, but is also not a 'hello world' deployment. If anyone has ideas on how else to upgrade, happy to try them out.

Did you find a solution for this?

[chunchunmaru0]

I've a slight different monorepo build, where I'm CD'ing into the said dir, and building the nextjs standalone package, that way it works on AWS Amplify.

version: 1
applications:
  - appRoot: apps/web
    frontend:
      phases:
        preBuild:
          commands:
            - corepack enable
            - corepack prepare pnpm@latest --activate
            - pnpm install
        build:
          commands:
            - cd ../..
            - pnpm build --filter=web
      artifacts:
        # For Next.js standalone builds
        baseDirectory: .next
        files:
          - "**/*"
      cache:
        paths:
          - apps/web/.next/cache/**/*
          - apps/web/node_modules/**/*
          - node_modules/**/*
          - .turbo/**/*

[josefaidt]

Hey folks 👋 thanks for raising this! I'm working on a repro of this but haven't had much success -- using pnpm, Next.js 16.1.6, and the pino lib in my layout file. I noticed a few of the snippets provided in the thread are referencing monorepo setups with Amplify. Are folks experiencing this without the monorepo setup as well?

As a workaround, does the standalone build deploy okay (outputs to .next/standalone)?

[yamaaaaaa31]

Hi @josefaidt, thanks for looking into this!

To answer your questions:

1. Monorepo: We use Amplify's monorepo configuration (appRoot: frontend in amplify.yml), but the frontend itself is a standalone Next.js app — not a pnpm workspace monorepo. There are no cross-package dependencies. So the symlink issue is not related to monorepo package resolution; it's purely from Turbopack's behavior in .next/node_modules.

2. Standalone build: We already use output: 'standalone' in next.config.ts. The issue still occurs — the symlinks in .next/node_modules cause the EEXIST error during Amplify's bundling regardless of standalone mode.

3. Workaround: The post-build script I shared (resolving symlinks to actual files) works for us. However, as @kachkaev reported, for larger projects this can push the build output over Amplify's 230MB size limit.

[NamanArora]

Faced the same issue today. Hoping this gets fixed soon. For temp measure, I did this to fix it

version: 1
applications:
  - appRoot: frontend
    frontend:
      phases:
        preBuild:
          commands:
            - npm ci
        build:
          commands:
            - npm run build
            # Resolve symlinks in .next to fix Amplify bundler EEXIST error
            # Turbopack creates symlinks that Amplify's bundler can't handle
            - |
              if [ -d ".next" ]; then
                find .next -type l -exec sh -c 'target=$(readlink -f "$1") && rm "$1" && cp -r "$target" "$1"' _ {} \;
              fi
      artifacts:
        baseDirectory: .next
        files:
          - '**/*'
      cache:
        paths:
          - node_modules/**/*
          - .next/cache/**/*

[josefaidt]

Hey @yamaaaaaa31 and @NamanArora thanks for the added context! I was able to reproduce this behavior by deploying a next.js site from a monorepo. I wasn't able to reproduce without a monorepo configuration in amplify.yml, and the site still deployed successfully after adding appRoot: ./. The issue arises when the next.js site is in a directory within a monorepo, like frontend/ or apps/www, etc.

Marking as a bug!

[Gpacheco019]

Guys, just adding more information, perhaps useful for correction:
The error occurs with packages that contain native modules (in our case dd-trace for Datadog APM). Previously, we also saw this error with @react-pdf/renderer.

Impact

We do not use Turbopack in production builds (only in development with next dev --turbopack). The production build uses the standard Next.js/SWC compiler. This suggests that the problem may not be exclusive to Turbopack, but rather related to changes in how the SWC compiler handles serverExternalPackages in more recent versions.

When we updated Next.js/SWC to version 16.1.6, an issue occurred that prevented Amplify from compiling.

Because when we update, this error occurs, similar to the one mentioned at the beginning of the issue:

2026-02-02T15:19:05.297Z [INFO]: # Caching completed
2026-02-02T15:19:22.874Z [ERROR]: !!! We failed to bundle your application due to an unexpected error. Please try again. If the issue persists, please contact AWS support.
2026-02-02T15:19:22.985Z [ERROR]: !!! Error: EEXIST: file already exists, mkdir '/codebuild/output/src201127112/src/***/frontend/amplify-compute-bundle-output/compute/default/.next/node_modules/dd-trace-3bf661a891f513a5'

What We've Tried

• Adding affected packages to serverExternalPackages in next.config.ts
• Adding paths to outputFileTracingExcludes
• Neither approach resolved the issue