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 |
Read the three versions
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, …) |
- Installed behind Latest → an update is available. The row shows an update badge telling you how big the jump is: patch, minor, or major (that maps straight to risk — see Semantic versioning).
- Installed differs from Requested → your range allowed a newer build than the number you wrote. That's normal, and it's exactly why a lockfile matters (below).
- A security flag → the panel warns when an installed package has a known vulnerability. These jump the queue.
The monthly habit
Work the page in this order — riskiest-to-ignore first, riskiest-to-apply last:
- Back up or branch first. Take a backup, or if the project lives in Git, do this on a branch. An update that misbehaves should cost you a restore, not a weekend.
- Clear vulnerability flags. A flagged package is the one update you shouldn't defer. Update it now.
- Apply patch and minor updates. Patches are bug fixes; minors add features without breaking existing code. These are almost always safe — press Update on the row and let the Tasks panel run it.
- Handle major updates deliberately. A major bump is allowed to break things. Read the project's changelog, update one at a time, and test after each.
- Restart, then verify. Installs don't restart your app for you — restart the server so it loads the new versions, then confirm your bot or site still works.
⚠️ 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.
Lockfiles: why two installs stay identical
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.
Editing vs. the panel — same destination
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.
Who can do this
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.
Troubleshooting
- An update broke the app — roll back: set the version back on the row (or restore the backup you took in step 1), then restart. This is why step 1 exists.
npm error notarget/ "No matching version" — you asked for a version that doesn't exist. See Install failures.- The Tasks job failed — open the task's logs on the Packages page; the package manager's real error is there.
- Installed still shows the old version — you haven't restarted since the install. Restart and check again.