Summary
next build completes cleanly (exit 0) on every configuration we've tried, but Vercel's post-build step fails immediately afterward with an ENOENT, looking for a file our build correctly does not produce. We've eliminated every repo-side variable we can think of — two separate accounts, three Next.js versions, both Node LTS lines, both bundlers, with and without various config files — and the failure persists identically across all of them. We believe this is a platform-side issue in the build/deploy pipeline, not something in our project.
Key evidence: the failing filename changes between identical runs
Two deploys of the same commit, minutes apart, on a brand-new account and a brand-new project:
| Run | Failure |
|---|---|
| 1 | ENOENT .next/lock |
2 (--force) | ENOENT .next/export-detail.json |
Both fail at the identical stage — immediately after Collecting build traces ..., in the post-build step, with next build itself completely clean in both runs. A genuinely missing output file would fail on the same filename every time. A filename that changes between two runs of the identical commit indicates the post-build step isn't reliably finding the .next directory at all, rather than failing on a specific missing artifact — this looks like a race or timing issue in how the builder reads build output, not a build-output-content bug.
Reproduction: fresh account, fresh project
- Account:
1812jeevith-5930s-projects(created solely for this isolation test, no prior deployments) - Project:
passcv-isolation - Deployment 1 (ENOENT
.next/lock):vercel.com/1812jeevith-5930s-projects/passcv-isolation/CpiwYKfXDWnCsncHwVrF9EqW2FuU - Deployment 2 (ENOENT
.next/export-detail.json):vercel.com/1812jeevith-5930s-projects/passcv-isolation/BGijmDWUpDexMThH1VtPECeqWz6F
These deployment IDs point at the actual build containers, which should let you inspect the runtime state directly rather than relying on our description of it.
Build output evidence
export-marker.json from the same build reports "hasExportPathMap": false. Our build correctly determines it should not produce export-detail.json — the builder demands it anyway.
Elimination list
Everything below was tested, not reasoned about — each item run to a clean pass/fail on its own:
- Accounts: two separate Vercel accounts, different emails, different orgs — same failure on both
- Projects: original
passcv, freshpasscv-pdftest(old account), freshpasscv-isolation(new account) - Next.js versions: 14.2.35, 15.5.22, 16.2.12 (current Active LTS at time of testing)
- Node: 20.x and 24.x
- Bundler: Turbopack (Next 16 default) and explicit
--webpack vercel.json: present and deleted entirelynext.config.mjs:outputFileTracingIncludespresent and removed- Chromium dependency:
@sparticuz/chromium(390MB) and@sparticuz/chromium-min - Route shape: two Pages API routes, one route, debug handler stripped
- Build cache: default and
--force .vercelignore: present and absent; local.nextuploaded and not- CLI version: 53.2.0 (local
vercel build) and 58.4.0 (remote) — same failure on both
next build exits 0 in every single configuration above.
Questions for support
- Is there a known issue with the post-build step's discovery of
.nextoutput — specifically a race between build-output write completion and the builder reading it — that would explain a failing-filename that isn't stable across identical runs? - Given the elimination list above, can you point to a project-level or account-level setting (outside
vercel.json/next.config.mjs, which we've already ruled out) that could affect this? - Is there a way to get a build-container-side trace of exactly what the post-build step attempts to read from
.next, to confirm the "not finding the directory" theory directly rather than by inference?
Happy to provide additional deployment IDs, full build logs, or a live repro on request.