Operations

Vulnerability Checks

Known vulnerabilities in apps' packages, committed secrets, end-of-life runtimes and account alerts.

Every deploy, VPSPilot checks what the app is made of: the packages its lockfiles pin, the OS packages inside its container, files in its repository that look like secrets, and whether its runtime still gets security fixes. Results are on each app's page under Security and, for every app at once, on the Security page. Needs agent 1.1.7 or later.

What is checked

Check	Read from	Looked up in
Dependencies	`package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`, `bun.lock`, `uv.lock`, `poetry.lock`, `Pipfile.lock`, pinned `requirements.txt`, `go.mod`, `Cargo.lock`, `composer.lock`, `Gemfile.lock`: at the repository root, the build context and folders one level down	OSV.dev
OS packages	The running container (Debian, Ubuntu, Alpine). Only issues the distro has already fixed count.	OSV.dev
Committed secrets	Files git tracks: private keys, cloud and API tokens, .env files with real values	Nothing: it stays on the server
End of life	The Node.js or Python version of the build and the container's distro	endoflife.date

Lockfiles are re-checked against OSV.dev every day, so an advisory published after the deploy still shows up. To scan again now (after changing a lockfile on the server, for example), use Scan now on the app's page.

What leaves your servers

Only package names and versions go to OSV.dev, the open database behind GitHub's and the Linux distros' advisories. To keep even those private, turn off Vulnerability Checks in Settings → Security; the secret scan keeps working. The secret scan reports the file, the line and the kind of secret, never the value.

Reading the results

Advisories for the same package and version are one row, with the release that fixes all of them. Open a row for each advisory, its severity and a link to its page. Upgrade the package, commit the lockfile and deploy. Something that doesn't apply to you (a vulnerable function your app never calls) can be ignored: it stops counting for alerts and stays ignored on later checks.

Vulnerable OS packages come from the base image. They are fixed by rebuilding: redeploy, or tick Rebuild weekly under Security on the app's page to redeploy the live version every week and pick up fixes as the distro publishes them.

Committed secrets

A secret in the repository is in its history and in every clone, even after the file is deleted. Move it to the app's environment variables, then rotate it with whoever issued it. Deploys also point them out in the build log.

Alerts

Rule	Fires when
Vulnerable dependencies	An app has at least this many critical or high vulnerabilities with a fixed release (default 1)
Secrets in the repository	The repository has files that look like secrets
Runtime end of life	The app's Node.js, Python or distro stops getting security fixes within this many days (default 30), or already has
Agent out of date	A server's agent has been older than the control plane's for three days

They work like every other rule: see Monitoring and Alerts. The weekly report has a Security section with the same.

Account and team changes

These go to the audit log, every admin's inbox, alert channels with Security ticked and, by email, the account they're about:

a sign-in from an address the account hasn't used in 180 days;
a recovery code used to sign in;
a password changed or reset;
an account locked after repeated wrong passwords;
an authenticator app set up;
a role changed or an admin added, from the dashboard or the server's command line.