Vercel CI enters Beta, running only the tasks your code change affects
Vercel has launched Vercel CI in Beta, a continuous integration service that runs only the tasks affected by a code change and provisions only the compute those checks need. According to Vercel, the time from git push to "CI passed" in its own repositories is now 2-6x faster than before.
- Vercel CI is in Beta on all plans and runs only tasks affected by a code change.
- According to Vercel, push-to-"CI passed" time in its own repositories is 2-6x faster.
- It uses Turborepo and turbo.json, with a "ci" tag to select tasks and Remote Cache on by default.
- Tasks run on separate machines powered by Hive, Vercel's compute layer.
- Vercel plans advanced observability, pre-push distributed execution and finer test selection before general availability.
Built for the volume of agent-written code
Vercel points to a growing bottleneck: coding agents are opening more pull requests than ever, and each one waits on CI before anyone can review or merge it. Most CI systems run the entire workflow on every push, even for a one-line change, so the more agents push, the more time teams spend waiting.
Vercel CI is the company's answer. It runs only the tasks affected by a change and spins up only the compute those checks need, which Vercel compares to the way Fluid compute scales with traffic. Vercel says its own CI now keeps up with its coding agents.
How it works
Vercel CI relies on Turborepo to understand tasks and the dependencies between them. It reads turbo.json, so teams already using Turborepo do not need a separate CI configuration. Those not on Turborepo yet can add turbo.json and the turbo package, and Vercel says it also works in single-package repositories.
Setup starts by tagging the tasks that should run in CI, using "tags": ["ci"] inside the task definition. According to Vercel, there is no workflow YAML to maintain, no drift between the CI config and turbo.json, and Remote Cache is on by default.
On each push, from a person or an agent, Vercel CI works out which tasks need to run. Tasks whose inputs have not changed are served from cache. The remaining tasks each run on their own machine, powered by Hive, Vercel's compute layer, and start as soon as their dependencies finish. The changelog adds that dependencies are installed once per run and cached across code updates.
Teams can set it up by following the documentation or by prompting a coding agent in the repository with the command npx skills use vercel/ci@setup, which selects initial tasks, configures Vercel CI and opens a pull request.
Inspecting runs and merging
Runs can be watched through the Vercel dashboard, the Vercel CLI or Vercel MCP. When a check fails, users can go straight to the failing task, see what is blocked behind it and open its logs. They can also search recent runs to see whether a test has been flaky.
The CLI commands listed by Vercel include:
- vc ci ls to list CI runs for the repository
- vc ci inspect to list the tasks for a run
- vc ci logs to get logs for all tasks in a run, or for a specific task
- vc ci grep to search across run logs for a string
Vercel CI posts a check to the pull request on GitHub, so existing branch protection rules can still block merges on failure.
What comes next and availability
Vercel says Vercel CI has already completed nearly 8 million tasks across its own repositories and the private beta. Ahead of general availability, the company plans to add advanced observability, a vc ci CLI command for distributed execution before pushing code, and more granular test selection.
Vercel CI is available in Beta today on all plans. For teams already on Turborepo, the pitch is a small change: tag the tasks that matter and let the service decide what to run. Vercel's speed figures come from its own internal repositories, so results in other codebases may differ.
