Wrangler 4.150 now uploads source maps by default

For sites and APIs running on Cloudflare Workers, the line numbers of errors in the logs point to the built code, so you cannot tell where they are in the original source. From Wrangler 4.150.0, this inconvenience is solved without any configuration. In exchange, a file containing the original source code is now sent to Cloudflare with every deployment.

Wrangler is the official CLI for building and deploying Cloudflare Workers. The changelog for 4.150.0, published on npm on October 13, 2026, lists the following change under "Minor Changes."

Upload source maps by default for wrangler deploy, wrangler versions upload and wrangler preview

Based on the original changelog and the results of comparing the upload contents of 4.149.0 and 4.150.0 in the editorial team's test environment, this article sorts out what people running sites or business systems on Workers should check before upgrading.

What changed

A source map is a file that maps positions in built JavaScript to the original source (such as TypeScript). If you send it to Cloudflare, error locations shown in logs and wrangler tail are displayed as lines in the original source.

Until now, they were sent only when upload_source_maps in the configuration file was set to true. According to the changelog, the behavior from 4.150.0 is as follows.

The affected commands are wrangler deploy, wrangler versions upload and wrangler preview. The experimental wrangler build --experimental-cf-build-output did not change in 4.150.0 and included source maps only when upload_source_maps = true. However, in 4.151.0, released the next day (October 14, 2026), it also changed to include them by default (you can stop this with upload_source_maps = false). As of October 19, the latest version on npm is 4.151.1.

We compared what gets uploaded in 4.149.0 and 4.150.0

The editorial team prepared a small test Worker (a few-line function written in TypeScript, without specifying upload_source_maps), pointed Wrangler's API endpoint at a local stub (a test server that returns fixed responses in place of the Cloudflare API and records what it receives) and ran wrangler versions upload. We did not connect to an actual Cloudflare account.

Opening the index.js.map uploaded by 4.150.0, we found that sourcesContent contained the full text of the original src/index.ts as-is, including type annotations. This means a source map can contain not just position mappings but the original code itself.

You can also confirm the difference in Wrangler's code (wrangler-dist/cli.js, as published on npm). In 4.149.0 the condition is "load only when uploadSourceMaps is true"; in 4.150.0 it changed to "load unless false, and treat it strictly only when true."

Deciding whether it is acceptable to send them

From here on is the editorial team's own analysis. Sending source maps lets you trace production errors back to lines in the original code, which speeds up incident investigation. On the other hand, it means your original code is stored on Cloudflare's side. According to Cloudflare's documentation (Source maps and stack traces, updated October 12, 2026), uploaded source maps are used to map stack traces (the chain of function calls leading up to an error) back to lines in the original code when an uncaught exception occurs in a Worker, and the results can be viewed in real-time logs, Tail Workers, and Workers Issues. Source maps cannot be read from code while the Worker is running, and the size limit is 15 MB after gzip compression. The documentation does not state the retention period or who in the account can view the contents. In addition, as of October 19 the documentation still uses the earlier wording, "uploads when upload_source_maps is set to true," and a fix reflecting the change in the default is in preparation.

If any of the following applies to you, decide whether to send them before upgrading the version.

• For client projects, the contract or the client's rules specify where source code may be stored or whether it may be provided to third parties
• Your code may still contain information that should not be there (internal URLs, test credentials, customer names left in comments, and so on)
• Your company's security rules define what information may be sent to external services

If the second item applies, the proper fix is to remove that information from the code before turning off source maps, because the built index.js is also sent to Cloudflare. If you output .map with your own build such as Vite, make sure, as the documentation says, not to place server-side source maps in the static assets (public files) directory. If you put them there, they may become downloadable by anyone, separately from what is sent to Cloudflare. A case where source maps were included in a published npm package and the original code became readable is covered in Lessons from the Claude Code source leak. This change is not about public exposure, but the shared point is knowing what goes into a source map.

What to check before upgrading the version

1. Check the package.json specification. If you update the lockfile with a range specification such as "wrangler": "^4.x", 4.150.0 or later may be installed unintentionally. If you pin the version, check this when you upgrade
2. Write your policy in the configuration file. If you send them, set "upload_source_maps": true (strict handling where the upload fails if any source map cannot be resolved); if you do not, explicitly set false in wrangler.jsonc (or wrangler.toml). Rather than relying on the default behavior, you keep the policy in a form that can be reviewed
3. Check that CI deployments use the same setting. If you pass flags such as --upload-source-maps in CI, review how they relate to the configuration file
4. Treat this separately from migrating to Cloudflare's new CLI. In 4.150.0, wrangler deploy and similar commands also stop in projects that still contain output (.cloudflare/output) built with Cloudflare's new CLI (cf). Migration to cf is covered in Cloudflare's new CLI "cf" beta

For how to divide permissions when you let a web agency or external developers operate Workers, see Cloudflare Workers: grant web agencies permissions per Worker.

Scope of verification

On October 17, 2026, we checked Wrangler's changelog (4.150.0 in packages/wrangler/CHANGELOG.md of the cloudflare/workers-sdk repository) and the publication date and time of wrangler on npm (document research). On October 19, we reopened the changelog (including 4.151.0 and 4.151.1), npm, and Cloudflare's source maps documentation, and added the change to wrangler build --experimental-cf-build-output in 4.151.0 and what the documentation says. In addition, in the editorial team's test environment (Linux, Node.js v22.22.0, wrangler 4.149.0 and 4.150.0), we uploaded a test Worker to a local stub with wrangler versions upload and checked the files sent and the contents of the source maps (hands-on testing). We have not verified sending with wrangler deploy and wrangler preview, uploading to an actual Cloudflare account, storage and display of source maps on Cloudflare, or behavior in build environments such as Workers Builds.

To review the operation and deployment of sites and APIs running on Cloudflare Workers, contact us through development, AI, and automation consulting.

References

• wrangler CHANGELOG（cloudflare/workers-sdk, packages/wrangler/CHANGELOG.md）
• npm registry — wrangler
• Source maps and stack traces（Cloudflare Workers docs）