Getting started

PkgFire checks dependencies before they are installed. You install one small command-line tool, connect it to your account, and put pkgfire in front of the install commands you already type. This page takes you from nothing to a first verdict.

Install the CLI

On macOS or Linux, on Intel or ARM:

curl -fsSL https://pkgfire.org/install.sh | sh

The script works out your platform, downloads the matching binary, checks it against the published SHA-256 checksums and refuses to install if they do not match. It puts the binary in a directory already on your PATH that does not need sudo, and writes a config file that points at pkgfire.org.

Piping a script into a shell deserves a second look, especially for a tool whose job is to stop unchecked code running. You can read it first with curl -fsSL https://pkgfire.org/install.sh | less, or download a binary yourself from the downloads page and compare it with SHA256SUMS there. Windows binaries are published on the same page; the script does not install them.

Connect your account

The CLI talks to your account with an API key.

1. Sign in at pkgfire.org with your email address. There is no password: a link arrives that works once and expires in 15 minutes.
2. Open API keys in the dashboard and create one. It is shown once, so copy it now.
3. Store it:

pkgfire auth set-key

The key is read without echoing, so it does not end up in your shell history, and it is checked against the service before anything is saved. It is kept in ~/.config/pkgfire/config.toml, readable only by you. pkgfire auth status shows what is configured and pkgfire auth clear removes it.

In CI, set PKGFIRE_API_KEY (and PKGFIRE_API_URL, https://pkgfire.org) instead of a config file. The variables take precedence over the file. See CI.

Your first scan

From the root of a project with a lockfile:

pkgfire scan

pkgfire scan reads the lockfile that is already there and checks every package in it. It installs nothing and runs no package code. It prints the verdict, ALLOW, WARN or BLOCK, with the reasons behind it, and exits with a code that says the same thing (see exit codes).

The project is named after the repository's remote, owner/repo, so every clone of one repository lands in the same project whatever its directory is called. --project <name> or PKGFIRE_PROJECT names it yourself.

Every scan is kept in the dashboard, with its findings, its verdict and why, and what changed since the previous scan of the same project.

A first scan of a large project can take a few minutes: every package the service has not seen before is downloaded and analysed. Scans after that are quick, because results are cached by the exact file that was analysed.

Check your next install

Put pkgfire in front of the command:

pkgfire npm install
pkgfire pnpm add lodash
pkgfire bun install
pkgfire uv sync
pkgfire go get example.com/lib@v1.4.0

PkgFire works out what the command would change, with install scripts off and nothing built, checks the result, and only then runs your own package manager. A BLOCK means nothing was installed and nothing ran. How that works, and which commands are wrapped: The install wrapper.

One package

To look at a single package version before you depend on it:

pkgfire scan npm lodash@4.17.21

Keeping the CLI current

pkgfire update

downloads the published release for your platform, checks it against the published checksums, and only then replaces the installed binary. pkgfire update --check only says whether a newer version exists.