When a start fails while installing dependencies, the error is specific and sits near the top of the console — not in your code at all. This guide reads the three failures you'll actually hit (two npm, one pip), each with its verbatim message and its fix.
No formal prerequisites beyond having an app that installs packages. It's the install-phase companion to When your server won't start.
Look at the top, not the bottom
Every start installs your dependencies before your code runs — npm output for Node, pip for Python. If the install fails, your app never even starts, so the real error is up in that install section, above any later noise.
💡 Tip: Scroll to the first failing line — it names the package that broke.
The three failures you'll actually hit, at a glance:
| Error | What it means | Fix |
|---|---|---|
| npm E404 | Package name doesn't exist — usually a typo | Correct the name, restart |
| npm ETARGET | The version you pinned doesn't exist | Loosen or fix the version, restart |
| pip could not find a version | Bad package name, or a version that isn't published | Fix the name or version, restart |
npm: E404 — no such package
npm error code E404
npm error 404 Not Found - GET https://registry.npmjs.org/expresE404 means npm asked the registry for a package that doesn't exist — almost always a typo (expres for express) or a name that was never published. Fix: check the exact name on npmjs.com, correct it, and restart. The Packages page's search box queries the real registry, so installing from there sidesteps the typo entirely.
npm: ETARGET — no such version
npm error code ETARGET
npm error notarget No matching version found for express@^99.0.0.Here the package exists but the version you asked for doesn't. A pin like ^99.0.0 has no match because there's no v99. Fix: loosen or correct the version in package.json — drop to a real one, or use something broad like "express": "^4" to take the latest 4.x — then restart. The Packages page shows the real Requested / Installed / Latest versions side by side, which makes an impossible pin obvious.
pip: could not find a version — both causes, one message
ERROR: Could not find a version that satisfies the requirement flsk (from versions: none)
ERROR: No matching distribution found for flskpip prints this for both problems, and the parenthetical tells them apart:
(from versions: none)— pip found nothing by that name: a typo (flskforflask) or a nonexistent package. Fix the name (check it on pypi.org).(from versions: 1.0, 1.1, 2.0)— the package exists but your pinned version isn't in the list. Pick one that is.
Correct requirements.txt and restart.
Other runtimes, same shape
npm and pip are the two you'll meet most, but the pattern is identical for every runtime's installer — composer (PHP), cargo (Rust), go get (Go), bun install, dart pub. The failure sits near the top of the install output and names the package or version that broke; the fix is the same: correct the name or version in that project's manifest (composer.json, Cargo.toml, go.mod, pubspec.yaml…), then restart. The Packages page speaks all of these registries too, so its search is the safest way to add a dependency without a typo.
💡 Tip: A one-off network blip during an install — a timeout or a dropped connection rather than an E404 — isn't a broken package. Just press Start again to retry it.
Fixing it, wherever the dependency lives
Two places hold your dependencies, and correcting either one works:
- The Packages page — search the right name/version, install, restart. Safest, because the search is backed by the real registry.
- The dependency file —
package.jsonorrequirements.txt, edited directly (this is what Git-deployed projects do). Fix the line, restart.
Whichever you use, the change only takes effect on the next start — so always restart after.
Peer conflicts and lockfiles
Sometimes an install fails not on a missing package but on a conflict — npm's ERESOLVE peer-dependency complaint, or an install that disagrees with a committed lockfile. Read the message: it names the two packages whose requirements collide, and the honest fix is to reconcile their versions so they agree (bump or pin one).
⚠️ Heads up: Deleting a lockfile (
package-lock.json) can clear a stale-lockfile error, but treat that as a last resort, not a first move — the lockfile is what makes installs repeatable.
Native modules that compile
Most packages with native code ship prebuilt binaries for the server's Linux, so they just install — better-sqlite3 is one that works out of the box. When a package genuinely has to compile and can't, the log fills with node-gyp, gcc, or cc errors instead of a clean download. There's no single fix, but two moves usually help: try a different version of the package (an older or newer release may ship a prebuilt binary for this environment), or change the runtime version in Settings (some native modules only prebuild for certain Node versions).