vlt 1.0 arrives as an npm replacement and blocks malware in its own registry

vlt, a JavaScript package manager and registry built by the original creators of npm, launched version 1.0 as a drop-in replacement for npm. Alongside the client comes general availability of the hosted registries and ecosystem mirrors. The central promise, in the words of founder Darcy Clarke on X, is a client "built so that nothing runs on your machine just because you typed install."

For those writing Node.js software in Brazil, what matters is not just another manager in the race for install speed. It's the shift in the supply chain security model, which is where the attacks have been happening.

The separation between install and build

npm does everything in a single step: it downloads, extracts, and runs the lifecycle scripts (like postinstall) of each package. It's exactly this automatic chaining that supply chain attacks exploit, malicious code runs the moment you install.

vlt breaks this into two steps. vlt install downloads and extracts packages without running anything. vlt build runs the scripts, but only for packages you trust, and by default skips anything flagged as malware:

$ vlt install   # downloads packages, no script runs
$ vlt build     # runs approved scripts, blocks known malware

In practice, this means a compromised package can reach your node_modules without even getting a chance to run, the decision to run scripts becomes an explicit choice of yours, not a side effect of install.

Querying the dependency tree

The second standout feature is vlt query, a selector syntax that treats the dependency graph as a DOM tree. There are more than 60 CSS-style selectors, and about half of them are focused on security, powered by an integration with Socket. This allows auditing dependencies at scale, which matters for teams managing dozens of projects.

There are details that go beyond a single project: the :host(local) selector extends queries to every project on the machine, and the --view=mermaid flag renders the dependencies found as a diagram. For anyone who needs to map where a problematic dependency appears across multiple repositories, it's an auditing tool built into the manager.

Blocking at the registry, not just the client

vlt's strongest differentiator is its hosted registry, which rejects known malicious packages before serving them. According to InfoQ, vlt has already flagged more than 275,000 package versions, and reviewers note that a quarter of them are still installable on npm.

This number puts the move in context. It's not just the client that protects itself, the distribution point itself filters. The registry API is compatible with npm, so existing CI pipelines, private registries, and tooling keep working.

What the competitors have already done

vlt doesn't appear in a vacuum. After a year marked by supply chain attacks, like the Shai-Hulud worm, the entire ecosystem has been moving:

| Tool | Security measure | |---|---| | npm v12 | Disables install scripts by default | | pnpm | Quarantines new releases with a minimum release age | | Bun | Blocks postinstall scripts | | vlt 1.0 | Rejects bad packages in its own registry |

The difference is where the barrier sits. npm, pnpm, and Bun act on the client or on install policy. vlt moves part of the defense to the infrastructure that serves the packages.

Some honesty about performance is warranted: in raw install speed, pnpm and Bun remain ahead. vlt reports its registry as up to 38% faster than npm, not as the fastest on the market. In other words, choosing vlt means choosing the security model and graph auditing, not chasing a cold install speed record.

The five-second pitch

On Hacker News, where the launch made the front page, the reception was mixed. One commenter praised something that "will benefit the entire ecosystem," while others asked Clarke to explain the pitch "in five seconds or less." His response:

5s: save time and money.

>

10s: vlt helps engineering teams build JavaScript software faster, reduce supply chain risk, and lower infrastructure costs (via API and payload performance optimizations).

>

20s: if you've been using npm for years and have been narrowly dodging the various malware attacks, or you're responsible for high CI/agent bills because cold installs are X% of the time compared to your actual build/runtime, then take a look at us.

>

-- Darcy Clarke, founder of vlt

The CI cost angle deserves attention in the Brazilian context: with AI agents and pipelines running cold install all the time, install infrastructure cost becomes a concrete expense line, and it's part of the pitch.

How to migrate

According to InfoQ, the migration steps are small. After installing globally, you can run vlt install and vlt build on an existing project:

npm install -g vlt
# on an existing project:
vlt install
vlt build

Configuration moves from .npmrc to vlt.json, and there's a new vlt-lock.json lockfile. Since the registry API is compatible with npm, CI, private registries, and tooling keep working, which reduces the friction of testing it on a real project. The full path is in the migration guide.

vlt is free and open source under the BSD-2-Clause-Patent license, developed by vlt technology inc., and already available via npm i -g vlt.

What remains open

The malware database behind the registry-level blocking is the heart of the proposal, and it raises questions the launch hasn't yet answered definitively: how fast are new attacks catalogued, what's the false-positive rate that could block a legitimate build, and what does it mean to depend on a registry hosted by a specific company instead of the public npm. For a Brazilian team evaluating adoption, the honest test is to run vlt install/vlt build in parallel with the current workflow and measure both the friction and the packages actually blocked before switching for good.