Run the scanner inside your own network

The same engine, on your side of the fence. It is not a smaller version: the rules, the syntax reading, the ownership model and the score are the code the hosted scan runs, and a test on every release checks the two agree. What the offline scanner adds is reach and privacy. It can measure hosts behind Cloudflare, which a Worker cannot dial, it can open build artifacts and container images where they sit, and it can read code you are not willing to send anywhere. Only findings leave, and only if you ask them to.

Your code stays put

Point it at a directory. It reads the files locally, builds the cryptographic bill of materials locally, and writes a report locally. Nothing is transmitted unless you pass --upload, and even then it sends findings, never source.

Sees what the cloud cannot

Running from your laptop or your VPC means no Cloudflare blind spot and no browser-fingerprint rejections. Verified: the hosted scanner cannot probe example.com at all, while the runner measured it as X25519MLKEM768.

Shared engine, different scan scope

The assessment logic is shared code, so a runner report and a hosted report are produced by shared rules. Each report states its actual scope; the hosted scan has a smaller source budget and cannot reach inside your network or a container image.

Containers and built artifacts

A source scan reads what your team wrote. This reads what your team ships, which is a different list. The OpenSSL that breaks a compliance answer is usually in the base image, declared in no repository anywhere.

What it opens

Container images, by registry tag such as nginx:1.27, or from a tar you exported with docker save. No Docker daemon needed.
Java: JAR and WAR, including archives nested inside other archives.
Python: wheel and sdist. .NET: NuGet package.
Any zip or tar.gz produced by a build.

What that reveals

Every image layer is read in order, honouring whiteouts, so files deleted in a later layer are not reported.
Bundled libssl and libcrypto, and the exact OpenSSL build and version.
Java trust stores and keystores inside the artifact, with their entries and algorithms.
Root certificate bundles, often hundreds of them, which source declares nowhere.
Operating system packages carrying their own crypto, and the base image they came from.

qr-run artifact ./build/app.jar
qr-run image nginx:1.27
qr-run image ghcr.io/owner/api:v2 --platform linux/arm64
qr-run image ./payments-api.tar --upload https://getquantumready.app

Cloud and infrastructure

Certificates and keys do not live in your repository, they live in your cloud account. This reads the TLS and key configuration of your accounts through the CLI you are already signed in to, so there is no application to register and no credential to hand over.

What it reads

AWS: ACM certificates with key and signature algorithm, KMS key specs, and load balancer listeners with their SSL policy.
Azure: Key Vault certificates and Application Gateway SSL policy.
Google Cloud: Compute SSL certificates and SSL policies.

How it is kept safe

Every call is read only, and the exact commands are listed in the report so it can be audited rather than trusted.
No key material, secret value or application data is read. Certificate metadata only.
It runs on your machine using your CLI session. We never receive your credentials.
If the CLI is absent or not signed in, it says so rather than reporting an empty result.

qr-run cloud aws
qr-run cloud azure
qr-run cloud gcp

Web scan or offline scan: which one to use

They share an engine and report format, with different capabilities and budgets. The hosted scanner reads up to 250 files or 2 MiB of source, whichever comes first, inside the free Workers budget. Use the local runner for the larger source budget and access to internal services or artifacts.

	Hosted scan	Offline scan
Runs where	Our cloud	Your machine
Reaches	Hosted scans of public or linked repositories, up to the stated budget, and public endpoints	Private code, built artifacts, container images, and hosts inside your own network
Your source	Archive processed in memory; reports and temporary checkpoints can retain matched excerpts	Never leaves your machine, and only findings travel if you ask
Blind spot	Cannot dial a Cloudflare-fronted host, and cannot see inside a container image	Needs a machine you control and an activation key
Best for	Judging the engine quickly, and anything already public	Anything you would not send anywhere, and everything that has been built or deployed

Use the hosted scan for a first look and the local scanner for broader source and artifact coverage. Both have stated limits. The account rollup can group their reports by application.

Install it once, then run it from anywhere

Node 18 or later. No dependencies, no daemon, nothing to configure.

Install and activate, in one paste

Paste this whole block into a terminal. Swap in the activation key from your account page on the line that asks for it. The final line confirms it worked.

curl -fL -H "x-qr-activation: YOUR-ACTIVATION-KEY" -o quantumready-runner-0.10.7.zip "https://getquantumready.app/download/quantumready-runner-0.10.7.zip"
unzip -o quantumready-runner-0.10.7.zip
cd quantumready-runner
sh runner/install.sh
qr-run activate YOUR-ACTIVATION-KEY
qr-run status

The download uses your activation key in a request header, because the bundle is not public. Without valid activation, curl follows a redirect to the sign in page and saves that instead, which then fails to unzip with an end-of-central-directory error. If that happens, check the file: file quantumready-runner-0.10.7.zip should say "Zip archive", and the size should be around 2 MB. You can also download it from your account page in a browser, where the session is already signed in.

The installer creates a qr-run command. If it reports that the folder is not on your PATH, add the single line it prints to your shell profile and open a new terminal. If you already have this project checked out, skip the download and run node runner/qr-run.mjs in place of qr-run.

Then just type the command

