Verx — AI dependency security for dev teams.
Scans the full transitive tree, clusters coupled packages into phased upgrade plans, and runs AI agents in isolated containers to fix breaking changes before a reviewer ever sees them. Built because npm audit fix is not a plan.
Volume is not a strategy
Dependabot opens a PR per package. Snyk opens a ticket per CVE. Both tools generate volume. Neither addresses the actual problem.
The actual problem is coupling. Bumping React means bumping React DOM. Bumping the testing library means the matchers break. Bumping a date library four levels deep surfaces a peer-dependency conflict in something you forgot you depended on. Forty Dependabot PRs in a mature codebase are not forty safe upgrades — they are forty conflicting experiments, each one breaking the next.
So teams defer. The security backlog grows. Eventually someone schedules “dependency week,” and that week turns into a production incident on the other side of a forced merge. We have watched this cycle at three separate shops. Verx exists because the cycle is not inevitable.
Upgrades run as workflows, not commits
Verx treats an upgrade as a workflow, not a commit. The workflow has five phases, each one a defined state with entry and exit conditions.
Setup
Clone the repo into a bind-mounted workspace. Detect the package manager. Snapshot the current lockfile. Record the baseline test results. Nothing has changed yet.
Pre-Verify
Run the project's tests, type-check, and lint against the baseline. If the baseline is broken, Verx refuses to upgrade on top of it. An upgrade stacked on a broken codebase is indistinguishable from a new regression.
Apply
Install the upgrade cluster. Resolve the lockfile. Commit to a per-phase branch (p1, p2, p3) so each phase is independently revertible.
Post-Verify
Re-run the test suite, type-check, and lint. If anything fails, hand off to the agentic fixer. If the fixer can't resolve it, the phase surfaces the failure with its stack and its diagnosis to the reviewer.
Commit
Open a PR per phase with a summary of what was upgraded, what broke, what got fixed automatically, and what is left for review.
The orchestrator is a persistent state machine. It is resumable. If a phase crashes or times out, the workflow can restart from the last successful state without re-running phases that already passed. lib/upgrade/orchestrator.ts is 53KB for this reason alone.
What belongs in each phase
Before Verx can orchestrate an upgrade, it has to decide what belongs in each phase. That is what Cluster Intelligence does.
Packages that declare each other as peer dependencies ship together or not at all. React and React DOM. Vue and Vue Router. A peer cluster is one unit.
Packages that import from each other across the project's source form a cluster. If your code uses zod through react-hook-form, bumping one forces a compatibility window with the other.
In a pnpm workspace with a Module Federation host, singleton packages are cluster constraints across workspaces — and the tool has to respect that across the whole repo, not per-package.
Each upgrade target is scored on battle-tested days since release and community adoption percentage. Freshly-published versions are held back. Long-tail bug-fix versions pass faster.
Clusters are ordered by constraint dependency. If cluster B requires a peer range that cluster A delivers, A runs first.
The part that makes it research-grade
Post-verify failures feed a registry. Over time, the registry builds up patterns: this error shape, against this package upgrade, against this framework version, is resolved by this edit.
The registry is not a static rulebook. It is confidence-scored. A fix that has resolved the same failure shape ten times against ten different codebases gets promoted to the auto-apply tier. A fix seen once stays in the suggest tier. A fix that has ever made things worse gets retired.
This is the feedback loop that makes Verx usable on monorepos in practice. The first upgrade on a new codebase is slow. The twentieth is fast — the failures the twentieth upgrade surfaces are mostly ones Verx has seen before.
lib/upgrade/failure-registry.ts is 49KB. It is the quietest piece of the system and does the most work over time.
Claude on the critical path. Gemini on the volume.
Verx runs two models. Claude (Sonnet 4) handles the critical path — agentic fix application, post-verify diagnosis, the commit summary. Google Gemini handles scanning, CVE correlation, and the bulk analysis tier.
Each provider has a circuit breaker. A 429-storm on one provider does not degrade the other. Cost-per-fix is tracked per provider, per model, per phase. The split is explicit.
Ephemeral containers, real build environment.
Each phase's apply-and-verify runs in an ephemeral container with the project's real build environment. Not a simulation. Not a shared worker. A fresh container per phase so state from a failed phase never leaks into the next.
The worker process tracks orphan containers and prunes them on startup and shutdown. This sounds like a small thing until you run upgrades at scale and discover what a leaked Docker network does to your cost bill.
What changed on the ground
- Average age of unresolved CVEs
- 94 days → 11 days
- Critical CVE resolution time
- Under 48 hours
- PRs per upgrade cycle
- 40+ → 4–6 clustered
- Review time on dependency PRs
- 10× reduction
- Kickoff to production
- 14 weeks
The scope underneath
- 247K lines of TypeScript across 1,003 files in 393 directories
- 149 API endpoints across 20 domains
- 70+ Prisma tables modeling projects, dependencies, scans, upgrades, teams, orgs, subscriptions
- 51 upgrade-engine files, 27 scanner files
- Monorepo-aware: workspace graph, Module Federation singletons, inter-workspace dependency tracking
- Supply-chain intelligence: package health scoring, suspicious-package detection, EPSS integration
- Codemod registry covering Next.js, React, TypeScript, ESM, Angular, and Vue migrations
- 85 test files across unit, API, flow, and smoke tiers
“We went from dreading dependency day to barely noticing it. Verx groups the updates intelligently, fixes the breaking changes before we even look at the PR, and tells us exactly what each change touches. Our security backlog is basically empty now.”
Common questions
What is Verx?
Verx is an AI-powered dependency security platform for dev teams. It scans full dependency trees against CVE databases, clusters related packages for safe batch updates, runs AI agents in isolated containers to fix breaking changes, and maps blast radius so you know what a change affects before you merge.
How is Verx different from Dependabot or Snyk?
Dependabot and Snyk generate alerts for individual packages. Verx goes further: it clusters coupled packages into safe batch updates, runs AI agents in sandboxes to actually fix breaking changes, and maps the full blast radius of each update. Instead of 40 individual PRs, you get 4–6 clustered PRs with pre-fixed breaking changes.
What package managers does Verx support?
Verx supports npm, pip, Maven, Go modules, and Cargo. It parses lock files and manifest files to build the full transitive dependency graph — not just direct dependencies, but every package in the tree.
How do the sandboxed AI agents work?
For each upgrade cluster, an AI agent spins up in an isolated container with the project’s full build environment. The agent applies the upgrades, runs the test suite, diagnoses any failures, and patches breaking changes. If all tests pass, it opens a PR. If something can’t be auto-fixed, it opens a PR with a detailed analysis of what broke and why.
What is blast-radius mapping?
Blast-radius mapping uses static analysis to trace which files, imports, and downstream packages a proposed dependency change touches. Before you merge an upgrade, you see exactly what parts of your codebase are affected — no guessing, no surprises.
How does Verx prioritize CVEs?
Verx scores CVEs using a composite of severity (CVSS), exploitability (is there a known exploit in the wild?), and blast radius (how much of your codebase does this dependency touch?). This produces more actionable prioritization than CVSS score alone.
How long did it take to build Verx?
Verx went from kickoff to production deployment in 14 weeks. The build ran in four phases: dependency graph analysis, clustering algorithm development, sandboxed agent remediation, and blast-radius mapping. Each phase was validated against real monorepos.
What results has Verx delivered?
The average age of unresolved CVEs dropped from 94 days to 11 days. Critical CVEs are resolved within 48 hours. Clustered upgrades replaced 40+ individual PRs with 4–6 organized PRs. Code review time for dependency updates dropped by 10×.
Got an agentic system that has to survive production?
The 5-phase orchestrator, the failure registry, the dual-AI cost routing — these are the patterns that separate a demo from a platform. If you're building something that has to run unattended on a team's codebase, we have done it.