With Safeguard, the platform schedules scans and the local runner executes them on your own machine, then posts results back. Source code stays on that machine. You start the runner with the CLI, check it with a status command, and tune how often assets are rescanned in your scan policies.
This post sticks to what the CLI and continuous scanning documentation say. Where they leave a detail open, we say so instead of guessing.
What is the local runner?
The CLI documentation describes the runner as running on your own infrastructure and claiming scan jobs queued for your tenant. It posts results back to the platform, and source code stays on the machine. It uses the same binary and isolation as a standalone scan. It polls for queued jobs in the background, and the example output on that page shows a 30 second poll interval.
The CLI is the npm package @safeguard-sh/cli and also installs from cli.safeguard.sh. The commands for this feature are runner, which starts it, and runner status, which shows the current registration, including a runner ID and tenant. The built in help lists the rest.
Who decides when a scan happens?
The CLI page says the platform schedules scans and the local machine executes them, and that the queue lives on the platform side. It does not describe cron style schedules, so do not assume you can write one.
The continuous scanning page explains what triggers work on the platform side. Assets are re evaluated whenever something relevant changes, not only at build time. Triggers include vulnerability feed updates such as new CVEs, GHSAs, OSV entries, Known Exploited Vulnerabilities additions and EPSS changes, Safeguard zero day advisories, and asset changes such as a new commit, a new image tag or a vendor SBOM upload.
Documented frequencies by asset type:
- Source repositories: on every push, plus an hourly pull to catch missed webhooks.
- Container images: on push, plus every 4 hours for running images.
- Kubernetes workloads: on admission, plus a reconciliation every 15 minutes.
- AI models: on publish, plus weekly re validation.
- Vendor SBOMs: on upload, plus on SLA expiry if configured.
The page also says you can set a scan interval per asset label, for example 5 minutes for assets labeled sensitive and 24 hours for development environments, under Policies and then Scan Policies. It adds caveats about API examples that are not yet available, so check the page for current behavior before you depend on a specific setting.
One thing the page does not say is how the runner takes part in these scheduled scans. Treat the link between a platform schedule and your runner as the CLI page describes it, and confirm in the app.
Why use a local runner at all?
Two practical reasons.
Source stays on your machine. If policy says code must not leave your network, this model fits. Only results come back, and per Safeguard's description they are encrypted.
Your environment, your credentials. Private registries, internal package mirrors and build tools are easier to reach from inside your network.
Operating notes
A runner only picks up jobs while it is running. If it is stopped, jobs wait in the queue. That follows from the polling design, so decide where it runs. A small always on server is a better home than a laptop.
Give it only the access a scan needs. It reads the repository and writes results, and it does not need production credentials.
Check runner status after you start it, and again after a reboot, to confirm the registration is still in place.
If you use Zero AI mode, the scanner works without an LLM. The CLI also offers optional LLM source analysis if your policy allows it.
Walk through it at /demos/local-runner-cli.
What to do
- Install the CLI from cli.safeguard.sh and log in.
- Pick a stable host for the runner, not a personal laptop.
- Start the runner and run the status command to confirm tenant and ID.
- Read the continuous scanning page and set intervals for your sensitive assets.
- Queue a test scan and watch it complete.
- Add a simple check, such as an alert if the runner is not registered.
Quick check
Does the runner send my source code to Safeguard?
Per the CLI documentation, source code stays on the machine and only results are posted back.
Can I write my own cron schedule for the runner?
The documentation we read does not describe cron style schedules. The platform queues jobs, and you tune intervals through scan policies.
Sources
- Safeguard CLI documentation, fetched 18 October 2026
- Safeguard documentation: Continuous scanning, fetched 18 October 2026
Last reviewed: 18 October 2026.
