Vercel deploy fails: "Command "npm run build" exited with code 1"
Filed under Deployment failures
The build itself failed for a specific reason printed higher in the log — a type error, lint failure, case-mismatched import, or missing environment variable — and "exited with code 1" is only Vercel's summary of that failure.
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 failed with: Error: Command "npm run build" exited with code 1. I know that line is only the summary. Here is the first real error I found higher in the Vercel build log, with the file and line it names: [paste it]. When I run npm run build locally, I get: [paste the local output, or say it passes locally]. Please: 1) explain in plain English what that first error actually means, 2) show me the exact change to fix it, 3) if it is an import or module error, check whether the capitalisation of the import path matches the real file name exactly, and whether the package is listed in package.json. Constraints: fix the first real error only — do not "fix" the exit code line, do not disable TypeScript or lint checks to make the build pass, do not rewrite unrelated files, and tell me how to confirm the fix locally before I redeploy.
Fix it yourself
Follow the repair
- Scroll up in the Vercel build log and find the first real error. Open the failed deployment in Vercel and expand the build log. Ignore the final lines entirely. Scroll up looking for the words "Failed to compile", "Type error", "Module not found", or the name of a file in your project with a line number. The first specific complaint is your actual bug — everything after it is the build winding down. Copy that message and the file it names; that pair is what you fix, and what you search for or paste to your AI if you get stuck.
- Reproduce it locally with npm run build. In your project folder in a terminal, run:
You will almost always get the same failure in seconds instead of the minutes a redeploy takes, with the full error laid out in one place. Fix, rerun, repeat until the local build passes — a build that passes locally and uses the same lockfile will pass on Vercel in the overwhelming majority of cases. This loop is the whole workflow; redeploying to test each guess is the slow version of the same thing.npm run build - If it is an import error, check the capitalisation letter by letter. "Module not found" pointing at a file that plainly exists is the signature of a case mismatch. Compare the import in your code against the real file name on disk, character by character:
Fix the import (or rename the file) so they agree exactly, then rerun the local build. This one bites constantly because your computer has been silently forgiving it the whole time you were developing.// file on disk: components/Button.tsx import Button from "./components/button"; // fails on Linux import Button from "./components/Button"; // matches exactly - If a variable is missing at build time, add it to Vercel and redeploy. Your local .env file does not travel with your code — it is (correctly) never committed. Any value the build reads, especially NEXT_PUBLIC_ variables in Next.js, must also exist in Vercel under Project Settings, then Environment Variables, for the Production environment. Add the missing ones, then trigger a fresh deployment: changing variables does not rebuild anything by itself, and an old failed deployment will not pick them up.
- Make sure the dependencies you rely on are actually committed. If the log says a package cannot be found and you know you installed it, check that package.json and your lockfile (package-lock.json) include it and that both files were committed and pushed. Installing a package in your editor's terminal without saving it to package.json, or forgetting to push, leaves Vercel building from a shopping list that does not mention the thing your code imports. Commit, push, redeploy.
- If the local build passes but Vercel still fails, clear the cache and check the Node version. Two environmental differences remain. First, redeploy with the build cache cleared (in the deployment's menu, choose Redeploy and untick the cache option) — a stale cache can keep a fixed project failing. Second, compare Node versions: Vercel uses the version set in Project Settings (or an "engines" entry in package.json), and a big gap from your local version can change build behaviour. Align them, and the last common cause is gone.
Why this happensOptional explanation
When Vercel builds your project, it runs your build command — for most apps, npm run build — on one of its Linux machines. If anything in that process fails, the process ends with a non-zero "exit code," and Vercel prints the summary line you are staring at: the command exited with code 1. Code 1 just means "something above me failed." It is the smoke, never the fire, and searching for that exact sentence mostly finds other people who also stopped one step short of the real message.
The real causes repeat. Next.js checks your types and runs lint during a production build, so code that happily runs in development can be refused at build time for a type mismatch or a lint rule. Imports are another classic: macOS and Windows treat Button.tsx and button.tsx as the same file, but Linux — Vercel's machines, and your deployed app — treats them as different files, so an import that "works on my machine" fails the build. Add build-time environment variables that exist in your local .env file but were never added to Vercel, and dependencies that are installed on your machine but missing from the package.json you committed, and you have almost every case.
- Buried real error: a type error, lint failure, or missing module is reported higher in the log — the exit code line is only the summary.
- Case-mismatched imports: the import path's capitalisation differs from the actual file name, which Mac and Windows forgive and Linux does not.
- Missing build-time variables: your local .env file never made it to Vercel's Environment Variables, so the build hits a value that is not there.
- Uncommitted dependencies: the package is installed locally, but package.json or the lockfile with it never got committed and pushed.
Quick answers
Why does searching for "exited with code 1" never give a straight answer?
Because the line reports that the build process ended in failure — it is a summary, not a diagnosis. The specific failure (a type error, a module that was not found, a lint rule) is always printed earlier in the same log. Searching for the summary line mostly finds other people reading their logs one step too late.
The build passes on my machine but fails on Vercel. What differs?
Almost always a case-mismatched import: your computer's file system treats Button.tsx and button.tsx as the same file, while the Linux machines that build and host your app treat them as different. The runner-up causes are environment variables that exist locally but were never added to Vercel, and a build cache worth clearing once everything else checks out.
Can I just turn off the TypeScript and lint checks so the build passes?
It makes the red message disappear by telling the build not to check — the type errors and lint problems are still in your code, waiting to become runtime bugs your users find instead. Fix the error the check is pointing at; it is nearly always a small, real problem.