# Fix a Failed Vercel Deployment of a Next.js App

Yes. A failed deployment starts a run; the agent reads the Vercel build log, reproduces next build in its sandbox and opens a pull request that fixes it.

[Run this on Rush](https://cloud.getrush.ai/run/fix-vercel-build-failures/nextjs/), in a Project that has your repository.

## What the agent does

The run starts when Vercel reports a failed deployment: the deployment event arrives after the prompt, and the agent uses the Vercel connection to read that deployment's build log. It takes the failing line from the log rather than from the last line of output, because a Next.js build often prints the cause above a generic "Build failed" message. Then it clones the repository at the commit the deployment built into its own cloud sandbox.

In a Next.js app like `vercel/commerce`, the agent reads `package.json` and finds `next build` as the `build` script, Next.js 15.6 canary with React 19, and a `pnpm-lock.yaml`, so it installs with pnpm rather than npm to get the dependency tree Vercel built. `next.config.ts` turns on the experimental `ppr`, `inlineCss` and `useCache` flags, and the app router under `app/` prerenders pages that fetch from Shopify through `lib/shopify/index.ts`.

Reproducing the build needs the same environment variables Vercel has. `.env.example` lists `SHOPIFY_STORE_DOMAIN`, `SHOPIFY_STOREFRONT_ACCESS_TOKEN`, `SHOPIFY_REVALIDATION_SECRET`, `COMPANY_NAME` and `SITE_NAME`, and `lib/shopify/index.ts` reads the token with a non-null assertion, so a build without them fails for a reason unrelated to the deployment. Those values come from Project secrets, which reach every session in the Project as environment variables. With them set, the agent runs the build, confirms it fails on the same line as the Vercel log, and only then edits code.

It fixes the cause in the file the log names: a type error in a server action, an import of a server-only module into a client component, a page that calls a dynamic API during prerender. Then it runs the build again until it passes, and runs `pnpm test`, which in this repository is `prettier --check`, so the fix is formatted the way the project requires.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "A Vercel deployment of this Next.js app failed; the deployment event follows this prompt. Use the Vercel connection to read that deployment's build log and quote the failing line. Install with the lockfile the repository uses, reproduce the failure with the build script in the sandbox using the Project's environment variables, fix the cause, confirm the build passes and the test script passes, and open a pull request that quotes the failing log line and explains the fix.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

What comes back is a pull request on its own branch. The description quotes the line from the Vercel build log, names the file and the cause, and shows the passing build from the sandbox. The diff is the fix and nothing else; a change to `next.config.ts` or a dependency version is called out separately because it affects every page.

Vercel builds a preview deployment for the pull request, so the check a reviewer looks at first is the one that failed. They confirm the preview is green, read the fix to see that it removes the cause rather than silencing it, and check that no `// @ts-ignore` or disabled lint rule was added to get there.

When the build cannot be reproduced, for example because the failure came from a missing environment variable on Vercel and not from code, the run does not invent a fix. It says what it tried and what differs between the sandbox and the deployment, and the session keeps every command and its output for whoever picks it up.

## Run it on every failed Vercel deployment

In the console, add an automation to the Project with this prompt and a `webhook` trigger; Rush shows the trigger's URL and signing secret once. In the Vercel project's settings, add a webhook for failed deployments pointing at that URL. Each failed deployment then starts one run with the event after the prompt, as data rather than instructions.

Duplicate deliveries of the same event are deduplicated, so a retried Vercel webhook does not open two pull requests. If you would rather route the event through your own server, it can call `POST /o/{org}/sessions` with the event in `input`, and a webhook on the API key tells it when the run finishes.

## Why run it on Rush?

A red deployment usually means someone stops what they are doing, opens the log, checks out the commit and runs the build locally with the right environment. A Rush run does that in its own sandbox: the clone at the failed commit, pnpm with the lockfile, the Project's secrets as environment variables, and `next build` with its full output kept in the session.

The proof is a passing build and a green preview, not a claim. Several failed deployments across branches each get their own run on their own branch, and when a run cannot reproduce a failure it ends with what it found instead of a false done.

## Frequently asked questions

### How does the run reach my Vercel account?

Through the Vercel MCP server, connected once with `POST /me/connections` using `"auth": {"mode": "oauth"}` and a sign-in in the browser. Name it on the run in `connections`, or on the saved agent the automation runs, and the agent reads build logs and deployments through it.

### Does it work with pnpm?

Yes. The prompt tells the agent to install with the lockfile the repository has, and `vercel/commerce` ships `pnpm-lock.yaml`, so it runs `pnpm install` and the `build` script the same way Vercel does.

### My build needs secrets. Where do they come from?

From Project secrets, saved with `POST /o/{org}/secrets`. They reach every session in the Project as environment variables, so `SHOPIFY_STOREFRONT_ACCESS_TOKEN` and the others are set when the agent runs the build, and they never appear in the pull request.

### What if the failure is in Vercel's settings, not my code?

Then the build passes in the sandbox and the run says so. It names the difference it found, such as a variable Vercel is missing or a different Node version, and opens no pull request for a problem code cannot fix.