Vercel launches CI beta that skips unaffected build and test tasks

• Vercel CI is in beta on all plans, with 2-6× faster internal CI, according to Vercel's announcement.
• Unaffected tasks are skipped using Turborepo's dependency graph; the launch explanation describes backend changes bypassing frontend lint while retaining end-to-end tests.
• Language-level dependency tracing remains future work, as one launch reply explains.

Even a single-package repository can use Vercel CI. The configuration reference has an easy-to-miss restriction: tools installed outside the repository directory never reach task machines. Dagger 1.0 beta, released five days earlier, also reads native toolchain configuration and runs GitHub checks without workflow YAML.

Tasks opt into CI through turbo.json, rather than a separate workflow file:

The configuration reference defines how those tags compose:

• Dependencies of selected tasks run too, following Turborepo's dependsOn graph.
• Package-level configuration can enable tasks independently of the root configuration.
• !ci overrides ci for task selection, but a task tagged !ci still runs when another selected task depends on it.

Reusing the local task graph is the best part of this launch. Jared Palmer, who pitched Turborepo in 2021, said agents now make it trivial to move shell scripts into packages in that graph.

Vercel attributes its speedup to both avoiding work and changing execution. The company says nearly eight million tasks have run across its repositories and private beta; the reported 2-6× improvement measures internal wait time from git push to “CI passed,” according to the launch post.

The execution mechanics are:

• Caching: Remote Cache is enabled by default. Tasks with unchanged inputs can be restored from cache.
• Bootstrapping: A separate instance clones the repository and installs dependencies. Vercel saves the repository directory for task instances to start from.
• Scheduling: Uncached tasks run on separate Hive machines and start as soon as their dependencies finish.

Resource allocation has concrete defaults in the configuration docs:

• Tasks receive 2 CPUs and 4 GB RAM by default.
• ci:cpus:8 assigns a task 8 CPUs and 16 GB RAM. The maximum is 32 CPUs and 64 GB RAM.
• Dependency installation defaults to 4 CPUs and 8 GB RAM, with its own resource override in vercel.json.

Agents can configure the repository using the setup skill described in the launch instructions:

The skill selects initial tasks, configures CI and opens a pull request. For debugging, the launch post documents these commands alongside dashboard and MCP access:

These expose runs, task status, task-specific stderr and searches across recent run logs. Distributed execution before pushing remains on the roadmap.

Package granularity constrains how much work the graph can eliminate. When challenged about coarse packages, cramforce suggested having an agent split them more finely.

In another reply, cramforce said selection would be conservative and described tracing language-level dependencies as future work.

Vercel CI posts a GitHub check, so existing branch protection rules can block merges when tasks fail, according to the documentation.

The launch discussion also explored less gated workflows: cramforce asked what stopped a user pushing to main and opposed merge queues. He argued that reverting rare main-branch breakages was preferable to adding overhead on every merge.

The beta documentation lists these requirements and restrictions:

• Turborepo 2.11.7+ and Vercel CLI 64.3.1+.
• Linux task images only.
• GitHub is the only supported source forge, and git push is the only supported trigger.
• The repository must connect to at least one Vercel project, with no projects spanning multiple Vercel teams.
• CI must be explicitly enabled with vercel ci enable.

Beyond the pre-push execution work, Vercel's announced roadmap includes advanced observability and more granular test selection. Its launch thread also teased other work still in the pipeline.