GuidesOnly show guides for your app
GuidesGuidesA fifteen-minute monthly habit — read the Packages page's Requested / Installed / Latest columns, clear the vulnerability flags, apply safe updates, and commit your lockfile so every start is reproducible.
The libraries your project depends on don't stand still. New versions ship, old ones grow security holes, and the gap between "installed a year ago" and "current" quietly widens until an update becomes a scary rewrite instead of a small step. The cure is a habit, not a heroic effort: fifteen minutes once a month keeps dependencies healthy and updates boring. Falix gives you the tool to do it — the Packages page.
| At a glance | |
|---|---|
| You need | A server running an app that speaks a package manager (Node.js, Python, Bun, Go, Rust, Dart, Deno, or any PHP app) |
| Plan | Any — the Packages page is on all plans |
| Time | ~15 minutes a month |
Open Packages from your server menu. Every dependency shows three version numbers, and the story lives in the gaps between them:
| Column | What it means |
|---|---|
| Requested | What your dependency file asks for — e.g. ^4.18.0 in package.json |
| Installed | What's actually on the server right now |
| Latest | The newest version on the real registry (npm, PyPI, crates.io, …) |
Work the page in this order — riskiest-to-ignore first, riskiest-to-apply last:
⚠️ Heads up: An install or update changes files but never restarts your app on its own. Until you restart, your running process is still on the old version. The server doesn't need to be online to install, though — you can update a stopped server and start it fresh.
Because dependencies auto-install on every start, "it worked yesterday" only holds if today's install resolves to the same versions. That's the lockfile's job. Your package manager writes one — package-lock.json (npm), bun.lock (Bun), Cargo.lock (Rust), go.sum (Go), poetry.lock / uv.lock (Python), composer.lock (PHP Composer) — recording the exact resolved version of every package, direct and indirect.
The rule: commit your lockfile to Git. A Git-based deploy that carries the lockfile reproduces the same dependency tree every time; one without it re-resolves your ranges on each machine and can drift. The lockfile is the difference between "installs the versions I tested" and "installs whatever's newest today."
💡 Tip: Adding packages by hand still works and is what Git projects do — you edit
package.json/requirements.txt/Cargo.tomland the file installs on the next start. But the Packages page runs the real package manager for you, updates the file, and is the only view that flags outdated and insecure dependencies. Use it for the audit even if you edit by hand.
The Packages page and hand-editing your dependency file end in the same place: the real package manager runs (npm install, pip, cargo add, go get, composer require, …) and your dependency file is updated. Reach for the page when you want the version and vulnerability information; edit the file directly when the project is Git-driven and the file is the source of truth. Don't manage dependencies through the "Additional packages" egg variables or startup-command edits — the Packages page and your dependency file are the supported paths.
The Packages page is governed by the Files permissions: a subuser needs read to view it and update to install or change anything. There is no separate "Packages" permission. See sub-users.
npm error notarget / "No matching version" — you asked for a version that doesn't exist. See Install failures.