Skip to content
vxvx
GitHubBlueskydev.toRSS
Newv0.0.654Runs follow the lock, workers end on time

Task orchestration you own.

vx runs and caches your task graph correctly, and a plugin can fill every stage after that.

  • 15pipeline stages a plugin can fill
  • MITsandbox, remote cache and remote execution, no paid tier
  • 0daemons, accounts or cloud services to run it
Quickstart →GitHub
vx run ci --all on the starter: cold, three tasks run; again, three up-to-date.

// 1008 cases · 6 tools · one neutral suite

Correct, case by case.

Every test in vx, Turborepo, Nx, Vite Task, Nix and moon, parsed into one suite: each case runs sandboxed against each tool and counts only outcomes.

  1. vx99%supports 99%
  2. Turborepo62%supports 91%
  3. Nx64%supports 93%
  4. Vite Task50%supports 75%
  5. Nix47%supports 71%
  6. moon58%supports 89%
Every case, every tool →

// your ci, your servers

Distributed task execution, a shared cache, shared history. Self-hosted.

Each is a plugin and a server you deploy on Bun, Docker or Cloudflare Workers, with no account and no paid tier.

Distributed task execution

@vzn/vx-dte + @vzn/vx-dte-server

One run spread over the workers your own CI starts, through a relay that stores nothing.

Remote cache

@vzn/vx-cache + @vzn/vx-cache-server

CI writes and everyone reads, from one bucket on Bun, Docker with S3, or Workers with R2.

Shared run history

@vzn/vx-history + @vzn/vx-history-server

Task timings from every CI run, so each run starts the critical path first.

// ai first

The build your agents can run.

bunx skills add vznjs/vx

One skill teaches any coding agent the CLI: run tasks, read failures and history, ask why.

  • vx run
  • vx last --failed
  • vx last --stats
  • vx why
  • vx docs
Built for agents →

vx why

A re-run names its cause, down to the file that changed.

$ vx why @demo/web#build
  verdict    cache key changed: upstream @demo/ui#build
  root cause:
    @demo/web#build ← @demo/ui#build ← file packages/ui/src/index.ts
How vx why works →

--format json

Every report verb prints JSON with a published schema, and failures keep their full log.

  • vx show
  • vx info
  • vx last
  • vx why
  • --dry=json
Every command →

// extensibility is king

What vx can do. Not what it is limited to.

Every plugin below is a separate package on core’s public plugin API, and yours can be too.

Keep the cache you have

@vzn/vx-migrate

Keep Turbo’s or Nx’s remote cache while you move to native config.

Observability

@vzn/vx-otel

Every run and task in any OpenTelemetry backend.

CI results on the PR

@vzn/vx-ci

GitHub job summary and Checks.

Precise lockfile keys

@vzn/vx-lockfile

Each task keyed on its own dependency closure: pnpm, bun, npm, yarn.

Bazel remote cache and execution

@vzn/vx-reapi

For a Bazel REAPI server you already run: NativeLink, BuildBuddy.

Your own

definePlugin()

Fill any of the 15 stages: where tasks run, where the cache lives, who watches, what the terminal draws, which commands exist.

// 9,603 tasks · 1,601 projects · 30 levels · identical commands, identical concurrency

Fast, never at the cost of a correct cache.

Nothing changed
vx412 ms
Turborepo484 ms
Nx7.90 s
Vite Task6.46 s
Nothing changed, outputs restored
vx817 ms
Turborepo1.04 s
Nx7.72 s
Vite Task6.33 s
Cold build
vx6.26 s
Turborepo10.34 s
Nx2 min 44 s
Vite Task6.49 s
Cold build: CPU the runner burns
vx40.63 s
Turborepo1 min 16 s
Nx5 min 4 s
Vite Task21.09 s

Time each tool adds over the ideal run; lower is better.

Benchmark workload: a synthetic monorepo of 1,601 projects and 9,603 tasks in 30 dependency levels, five core libraries a quarter of the projects use; build 300 ms, test and typecheck 150 ms, lint 75 ms, publish 30 ms; real repos with uneven task times will differ.

