Run npx wrangler deploy with the dry-run flag and an output directory. Cloudflare documents this as the way to review the exact code Wrangler will upload, after bundling. Open the output, check which dependency versions are inside, and note any modules left outside the main bundle.
The command
Cloudflare's bundling page gives this form:
npx wrangler deploy --dry-run --outdir dist
Nothing is uploaded. Wrangler builds your Worker with esbuild and writes the result to the dist folder, which is the artifact that would be deployed. On the limits page, Cloudflare shows the same idea with a bundled output folder and a printed Total Upload size, which is the uncompressed bundle size.
What to check in the output
- Size. Compare Total Upload with your last release. A sudden jump usually means a new or upgraded dependency.
- Versions. Search the output for the package names you care about. Bundlers often keep license comments and version strings you can grep.
- Surprises. Look for packages you did not expect, such as a large utility library pulled in by one import.
- Development code. Wrangler statically replaces the NODE_ENV value at build time, using production for deploy, so development-only branches can be removed from the production bundle. Confirm they are gone.
- Secrets. Search the bundle for anything that looks like a key or token. A value written into source ends up in the artifact. This is a manual review, not a guarantee.
The unbundled exception
Cloudflare documents that you can set find_additional_modules to true and define rules so some files are uploaded as separate external modules, for example large files that are lazy loaded or dynamic imports with variable paths. Those files are not inlined into the entry file.
For review, this means the entry bundle is not always the whole Worker. Check your Wrangler configuration for rules and find_additional_modules, and include those modules in whatever you scan. Likewise, non-JavaScript files such as Wasm can be uploaded as separate modules.
Make it a pipeline step
A manual check helps once. A repeatable one helps every release.
| Step | Where it runs |
|---|---|
| Install from the lockfile | CI |
| Dry-run build to an output folder | CI |
| Scan the dependency list and the output | CI |
| Compare bundle size with the previous release | CI, fail on a large unexplained jump |
| Deploy | Only after the above pass |
Pin the Wrangler version too. Cloudflare says it periodically updates the esbuild version included with Wrangler, which may sometimes bring breaking changes to bundling.
Why this matters for supply chain review
A scanner reading only package.json sees what you asked for. The bundle shows what was shipped. When the two disagree, for instance because a transitive package was pulled in at a different version, the bundle is the truth for what runs. Our post on whether a scanner can see inside a bundled Worker goes deeper on the tooling side.
Where Safeguard fits
Safeguard's dependency scanning and SBOM generation work from the repo and lockfile, and reachability analysis shows which findings your code can call. Pair that with the dry-run output review above so what you scanned matches what you shipped. Free scan: gold.safeguard.sh/scan.
Quick check
Does a dry run upload anything?
No. It builds the bundle locally so you can inspect it. Cloudflare documents it as the way to review the code Wrangler will upload.
Is the entry file always the whole Worker?
Not if you configure additional modules. With find_additional_modules and matching rules, files can be uploaded unbundled, so review those too.
Sources
Last reviewed: 19 October 2026.
