Why that npm package won't install in Bolt.new (it's not your code)

You ask Bolt to add password hashing, or a local SQLite database, or basic image resizing — normal, boring backend stuff — and the install just fails. Sometimes it’s a wall of node-gyp errors. Sometimes it’s a single line you’ve never seen before: Cannot load native addon because loading addons is disabled. The package is popular, it’s on every “how to build X” tutorial, and it works fine on your own machine. It still won’t install in Bolt.

If you’re staring at that error, the package isn’t broken and neither is your code. Bolt can’t run it, structurally, and no amount of asking it to “try again” fixes that.

Why this happens

Bolt.new doesn’t run your project on a server somewhere — it runs Node.js inside your browser tab, in a sandbox called a WebContainer (built by StackBlitz, the same tech behind bolt.new’s editor). That’s what makes the instant preview possible: there’s no VM to provision, no container to pull, the whole runtime is already sitting in your browser as WebAssembly.

The tradeoff is that a browser tab can only execute JavaScript and WebAssembly — it has no way to run compiled C or C++ binaries, which is exactly what a “native” npm package is. Packages like sqlite3, better-sqlite3, bcrypt, and canvas all ship a .node file: a compiled addon that talks to your operating system directly. WebContainers disable loading native addons outright (internally, Node is started with --no-addons), so the moment npm tries to install one and run its postinstall build step, it either fails outright or installs and then dies the first time your code actually calls into it.

It’s easy to miss because the failure doesn’t always look like a missing feature — it looks like a broken install, so the instinct is to ask Bolt to fix the error, and it’ll happily thrash: reinstalling, clearing the cache, swapping package versions. None of that helps, because the constraint isn’t in your dependency tree, it’s in what a browser is physically able to execute.

How to tell if this is your problem

1. Read the actual error, not just “install failed.” node-gyp, python not found, make: command not found, or Cannot load native addon because loading addons is disabled are all the same underlying issue — a compiled binary that WebContainers won’t run.
2. Check the package for a .node file or a binding.gyp. If its GitHub repo has either, it’s a native addon and this is almost certainly what you’re hitting.
3. Try the same npm install locally. If it installs clean on your own machine but fails only in Bolt, that’s the WebContainer sandbox, not a real dependency conflict.

The fix

Swap the package for a pure-JS or WASM build of the same thing, not a different tool from scratch — most native packages have one:

• bcrypt → bcryptjs (same API, pure JS, slower but fine for typical app-level hashing)
• sqlite3 / better-sqlite3 → sql.js (SQLite compiled to WASM) if you genuinely need an in-browser/local file DB, or drop the local file entirely
• canvas → skip it; do image work through a hosted API instead of a native binding

For anything that’s really a database, move it off the local filesystem and onto a hosted service reached over HTTP — Supabase, Turso, or Neon all give you a real Postgres or SQLite-compatible database that your WebContainer talks to over the network instead of trying to compile a driver for it. This is usually the better fix even outside Bolt: a database file living inside a browser sandbox was never going to survive a redeploy anyway.

Sharp is the one documented exception, and it’s worth knowing about specifically. StackBlitz ported sharp’s underlying image library to WebAssembly so it runs natively inside WebContainers — if the task is image resizing/cropping and you were reaching for sharp, try it before assuming you need a workaround. It’s a real, deliberate carve-out, not a sign that other native packages are secretly fine too.

Before adding an unfamiliar dependency, ask Bolt directly: “does this package require native compilation, or does it ship a pure-JS/WASM build?” It can check the package’s package.json for a gypfile field or a binding.gyp in the repo — cheaper than discovering it after a failed install.

How to avoid this next time

Anything touching cryptography, image/video processing, or local file-based databases is worth a 30-second check before you ask Bolt to install it: search “<package name> webcontainer” or look for a .node file in its repo. If it’s native, look for the WASM or pure-JS sibling first — nearly every popular one has been ported by now — and default to a hosted service over anything that expects to compile against a real operating system, because in Bolt, there isn’t one.