# Fix a Failed Vercel Deployment of a Nuxt App

Yes. A failed deployment starts a run; the agent reads the Vercel build log, reproduces nuxt build in its sandbox and opens a pull request with the fix.

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

## What the agent does

A failed Vercel deployment starts the run with the deployment event after the prompt. The agent reads that deployment's build log through the Vercel connection and finds the first real error, which in a Nuxt build can be a Vite transform error, a Nitro prerender failure or a type error from `nuxt prepare`. It clones the repository at the commit Vercel built into its own cloud sandbox.

In a Nuxt app like `elk-zone/elk`, the agent reads `package.json`: `nuxt build` as `build`, `pnpm@11.6.0` in `packageManager`, and a `postinstall` that runs `simple-git-hooks && nuxt prepare`, so a broken module can fail the install before the build even starts. `.nvmrc` says `lts/*`. The CI workflow in `.github/workflows/ci.yml` enables corepack and runs `pnpm install --frozen-lockfile`, `pnpm nuxi prepare`, `pnpm test:ci`, `pnpm lint` and `pnpm test:typecheck`, and the agent uses the same steps.

It reads `nuxt.config.ts` for build behaviour that depends on where the build runs. The storage driver is `process.env.NUXT_STORAGE_DRIVER ?? (isCI ? 'cloudflare' : 'fs')`, so on a CI host such as Vercel it expects Cloudflare KV credentials, and `netlify.toml` notes that without them the build crashes while starting the prerenderer. Nitro prerenders with `crawlLinks: true`, so one broken link in a page can fail the deployment. The agent sets the same CI condition in the sandbox, with the Project's secrets as environment variables, so its build fails the way Vercel's did.

With the failure reproduced, it fixes the cause in the file the log names, runs `pnpm build` until it passes, then runs the Vitest suite with `pnpm test:ci` and the type check with `pnpm test:typecheck` so the fix does not break something the build does not cover.

## Start it with one API call

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

```json
{
  "agent": "claude",
  "input": "A Vercel deployment of this Nuxt 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 pnpm and the frozen lockfile, reproduce the failure with pnpm build in the sandbox under the same CI conditions and the Project's environment variables, fix the cause, confirm the build, pnpm test:ci and pnpm test:typecheck pass, 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 with the fix on its own branch. Its description quotes the failing line from the Vercel build log, says whether the cause was in a component, a Nuxt module, the Nitro prerender or the configuration, and shows the passing build. Changes to `nuxt.config.ts` are listed on their own, since they change every build.

Two kinds of checks run on it: the Vercel preview deployment for the branch, and the repository's CI workflow with tests, lint and type check. A reviewer looks at the preview first, then confirms the fix addresses the cause. A prerender failure fixed by excluding the route from prerendering, for example, is a choice the description must state, not hide.

When the failure comes from the Vercel environment rather than the code, such as missing KV credentials for the storage driver, the run says so and names the variable instead of changing code to work around it. Every command it ran and its output stays in the session.

## Run it on every failed Vercel deployment

Create an automation in the Project with this prompt and a `webhook` trigger, and copy the URL and signing secret Rush shows once. Add a webhook in the Vercel project for failed deployments that posts to that URL. Each failure starts one run, with the deployment event passed to the agent after the prompt as untrusted data.

A webhook Vercel sends twice is deduplicated, so one failure gives one run and one pull request. When the automation is busy or rate limited it reports why it skipped an event, and the next failure starts its own run.

## Why run it on Rush?

Nuxt builds behave differently on a CI host than on a laptop: this app switches its storage driver on `isCI`, prerenders by crawling links, and runs `nuxt prepare` on install. A Rush run reproduces those conditions in its own sandbox instead of on someone's machine, with pnpm from `packageManager` and every command's output kept.

The pull request carries its proof: a passing build in the session, a green preview on Vercel and the repository's own CI. Failures on several branches each get their own run, and a failure the code cannot fix ends with an explanation rather than a forced change.

## Frequently asked questions

### The install itself fails. Can the agent handle that?

Yes. In this app `postinstall` runs `nuxt prepare`, so a broken module or config fails `pnpm install`. The agent reads that output the same way it reads a build failure and fixes the cause before running the build.

### Which pnpm version does it use?

The one `packageManager` names, `pnpm@11.6.0` in `elk-zone/elk`, through corepack as the CI workflow does. The lockfile is installed frozen, so the dependency tree matches what Vercel built.

### How does it connect to Vercel?

Connect the Vercel MCP server once with `POST /me/connections` and an OAuth sign-in, then name it in the run's `connections` or on the saved agent the automation runs. The agent uses it to read the deployment and its build log.

### Will it run the Vitest tests too?

Yes. The prompt asks for `pnpm test:ci`, which runs `vitest run`, and `pnpm test:typecheck` after the build passes, so a fix that builds but breaks a test is caught before the pull request opens.