Measured: vx 0.0.0 @ c2adbdd66 on 2026-11-12, Turborepo 2.11.10 on 2026-11-12, Nx 24.0.2 on 2026-11-12, Vite Task 1.4.0 on 2026-11-12; linux x64, 4 cores (AMD EPYC 9V45 96-Core Processor), 16 GB.

  • Nothing boots per task. No daemon, no Node process per task: vx spawns your command.
  • Hashing without reading. On a clean tree, cache keys come from git’s index.
  • One pass over the repo. One git walk per run; each stat and lookup happens once.
Benchmarks: tables, methodology, reproduce it →Every tool on one suite of cases →

// shipping every day

New in vx.

Every release →The blog →
Latest release · v0.0.654

Runs follow the lock, workers end on time

A run reads every project from the lock, turbo() and nx() mappings too.

Nov 11, 2026Read the release →
  1. Nov 7, 2026v0.0.653Worker types, one line per task
  2. Nov 6, 2026v0.0.652Flaky retries, sealed sandboxes
  3. Nov 5, 2026v0.0.651One look, locked dependencies

From the blog

Turborepo, Nx and Vite Task undo your commit on a cache hitNov 10, 2026A sandboxed task reads what it depends on, and nothing beside itNov 7, 2026DTE workers that fit the work, and a footer that says how full they ranNov 7, 2026

// three commands

Start in a minute.

bunx @vzn/vx init    # installs vx, writes .vx/workspace.ts and an empty vx.config.ts
vx lock              # after you declare a task in vx.config.ts
vx run build         # runs it and stores what it writes
vx run build         # again: up-to-date, from the cache

Coming from Turbo or Nx: the same vx init writes the native vx config from it.

Quickstart: your first cached task →Migrate from Turbo or Nx →

// one run, after you edit app

Everything vx does, in one picture.

at oncesandboxa run’s stages✕ deniedutils#buildfrom cacheui#buildfrom cacheapi#buildfrom cacheapp#buildyou edited app../secrets.envgraphkeyscheduleruncachetelemetryremote cacheOpenTelemetry①②③④✎ runs⑤⑥yours plugs in the same wayat oncesandboxa run’s stages✕ deniedutils#buildfrom cacheui#buildfrom cacheapi#buildfrom cacheapp#buildyou edited app../secrets.envgraphkeyscheduleruncachetelemetryremote cacheOpenTelemetry①②③④✎ runs⑤⑥yours plugs in the same way
One run of vx run build, after you edit app.
  1. 1Tasks. app builds after what it uses.
  2. 2Parallel. ui and api build at once.
  3. 3Cache. Unchanged work comes back from the cache.
  4. 4Only what changed. You edited app; only app runs.
  5. 5Sandbox. A workspace file you did not declare is out of reach.
  6. 6Plugins. Swap the cache, runner or telemetry. No fork.

// what you can count on

Correct. Sandboxed. Extensible. Free.

Correctness

A task’s cache key covers every file, setting and env var it declares.

Caching in depth →

Sandbox

A sandboxed task cannot read a workspace file it did not declare.

Sandboxing →

Extensibility

Plugins decide where tasks run, where the cache lives and who watches.

Writing a plugin →

Freedom

MIT, no paywall, no cloud, no account.

Migrate →

// 113 features, a page each

And everything else.

Cache you can trust

Sandboxed tasks

An undeclared read or write fails the task and names the path.

See inside a run

vx why

Ask why a task re-ran, and get the input that changed.

Cache you can trust

Outputs are exactly the snapshot

A module you deleted never comes back from the cache.

CI

Run only what a change reaches

--affected follows task edges from the change, and nothing else runs.

Everyday use

Dev servers in the graph

A server is ready when it prints a line, not after sleep 5.

Everyday use

Watch mode

Every change takes the same path as vx run, and the key decides what re-runs.

Plugins

Remote cache and execution

Spread one run over your own CI’s machines.

See inside a run

A skill for your coding agent

An installable skill teaches an agent to run, debug and query vx.

All features →
Turborepo, Nx and other product names are trademarks of their owners. vx is not affiliated with or endorsed by them.