No Output Directory named "dist" found after the Build completed (Vercel)

Filed under Deployment failures

Most likely causeAbout 10 min · 6 steps

Your build succeeded but wrote its finished files to a different folder than Vercel was told to expect — a framework preset, root directory, or override setting disagrees with how your app actually builds.

Match Framework Preset to your app in Project Settings
Set Root Directory to the folder holding package.json, if the app lives in a subfolder
Clear any Output Directory override (or legacy vercel.json) you didn't deliberately set

Fastest route

Give your AI this prompt

Copy it, replace the bracketed part with your error, and send it.

Preview the prompt
My Vercel deployment fails at the end with: "No Output Directory named '[dist/public]' found after the Build completed." The build step itself completes.

Please: 1) identify the framework this project actually uses from package.json, and the exact folder a local build produces, 2) check for anything that overrides the output location: a vercel.json with outputDirectory or a legacy builds section, or config in the framework's own files, and tell me what should be removed or corrected, 3) tell me the exact Vercel dashboard settings to set: Framework Preset, Root Directory (my package.json is at [repo root / subfolder path]), and Output Directory (or confirm it should be left to the preset).

Constraints: do not change the app's framework or restructure the project to match Vercel's current wrong expectation, and do not add a script that copies files into the expected folder as a workaround. Make one change at a time and tell me what a successful deploy log looks like.

Fix it yourself

Follow the repair

  1. Note which folder Vercel wanted. The error names it — dist, public, build. Write it down; that's the expectation you have to reconcile. Then read the deployment log above the error and confirm the build step itself completed — if it didn't, you have a build failure, and this page is not your fix.
  2. Match the Framework Preset. In your Vercel project: Settings → Build and Deployment → Framework Preset. Set it to the framework the app actually uses — Next.js, Vite, Create React App. The preset quietly configures the build command and the expected output folder together, which is why one wrong dropdown manufactures this exact error.
  3. Fix the Root Directory for subfolder apps. If your package.json lives in a subfolder, set Settings → General → Root Directory to that folder. Vercel then installs, builds, and — crucially — looks for output relative to the app, not the repository root. Monorepo and AI-restructured projects fail here more than anywhere else.
  4. Build locally and look at what appears. Run the same build command Vercel runs, on your machine, and watch which folder appears with the finished site inside. That folder is ground truth. If no output folder appears at all, your build command is the problem (a common one: the script runs a type check or a linter but never the actual build) — fix the script, not Vercel.
  5. Remove stale overrides. Check the Output Directory field in settings and any vercel.json in the repo for outputDirectory or a legacy builds section. If you (or a tutorial, or an AI) set one for a setup you no longer have, clear it and let the preset decide. Only keep an override if your build genuinely writes somewhere custom — and then it must name the folder from step 4 exactly.
  6. Redeploy with a cleared cache. Settings changes only affect new deployments. Trigger one, choosing the option to redeploy without the build cache, so nothing from the old configuration survives. The deploy should now sail past the pickup step that failed before.
Why this happensOptional explanation

Deploying is a contract. Your build tool promises to leave a finished site in a known folder — Vite and most static setups use dist, Create React App uses build, Next.js is handled specially — and Vercel promises to pick the site up from the folder your project settings describe. This error is the contract breaking at the pickup step: the location in the settings and the location your build actually wrote to are different folders.

The settings usually go wrong silently. Import a repo and pick the wrong Framework Preset (or let it land on "Other"), and Vercel expects public or dist while your framework does something else entirely. Let an AI restructure the project into a subfolder — apps/web, client — and Vercel keeps building at the root, where there is no package.json it recognises and no output where it looks. And overrides fossilise: a tutorial's instruction to "set Output Directory to dist", or a vercel.json an AI wrote months ago with a legacy builds section, outlives the setup it was meant for. The build succeeding is the tell that this is a settings mismatch, not broken code — the deploy log will show the build completing, then the pickup failing.

  • Wrong Framework Preset: Vercel expects another framework's output folder.
  • Subfolder app: Root Directory points at the repo root while the app builds elsewhere.
  • Stale override: an Output Directory setting or legacy vercel.json naming a folder nothing creates.
  • Build that emits nothing: the build command succeeds vacuously without producing a site at all.

Quick answers

Should I just set the Output Directory to dist?

Only if you truly changed it. If your build tool writes somewhere custom, set Output Directory to that folder. If you never customised it, the fix is the opposite: clear the override and let the correct framework preset decide.

How is this different from my build failing?

Different failures. Here, the build itself succeeded — the error is about where the finished files are. A build-command failure stops earlier with the compiler or tool's own error. Read the log top to bottom: the last thing that succeeded tells you which one you have.

My build works locally and produces dist. Why can't Vercel find it?

Because locally there is no middleman: you open the folder your tool produced and it works. Vercel adds a contract — it looks in the folder your project settings describe. The app didn't change; the expectations of the two environments differ.

One fix, every Friday.

One real error, explained in plain English, with the fix — in your inbox every Friday. No spam, no jargon, unsubscribe anytime.