Vercel change

Vercel

Vercel CI beta (October 28, 2026): how to set it up with turbo.json, what agents can do through the CLI and MCP, and how it compares with GitHub Actions

By Ohad Krispin, founder of VibeRaven · LinkedIn

Vercel CI, in beta since October 28, 2026 and announced for all plans, runs the Turborepo tasks you tag with "ci" in turbo.json on every git push to a GitHub repository connected to a Vercel project. It reads the task graph, restores tasks whose inputs did not change from Vercel Remote Cache, runs each remaining task on its own Linux machine (2 CPUs and 4 GB of memory by default), and posts a check to the pull request, so branch protection can stop a merge when a task fails. You need Turborepo 2.11.7 or later and Vercel CLI 64.3.1 or later; then run vercel ci enable from a clone of the repo, or give your agent the setup skill with npx skills use vercel/ci@setup. Agents read runs and logs with vercel ci ls, inspect, logs, grep and rerun, or through 15 Vercel MCP tools. In the beta it runs only on Linux, only for GitHub and only on git push, and the Pro plan is billed $0.0035 per CPU minute. Checked against Vercel's changelog, blog post and docs on 2026-10-28.

Paste this to your agent

Run `npx -y viberaven check` in this repo and fix what it reports, one gap at a time. Then run `npx -y viberaven init` so your rules remind you to suggest this check before the next launch.

The check runs locally, with no sign-in and no API key. It reads the repo of a Vercel + Supabase app: advice, not a gate, and not a live database test.

Repository check

Check this in your repo

Run a repo check as a Vercel CI task

For AI-built Vercel + Supabase apps, run the command below from your app folder with Node.js 20 or newer; both Vercel CI images ship Node.js 24.18.0. It reads the repo, including the SQL in supabase/migrations, and exits with code 1 on a blocker, such as a public table that no migration enables row level security on (rls_disabled).

To have Vercel CI run it, add it to package.json as a script, "viberaven:check": "npx -y viberaven@1.6.12 check", and tag a task of the same name in turbo.json: "tasks": { "viberaven:check": { "tags": ["ci"] } }. Vercel's own end-to-end test guide pairs a package.json script (e2e:ci) with a turbo.json task of that name tagged ci in the same way. On 1.6.12, init does not write this script, so add it yourself; pinning the version keeps a cached result tied to one version of the check.

It is a repository check, not a live database test: it cannot see policies changed in the Supabase dashboard, and a clean result is not a security audit. It is advice, not a gate: whether a failed task stops a merge depends on whether you make the Vercel CI check required in your branch protection rules.

npx -y viberaven@1.6.12 check

What it printed, and what turbo did with it, on a fixture repo

On 2026-10-28 we ran it on a small fixture repo made for this page, not a customer repo: one package with the script and the turbo.json task above, and one migration that creates public.notes without row level security. The check exited with code 1, and run as a Turborepo task with turbo 2.11.10 it failed the task. Vercel's docs say a run is marked failed when one or more tasks fail. We ran this locally, not on Vercel CI. The output is below, with the folder shortened to ~/app and the turbo task log trimmed to its summary.

$ npx -y viberaven@1.6.12 check

viberaven check · ~/app

🔴 No RLS policy proof in migrations  (rls_disabled)
   1 public table without row level security: public.notes (supabase/migrations/20261028000000_init.sql:1). The Data API does not enforce row restrictions for roles and operations allowed by the table's grants. Verify those grants to determine who can read or change rows.

Verdict: ❌ 1 blocker, 0 warnings · score 80
Fix: viberaven fix · Details: ~/app/.viberaven/agent-tasklist.md

$ npx turbo run "viberaven:check"

 Tasks:    0 successful, 1 total
Cached:    0 cached, 1 total
Failed:    //#viberaven:check

 ERROR  run failed: command  exited (1)

How to turn on Vercel CI

Connect the GitHub repository to a Vercel project on your team, then run vercel ci enable from a local clone; Vercel says a repository must be enabled before CI runs anything. Then add the ci tag to each task you want run on push. If the repo does not use Turborepo yet, add a turbo.json and the turbo package: Vercel says it works in single-package repos too, and a task is the package.json script of the same name. Vercel also publishes a setup skill: ask your agent to run npx skills use vercel/ci@setup and follow it to pick the first tasks, configure CI and open a pull request.

# Turborepo 2.11.7+ and Vercel CLI 64.3.1+
vercel ci enable

# turbo.json
{
  "tasks": {
    "test": {
      "tags": ["ci"]
    }
  }
}

How Vercel CI decides what runs (the Turborepo part)

On each push, Turborepo finds the tasks tagged ci, Vercel Remote Cache restores the ones already cached, and the rest run in dependency order, each in its own machine. A tagged task brings its dependencies with it: with "dependsOn": ["^build"], the build tasks it needs run first. The tag can also go in a package's own turbo.json, and "!ci" opts one package out of a task the root runs; a dependency tagged "!ci" still runs if a CI task needs it. Vercel reports that this cut the time from git push to "CI passed" by 2 to 6 times in its own repositories.

Each task gets 2 CPUs and 4 GB by default; a ci:cpus:<count> tag raises that up to 32 CPUs, at 2 GB per CPU. Dependencies install once per run, on a separate Amazon Linux machine with 4 CPUs and 8 GB, set with ci.bootstrapping.resources.vcpus in vercel.json. A ci:os:ubuntu tag runs a task on Ubuntu 24.04 instead of Amazon Linux 2023.

{
  "tasks": {
    "build": {
      "dependsOn": ["^build"]
    },
    "test": {
      "dependsOn": ["^build"],
      "tags": ["ci", "ci:cpus:8"]
    },
    "lint": {
      "tags": ["ci", "ci:os:ubuntu"]
    }
  }
}

