Vercel CI Beta Released: Run Turborepo with a Single Line of Config

Vercel recently announced that Vercel CI has entered beta, offering Turborepo users continuous integration that runs with a single line of configuration. This move pushes the cost of configuring CI down to nearly zero while making "only run affected CI" the default behavior.

According to the official Vercel blog, in Vercel's internal repositories, the wait time from git push to "CI passed" has been reduced by 2-6x, which the company says significantly improves CI's ability to keep pace with the output speed of coding agents.

The Design Logic Behind a Single Line of Config

Onboarding to Vercel CI is very straightforward: simply tag a task with ci in turbo.json. In the official example, adding ci to the tags array of the lint task causes that task to run on Vercel CI on every push.

This design extracts "which tasks belong to CI" from pipeline scripts and makes it part of the repository configuration. For teams already using Turborepo to manage a monorepo, there's no need to write additional YAML pipelines or sync task lists across platforms—the single source of truth for configuration stays in turbo.json.

A Setup Prompt for Coding Agents

Vercel also provides an onboarding method aimed at AI coding agents: have the agent run npx skills use vercel/ci@setup in the repository, then follow that skill's guidance to select initial tasks, configure Vercel CI, and submit a PR. This effectively hands CI onboarding itself over to the agent, closing the loop with the current workflow of "agents write code, CI verifies code."

Turborepo and turbo.json: Turborepo is a monorepo build system maintained by Vercel. Its core idea is to bring the tasks of every package in a monorepo (such as build, test, and lint) into a unified task graph and compute the affected scope based on file changes. turbo.json is the system's configuration file, declaring task dependencies and inputs/outputs via the tasks field (formerly pipeline in older versions), thereby enabling task-level caching and parallel scheduling. Vercel CI's choice to introduce a tags field in turbo.json to mark CI tasks leverages the fact that this task graph already describes which tasks depend on which files, so the platform can determine affected tasks without parsing a YAML pipeline.

Four Things Automated

According to the official documentation, every task tagged with ci runs on each push, and Vercel CI automatically handles the following:

• Running only CI affected by code changes
• Caching tasks via Vercel Remote Cache
• Installing dependencies only once per run
• Caching dependencies across multiple code updates

The first three address typical monorepo CI pain points: running all tasks wastes compute, repeated builds slow feedback, and dependency installation is repeated on every run. The fourth targets consecutive pushes, allowing dependency caches to be reused across multiple commits.

Why "2-6x" Is Worth Noting

The 2-6x reduction in wait time comes from measured data on Vercel's internal repositories, not a general benchmark. The breadth of this range indicates that the benefit is strongly correlated with repository structure, task granularity, and cache hit rate.

More noteworthy is the motivation stated officially: CI needs to keep up with the output pace of coding agents. When agents can commit code at high frequency, CI queuing and execution time become the new bottleneck, and "only run affected tasks + two-layer caching of dependencies and tasks" is the direct means of compressing that bottleneck.

Remote Cache and Affected Task Filtering: Turborepo's caching has two layers, local and remote. Before executing a task, Turborepo computes a hash of the task's inputs (source files, dependencies, environment variables, command arguments, etc.); if the hash hits the cache, it replays the logs and artifacts directly without actually executing. Remote Cache places this cache in team-shared storage, so CI machines, developers' local environments, and different CI runs can reuse the same results. Affected task filtering relies on Turborepo's package dependency graph: a commit only triggers tasks for packages whose changes fall within its dependency closure, and unaffected tasks are skipped entirely. Together, these two produce the combined effect of "only run what should run + don't re-run what has already run."

Relationship to Existing Turborepo Workflows

Turborepo itself already provides task pipelines and remote caching. Vercel CI's increment is hosting the execution environment on Vercel's side and enabling affected task filtering by default. For teams already deploying on Vercel, CI and deployment live on the same platform, so configuration and caching can be reused.

Note that this feature is currently in beta. The official information focuses on onboarding and automation capabilities, and does not disclose pricing, concurrency limits, or migration paths from other CI platforms. Teams should pay attention to these undisclosed details when evaluating.

What Platform Lock-in Means: Vercel is a platform that started with frontend and full-stack deployment, and its build and runtime systems are deeply integrated with Git repositories; deployment artifacts, environment variables, and preview environments are all managed by the platform. Vercel Remote Cache, as one of its platform services, could previously be used by local Turborepo. Vercel CI hosting the execution environment entirely on this platform means CI runs and deployments share the same caching and credential system, but it also means pipeline portability is limited by Vercel's account, billing, and quota model—migrating to another CI platform requires rebuilding caching and task filtering logic.

How to Get Started

The official documentation offers two paths: first, add the ci tag to tasks in turbo.json that should participate in CI; second, have a coding agent run npx skills use vercel/ci@setup and follow the guidance to complete configuration and a PR. For more information, see the Vercel blog, official documentation, and community announcement discussions.

Contributors to this feature include William Bout, Mitul Shah, Mehul Kar, and Vojtech Miksu.

Summary

Vercel CI's core proposition is to deliver a CI experience of "only run what should run, cache what can be cached" with minimal configuration, with reduced wait time as its main selling point. For Turborepo users, the onboarding barrier is already as low as a single line of config; the real decision point is the feature boundaries during beta and the degree of platform lock-in.

One-line Summary

Vercel CI enters beta, giving Turborepo users hosted CI that runs only affected tasks with a single line of config.

Paragraph Summary

Vercel announced that Vercel CI has entered beta: Turborepo users can onboard simply by adding a ci tag to tasks in turbo.json, with no YAML pipeline needed. Vercel CI by default runs only tasks affected by code changes, combines Vercel Remote Cache for task caching, installs dependencies only once per run, and reuses dependency caches across multiple pushes. Vercel says wait time from git push to CI passed in internal repositories has been reduced by 2-6x, mainly to let CI keep pace with high-frequency output from coding agents. Vercel also offers an onboarding method for AI coding agents via npx skills use vercel/ci@setup, which can automatically complete configuration and submit a PR. The feature is currently in beta; pricing, concurrency limits, and migration paths have not been disclosed, and the degree of platform lock-in is a key consideration for teams evaluating it.