Vercel CI Is in Beta: What It Means for Next.js Teams on Vercel

Most of my newer builds are Next.js on Vercel. Until now, Vercel handled the build and the deploy, and the checks before merge (lint, type-check, tests) ran somewhere else, usually GitHub Actions. Vercel CI moves those checks onto Vercel too. Here's what Vercel actually shipped, what I'd watch out for, and who I think should try it now.

A CI system runs your checks every time code changes, so nobody merges something broken. Most run the whole workflow on every push, even for a one-line change. Vercel's pitch is that this gets worse with coding agents, because agents open a lot of pull requests and each one waits on CI.

Vercel CI tries to do as little work as possible on each push. According to Vercel's docs, on every git push:

1. Turborepo finds the tasks you've tagged with "ci" in turbo.json.
2. Vercel Remote Cache is checked for tasks that have already run with the same inputs.
3. Only the uncached tasks run, in dependency order, each on its own machine sized for that task.
4. The result is posted back to GitHub as a check on the pull request.

Because it's a normal GitHub check, your existing branch protection rules can block a merge when it fails, the same way they do with a failing GitHub Action.

Yes. Vercel CI needs Turborepo 2.11.7 or later and Vercel CLI 64.3.1 or later. But you don't need to be running a big monorepo. Vercel says it works in single-package repos too: add a turbo.json file and the turbo package to a regular Next.js app.

The setup is small. You tag the tasks you want CI to run:

{
  "tasks": {
    "lint": { "tags": ["ci"] },
    "test": { "tags": ["ci"] }
  }
}

Then you enable it for the repo with vercel ci enable, or have your coding agent do the setup with the prompt Vercel provides. There's no separate workflow YAML file. Two details from the configuration docs worth knowing:

• Dependencies come along. If a tagged test task depends on build, Vercel CI runs the build first, even though you didn't tag it.
• Your environment variables won't show up on their own. Turborepo's strict mode drops any variable turbo.json doesn't list. Vercel's docs say a variable you add to Vercel CI doesn't reach your task until you list it in the task's env or passThroughEnv. Expect that to be the first "why is this test failing" moment.

The part I find most useful isn't the speed claim. It's that your checks can run against the deployment Vercel already built for that commit.

Vercel has a guide for end-to-end tests where a Playwright task waits for the Vercel deployment of the same commit, then tests that real URL. It works even when Deployment Protection is on. For a Next.js app, that means testing the preview deployment that will actually go live, not a dev server running on a CI machine. That's where bugs show up: middleware, environment variables, caching, images.

The other piece is agents. Vercel built this for coding agents to drive. Runs, tasks and logs are available through the Vercel CLI, Vercel MCP and Vercel's API. An agent can push a change, wait for the run, read the failing task's logs with something like vercel ci logs --failed, and fix it. If you're going to let an agent do that, scope its access first. CI logs and environment variables are the kind of thing an agent shouldn't get more of than it needs.

Vercel says that in its internal repositories, the wait from git push to "CI passed" is 2 to 6 times shorter than with its previous setup. Vercel also says Vercel CI has run nearly 8 million tasks across its own repos and the private beta.

That's Vercel's measurement on Vercel's code, and I haven't seen an independent benchmark. How much you gain depends on how your repo is split up. A big monorepo where most pushes touch one package benefits the most from skipping. A small single-app repo where every change touches the app will still run most of its checks. Caching and right-sized machines may still help, but I wouldn't expect 6x.

Vercel bills CI by the CPU minute, the same way it bills builds:

• Pro: $0.0035 per CPU minute.
• Enterprise: custom pricing.
• Hobby: the launch post says the beta is on all plans, but the pricing page doesn't list a Hobby rate or included minutes. I'd check before relying on it.

A CPU minute is one CPU for one minute. By default, the setup step for each run (cloning and installing dependencies) uses 4 CPUs, and each task uses 2. Tasks restored from cache or skipped don't use any.

Here's an illustrative example, using my own assumptions, not Vercel's. Say a push spends 1 minute on setup and then runs lint (1 minute), type-check (1 minute) and tests (3 minutes) at the defaults. That's 4 + 2 + 2 + 6 = 14 CPU minutes, or about 5 cents on Pro. Bump tests to 8 CPUs, or push 200 times a month, and it adds up differently, so watch the usage dashboard for the first month.

From Vercel's docs, as of launch:

• GitHub only. No GitLab or Bitbucket.
• git push is the only trigger. You can rerun a run from the CLI, but there are no scheduled runs.
• Linux only for the base image.
• The repo must be connected to a Vercel project, and not to projects on more than one Vercel team.
• It's a beta. Vercel says features and configuration may change. Before general availability, it plans to add advanced observability, a way to run CI before you push, and more granular test selection.

Try it now if your Next.js app already deploys on Vercel from GitHub, your CI is slow or expensive, or you're letting coding agents open pull requests and CI is the bottleneck.

Wait if you're on GitLab or Bitbucket, you need Windows or macOS runners, or your CI does a lot more than run checks (scheduled jobs, releases, deploying to other platforms). Those don't fit yet.

Either way, I'd run it in parallel with your existing CI on a low-stakes repo first. Don't make it a required check until it's agreed with your current setup for a couple of weeks. That's the same rule I use for every new tool in my AI coding setup: a trial, not a switch.

I build and maintain Next.js apps on Vercel for businesses in Nashville and Middle Tennessee, including CI, preview deployments and spending limits. If you want a second pair of eyes on whether Vercel CI fits your project, or help moving your checks over, get a free quote.

What is Vercel CI?

Vercel CI is Vercel's continuous integration service, launched in beta on October 28, 2026. It runs the Turborepo tasks you tag for CI when you push to GitHub, skips or restores from cache anything your change doesn't affect, and posts the result to your pull request as a check.

Does Vercel CI require Turborepo?

Yes, version 2.11.7 or later. It doesn't require a monorepo. Vercel says it works in single-package repos once you add turbo.json and the turbo package.

How much does Vercel CI cost?

On Pro, $0.0035 per CPU minute, matching Vercel's build pricing. Enterprise is custom. Cached and skipped tasks don't use CPU minutes. Vercel's pricing page doesn't list Hobby terms for the beta.

Is Vercel CI really 2-6x faster?

That's Vercel's claim, measured on its own internal repositories against its previous setup. Your results will depend on how much of each push your cache can skip.

Does Vercel CI work with GitLab or Bitbucket?

Not yet. At launch, GitHub is the only supported source, and git push is the only trigger.

• Vercel, "Introducing Vercel CI" (October 28, 2026)
• Vercel Changelog, "Vercel CI is now in beta" (October 28, 2026)
• Vercel Docs, "Vercel CI"
• Vercel Docs, "Vercel CI Pricing"
• Vercel Docs, "Vercel CI Configuration Reference"
• Vercel Docs, "Vercel CI Environment Variables"
• Vercel Docs, "Running End-to-End Tests in Vercel CI"
• Vercel Docs, "vercel ci" CLI reference
• Vercel on X, Vercel CI announcement (October 28, 2026)