Env vars and secrets that never reach the task

Vercel CI runs each task with Turborepo in Strict Mode, which removes every environment variable your turbo.json does not list. A variable you add to Vercel CI does not reach the task until you list it in the task's env, or in passThroughEnv to keep it out of the cache hash. Add secrets per repository under CI environment variables in the dashboard and mark them Secret; for private npm packages, add a secret named NPM_RC with your .npmrc content. Constants for non-secret values can go in vercel.json under ci, and Vercel says not to commit secrets there.

{
  "tasks": {
    "test": {
      "tags": ["ci"],
      "env": ["API_TOKEN"]
    }
  }
}

What an agent can do through the Vercel CLI and Vercel MCP

Vercel CLI 64.3.1 and later has vercel ci: ls lists runs (filter by branch, status or commit), inspect shows a run's jobs and tasks, logs reads task logs (only failed tasks, one task, a log level, or a text match), grep searches the logs of recent runs (20 by default, up to 50), and rerun starts a new attempt. Every subcommand takes --format json. inspect --wait and rerun --wait wait up to 10 minutes and exit with code 1 if the run fails, which gives an agent a plain pass or fail after it pushes.

Vercel MCP lists 15 Vercel CI tools, among them list_vercel_ci_invocations (filter by repository, branch, status or conclusion), get_vercel_ci_invocation_tree, get_vercel_ci_task_logs with conclusion=failed, and retry_vercel_ci_invocation. Vercel's tool reference says a retry can return retry_not_supported for some invocations, and that an agent should read the new attempt's status and logs before it reports the outcome.

vercel ci ls --all-branches --status failed --format json
vercel ci inspect --wait
vercel ci logs --failed
vercel ci logs --task 'web#test' --level error
vercel ci grep ECONNRESET --runs 50
vercel ci rerun --wait

Vercel CI vs GitHub Actions

Both report to the pull request as a GitHub check, and Vercel says branch protection can stop a merge when Vercel CI fails, the same way it does for a failed GitHub Action. The difference is the config: Vercel CI has no workflow YAML, it reads the tasks in turbo.json, runs only the ones your change affects and restores the rest from Remote Cache, and sizes compute per task.

The beta limits decide what stays in Actions. Vercel CI runs only on Linux (Amazon Linux 2023 or Ubuntu 24.04, x86_64), only for GitHub repositories, and only on git push, so scheduled jobs, manual runs and workflows triggered by other events have no Vercel CI equivalent yet. The repository has to be connected to at least one Vercel project, and not to projects on more than one Vercel team. The docs do not describe moving workflows across or running both; the checks are separate, so you can run both while you compare.

Run tests against the preview deployment of the same commit

A task can wait for the Vercel deployment of its commit: add "<package>#deployment" to its dependsOn and the ci:oidc:deployments tag. Vercel CI then gives the task VERCEL_DEPLOYMENT_URLS, a JSON object of package name to hostname, and adds an OIDC token to requests sent to that hostname, so tests reach a preview that has Deployment Protection on. List the variable in passThroughEnv. One trap from the docs: if the package has its own deployment script in package.json, Vercel CI runs that script instead of waiting for the deployment, and a task tagged ci:oidc:deployments fails.

{
  "extends": ["//"],
  "tasks": {
    "test:e2e": {
      "dependsOn": ["web#deployment"],
      "tags": ["ci", "ci:oidc:deployments"],
      "passThroughEnv": ["VERCEL_DEPLOYMENT_URLS"]
    }
  }
}

What Vercel CI costs

Vercel bills CI in CPU minutes, CPUs times run time, the same unit as Builds: $0.0035 per CPU minute on Pro, custom on Enterprise. Each run pays for the install step (4 CPUs by default) and each task that runs (2 CPUs by default); tasks restored from cache or skipped use none. Vercel's own example: a task with 8 CPUs that runs 2 minutes 30 seconds uses 20 CPU minutes, which is $0.07 at the Pro rate. The pricing page does not list the Hobby plan.

Checklist

Before you turn on Vercel CI

01
Check the versions: Turborepo 2.11.7 or later, Vercel CLI 64.3.1 or later.
```
npx turbo --version
vercel --version
```
02
Connect the GitHub repository to one Vercel project on one team, then enable CI from a clone:
```
vercel ci enable
```
03
Tag one cheap task first, such as lint, push, and wait for the result:
```
vercel ci inspect --wait
```
04List every env var each task reads in its env or passThroughEnv, and add secrets under CI environment variables, not in vercel.json.
05Keep the GitHub Actions workflows that run on a schedule, by hand or on events other than a push.
06Make the Vercel CI check required in branch protection only after a few runs pass.

Sources

Official docs behind this checklist

Browse all launch guides · Read resources · How to make and check your next change

FAQ

FAQ for builders before launch

Is Vercel CI free?

The changelog says the beta is on all plans. The pricing page lists Pro at $0.0035 per CPU minute and Enterprise as custom, and does not list Hobby. Tasks restored from cache or skipped use no CPU minutes.

Do I need a monorepo or Turborepo?

You need Turborepo, not a monorepo. Vercel says to add turbo.json and the turbo package if you do not use it yet, and that Vercel CI works in single-package repos too.

Can a Vercel CI task run any command?

A task runs the package.json script of the same name, so it runs whatever that script runs, on a Linux image with Node.js 24.18.0, git, Docker, jq and curl. A tool outside the image goes in through ci.bootstrapping.installCommand in vercel.json, and only reaches tasks if it is installed inside the repository folder.

Does Vercel CI work with GitLab or Bitbucket?

Not in the beta. The docs say GitHub is the only supported forge and git push the only trigger.