qr-run

With no arguments it opens a short menu, which is the easiest way to hand it to a prospect: pick what to scan, paste the target, and decide at the end whether the findings go anywhere. Nothing is uploaded unless you say yes.

Endpoint scanning works without a key. Repository, artifact and image scanning need one. The key links the downloaded copy to your account, and it does not give anyone access to your source code, which never leaves your machine. Without activation the runner refuses those scans and says where to get a key rather than failing silently.

Or skip the menu and pass arguments:

qr-run endpoint csa.gov.sg example.com.sg
qr-run local ./my-service
qr-run artifact ./build/app.jar
qr-run image nginx:1.27
qr-run repo https://github.com/owner/repo --out report.json
qr-run net 10.0.0.0/24
qr-run local ./my-service --upload https://getquantumready.app

Network scan

Sweeps your own network for services that speak TLS and reports what each one negotiates, which the hosted scanner cannot do because it can only reach the public internet. Give it a host, a range such as 10.0.0.0/24, or a comma separated list, and it probes the TLS ports by default. Narrow or widen with --ports 443,8443,636. It refuses anything larger than a /22, because this is meant for a network you own, and it is worth saying plainly: only run it against addresses you are authorised to scan.

qr-run net 10.0.0.0/24
qr-run net api.internal,db.internal --ports 443,8443 --out network.json

The output is one report for the whole range: each service with its key exchange group, TLS version and certificate, plus a count of how many are post-quantum ready and how many are still classical only. Add --upload to file it against your account.

Cloud infrastructure

Reads the TLS and key configuration of your cloud accounts through the provider CLI you are already signed in to, so there is no OAuth application to register and no long-lived key to store. Every call is read only, the exact commands are listed in the report, and no key material, secret value or application data is read. If the CLI is not installed or not signed in, it says so rather than reporting an empty result.

qr-run cloud aws
qr-run cloud azure
qr-run cloud gcp

On AWS it reads ACM certificates, KMS key specs and load balancer listeners. On Azure, Key Vault certificates and Application Gateway SSL policy. On Google Cloud, Compute SSL certificates and SSL policies. Add --upload to file the result against your account, where it joins the same application rollup as everything else.

Or use it from a browser, on your own machine

If you would rather not work in a terminal, the scanner can serve a small interface on this machine. It shows every scan type in one place, lists the scanners already installed here, and gives you a button that runs a scan and sends the findings to your account. It answers on the loopback address only, so nothing on the internet can reach it, and nothing leaves the machine unless you press the button that says so.

qr-run serve
# then open http://127.0.0.1:8787

If you see "Cannot find module .../runner/qr-run.mjs"

That happens when you run the relative path from a folder other than the project root, which is exactly why the installer exists. Run sh runner/install.sh from the project folder once, then use qr-run from anywhere.

What it checks

Command	What it does
`endpoint`	Partial protocol probes plus completed TLS 1.3 and TLS 1.2 sessions. Reports the raw group observation separately from the established-session group, inventories certificates and checks chain trust, hostname and dates. Supports SMTP STARTTLS, supplied CA/CRL files and optional bounded individual TLS 1.2 cipher probes. Revocation and client-runtime limits remain explicit.
`local`	Walks a directory, applies the same filters and more than 40 detection rules, and produces a cryptographic bill of materials with file and line evidence, prioritised actions and a readiness score.
`repo`	The same repository scan as the hosted site, run from your machine. Useful for very large repositories that exceed the hosted budget.
`artifact`	Opens a built file: JAR, WAR, EAR, WHL, NUPKG, ZIP, TAR or TAR.GZ. Lists every entry, finds bundled crypto libraries, certificates, keystores and native OpenSSL builds, reads manifests and configuration, and recurses into nested archives such as JARs inside a WAR. This is layer 2, what actually made it into the build.
`image`	Opens a container image saved with `docker save`. Reads the manifest and image config, walks every layer, and reports the OpenSSL builds, trust stores and packages that arrived through the base image. This is layer 3, and it usually finds things the source scan cannot see.

Options

Flag	Effect
`--quick`	Endpoint scan without the legacy protocol and weak cipher probes. Faster, less complete.
`--deep`	Read the code as well as matching it. Resolves the algorithm, mode and padding from the call itself, reads names assembled from constants, and names a cipher it cannot resolve as a record rather than guessing. Eleven language families: Java and Kotlin, JavaScript, TypeScript, Python, Go, Ruby, PHP, Rust, C#, C and C++, and PowerShell. On Team and Enterprise plans, and the grammars travel in the download, so it needs no network.
`--json`	Machine readable output on stdout.
`--out <file>`	Write the result to a file.
`--upload <url>`	Upload findings to your account using an activation key and print a private report link. Create share links from the report page.
`--ref <name>`	Branch or tag for the repository scan.

Same limits, stated the same way

The runner reads source and configuration files. It does not read compiled binaries, container images, hardware security modules, live databases or runtime key stores. Eleven language families are parsed as well as matched, and the rest are matched by pattern, so a name chosen at runtime and an encrypted configuration can still be missed. Every report states how many files and bytes were scanned, what was skipped and why, and whether any limit was reached.