Settings reference
Published apps: sleeping apps and known vulnerabilities
When idle and cold-start apps sleep, and the lookups for known vulnerabilities (CVEs) in the packages and images of every live app.
Idle and cold-start apps
In the portal: Admin, Settings, Published apps
An app without a single request for Let idle apps sleep after (minutes) is stopped, and the next request wakes it. An app its owner marked cold start sleeps after Cold-start apps sleep after (minutes) even when other apps never sleep, and its memory does not count as promised, so a server can carry more of them than its RAM.
A call that arrives while it sleeps (an API call, a webhook, a scheduled task) waits Hold a request to a cold-start app for (seconds) for the app to start before it gets a 503. A browser opening a page sees a "waking up" page instead.
Known vulnerabilities in the packages an app uses
In the portal: Admin, Settings, Published apps
Look up known vulnerabilities (CVEs) checks the packages each live app pins in its lockfiles against OSV.dev, an open vulnerability database. It runs on each deploy and again every day, because new advisories appear after the code was written. Only package names and versions are sent, never code.
It warns and never stops a deploy. Owners see what affects their app, and which version fixes it, on the app's Security tab. Admins see every app under Admin, Tech stack.
Under Advanced, Look up vulnerabilities again every (hours) sets the daily round (0 means only on deploy and on demand; it applies after the next restart), and Vulnerability database (OSV API) takes the address of a mirror for a server that may not reach the internet.
Vulnerable system packages in app images
In the portal: Admin, Settings, Published apps
Scan app images for vulnerable system packages adds what no lockfile lists: the operating system packages in each live image, such as the base image's openssl. It runs with the lookups above, on deploy and daily, using Trivy as a container next to Docker on each server. The usual cure for what it finds is to rebuild the app with fresh base images. Nothing of the image leaves the machine.
Trivy downloads its own vulnerability database, about 60 MB, from ghcr.io. A server that cannot reach it can use a copy: under Advanced, fill in Trivy database mirror. Trivy image chooses which Trivy version runs.