vlt 1.0 shipped this week as a drop-in replacement for npm, and it arrives at a moment when the JavaScript ecosystem is actively rethinking how package managers handle untrusted code. Built by the original creators of npm, vlt splits the install process in two: download first, execute later. The hosted registries reject known-malicious packages before they are served. It is the most opinionated take on npm's supply chain problems to reach general availability.
Phased installs as the default model
The core design change is in how vlt handles lifecycle scripts. npm downloads, extracts, and runs install scripts in a single step. When you type npm install, every package in the dependency tree gets to execute code on your machine. vlt breaks that into two commands. vlt install downloads and extracts packages without running anything. vlt build then executes scripts only for the packages you have approved, skipping anything flagged as malware by default.
This is not a security flag you have to remember to set. It is the only install model vlt offers. The separation means you can inspect what was downloaded before anything runs, and you can approve or deny scripts on a per-package basis. For teams that have been burned by a malicious postinstall script in a transitive dependency, this is a meaningful shift in the default security posture.
A dependency graph you can query
The second major feature is vlt query, a selector syntax that treats the dependency graph like a DOM tree. Around half of the 60-plus available selectors are security-focused, powered by a Socket integration that identifies patterns associated with malicious packages. Teams can audit dependencies at scale using CSS-like selectors rather than writing custom scripts to walk the tree.
A :host(local) selector extends queries across every project on a machine, which is useful for identifying shared vulnerable dependencies across a monorepo or a collection of repositories. The --view=mermaid flag renders matched dependencies as a diagram, giving a visual representation of the dependency chain that is easier to reason about than a textual list.
This is not new functionality in the abstract. Tools like Socket, Snyk, and npm audit already scan dependency trees for known vulnerabilities. What vlt changes is the interface. Instead of running a separate audit tool against a lockfile, you query the live dependency graph with a syntax designed for composability. Security checks become part of the development workflow rather than a CI step that runs after the fact.
Hosted registries that block bad packages
vlt's hosted registries reject known-malicious packages before they are served to clients. The team has flagged more than 275,000 package versions, and reviewers have noted that a quarter of those flagged versions are still installable on npm. This is not a hypothetical problem. The npm registry's open nature means that once a malicious package is published, it remains available unless the maintainer or npm actively removes it. vlt's registry takes the opposite approach: bad packages are excluded by default.
The registry is compatible with the npm API, which means existing CI pipelines, private registries, and tooling continue to work. Teams do not have to rewrite their deployment infrastructure to use vlt. The hosted registry is also up to 38 percent faster than npm, though pnpm and Bun still report faster raw install speeds overall.
How it compares to what pnpm and Bun already do
vlt is not arriving in a vacuum. npm v12 now disables install scripts by default. pnpm quarantines fresh releases with a minimum release age requirement. Bun blocks postinstall scripts too. The entire ecosystem is moving toward restricting automatic code execution, and vlt is the most aggressive implementation of that direction.
The difference is scope. pnpm and Bun treat script blocking as a feature you can toggle. vlt makes it the fundamental architecture. There is no single-step install that runs scripts. You always install, then build. That architectural choice makes the security model simpler to reason about, even if it changes the mental model for developers accustomed to npm install doing everything at once.
On raw install speed, the picture is mixed. vlt reports its registry as faster than npm, but pnpm and Bun still lead on cold install benchmarks. For teams that have optimized their CI around install speed, vlt's phased model adds a step, which could increase total wall-clock time even if the individual steps are faster.
Migration and licensing
Migrating from npm is straightforward. Install with npm i -g vlt, run vlt install and vlt build in an existing project, and move configuration from .npmrc to vlt.json. The lockfile format changes to vlt-lock.json. The migration guide covers the details.
vlt is free and open source under a BSD-2-Clause-Patent license, developed by vlt technology inc. The release reached the Hacker News front page, where founder Darcy Clarke pitched it as a way to reduce supply chain risk and lower infrastructure costs through API and payload optimizations. Whether the phased install model becomes the new default depends on whether teams are willing to change their muscle memory around npm install. The security argument for doing so is stronger than it has ever been.