Deploy to Cloudflare: ZodError on previews_base_config.deploy_command aborts every submit, including Cloudflare's own templates

[thankywal]

What version of wrangler are you using?

Not applicable — this is the dashboard's Deploy to Cloudflare flow, no local wrangler involved.

What operating system and version are you using?

macOS, Chrome 148–150.

Please provide a link to a minimal reproduction

https://deploy.workers.cloudflare.com/?url=https://github.com/cloudflare/templates/tree/main/hello-world-do-template

Describe the Bug

Pressing Deploy on the Deploy to Cloudflare setup form throws an uncaught ZodError and the submission aborts. It reproduces with Cloudflare's own templates, so it is not specific to any one repository.

Uncaught (in promise) ZodError: [
  {
    "expected": "string",
    "code": "invalid_type",
    "path": [
      "previews_base_config",
      "deploy_command"
    ],
    "message": "Invalid input: expected string, received undefined"
  }
]
    at at (cf-useBuilds.Q3C8LSNY.js:3:1874)
    at Hl (cf-ConfigureTemplate.CN_WXn13.js:38:62815)
    at Zl (cf-ConfigureTemplate.CN_WXn13.js:38:68824)
    at async onSubmit (cf-ConfigureTemplate.CN_WXn13.js:38:74781)
    at async cf-authenticated-app.T9NSyoF.js:22:22118

Steps to reproduce

1. Open the link above while signed in to an affected account.
2. Fill in the form (the defaults are fine).
3. Press Deploy.
4. The form shows "Setting up your repository. This may take a few seconds…", then returns to its previous state. The ZodError above is in the console.

What the user is left with. This is the part worth prioritising: the flow fails silently. By the time it throws, the dashboard has already created a Worker from the placeholder template and a repository in the user's GitHub account. What remains is:

• A repository containing exactly two files, README.md and the parsed wrangler config, committed by cloudflare-workers-and-pages[bot] with the message Uploading template. (a working import commits as cloudflare[bot] with source repo import and contains the full tree).
• No queued build — Workers Builds is never configured, so nothing ever builds.
• The placeholder Worker still deployed and answering Hello world.
• A dashboard that reports success.

Nothing surfaces an error to the user, so people reasonably believe the install worked and go looking for the fault in their own project.

Scope: what we varied

We chased this for a day assuming it was our repository. It is not. Each row is a real attempt:

Repository	Cloudflare account	GitHub account	Result
Our app, current	A	1	ZodError
Our app, byte-exact tree that imported successfully on 11 Aug	B (created that day)	2 (created that day)	ZodError
Our app, with the deploy script removed so the form falls back to its documented defaults	A	1	ZodError
cloudflare/templates → hello-world-do-template	A	1	ZodError
cloudflare/templates → hello-world-do-template	C	3	ZodError

Four repositories, three Cloudflare accounts, three GitHub identities, two browsers. The error follows none of them.

The second row is the useful control: that tree is byte-for-byte the one Cloudflare imported successfully on 2026-08-11 05:37 UTC (95 files, cloudflare[bot], source repo import). Published unchanged as a separate repository and deployed again the next day on a brand new account, it fails. Same bytes, different day, different outcome.

Analysis

From cf-ConfigureTemplate.CN_WXn13.js, the build settings sent to the API are assembled as:

let m = a ? !!i.enable_preview_builds : !!i.non_production_branch_builds,
    h = a ?   i.preview_command        :   i.non_production_branch_deploy_command;

return {
  script_tag: e,
  git_repository: { ...n, branch: t },
  production_settings: { ...d, deploy_command: o },
  previews_enabled: c,
  previews_base_config: { ...d, deploy_command: s }   // s ← h, undefined here
}

and the form's default values are:

[jo]: n && r && `build`  in n ? `${r} run build`  : ``,
[Fo]: n && r && `deploy` in n ? `${r} run deploy` : `npx wrangler deploy`,
[ji]: `npx wrangler versions upload`,   // non_production_branch_deploy_command
[Uo]: `npx wrangler preview`,           // preview_command

So build_command and the production deploy_command are derived from the repository's package.json and are always populated — both are visibly filled in on the form in every failing case. previews_base_config.deploy_command comes only from a form field: preview_command when the account has Worker Previews enabled, otherwise non_production_branch_deploy_command. Neither field is rendered on the deploy-to-workers template form, and the value reaches the schema as undefined.

Two things point at the Worker Previews rollout rather than at anything a user controls:

• Affected accounts take the createPath: 'worker_previews' branch during build-token creation, which selects i.preview_command — the field with no input on this form.
• Both defaults are hardcoded in the bundle. Nothing in a repository can supply this value, which is consistent with the documented behaviour that Workers Builds does not honour build configuration from the Wrangler file.

Suggested fix

Defaulting h to `npx wrangler versions upload` when the form does not collect it would restore the flow, since that is already the documented default for the non-production branch deploy command.

Separately, and regardless of this specific bug: it would help a lot if a failed submit did not leave behind a two-file repository, an unconfigured build and a placeholder Worker under a success message. The silent half-completed state cost far more time than the error itself.

Please provide any relevant error logs

Related, and possibly the same root cause seen from the other end: #31 reports the two-file repository and the Worker stuck on the Hello World placeholder, which is exactly the state this ZodError leaves behind.

The three repositories used in the table above are public and unchanged, if they are useful for reproducing:

• thankywal/muxel-probe-a — the byte-exact tree that imported successfully on 11 Aug
• thankywal/muxel-probe-c — same tree with the deploy script removed
• thankywal/muxel — the application itself

Happy to supply HAR files, the failing request payloads, or account IDs privately if that would help.

[workers-devprod]

• Reproduction: ⚠️ Blocked. Issue is in the live Cloudflare dashboard at deploy.workers.cloudflare.com, not in this repository's code; requires authenticated Cloudflare/GitHub accounts and browser access to an external service.

[thankywal]

Understood on the reproduction — a signed-in dashboard is not something automated triage can drive, and I should not have made a browser the only way in.

Here is a reproduction that needs no account, no browser and no Cloudflare login. The dashboard bundle that throws is served publicly and unauthenticated, so the defect can be read directly out of the shipped artefact:

curl -s https://dash.cloudflare.com/assets/cf-ConfigureTemplate.CN_WXn13.js \
  | grep -o 'h=a?i.preview_command:i.non_production_branch_deploy_command'

curl -s https://dash.cloudflare.com/assets/cf-ConfigureTemplate.CN_WXn13.js \
  | grep -o 'previews_base_config:{[^}]*}'

Both return HTTP 200 with no credentials. That is the same file, and the same two frames, named in the stack trace: cf-ConfigureTemplate.CN_WXn13.js:38:62815 and :38:74781.

The defect, in the shipped bundle

previews_base_config.deploy_command is populated from exactly one source:

let m = a ? !!i.enable_preview_builds : !!i.non_production_branch_builds,
    h = a ?   i.preview_command        :   i.non_production_branch_deploy_command;

which then flows into the payload that is schema-validated:

previews_base_config: { ...d, deploy_command: s }   // s ← h

On the deploy-to-workers template form, neither preview_command nor non_production_branch_deploy_command is rendered as a field, so h is undefined and the Zod parse throws before any request is sent.

The adjacent default-values map in the same file shows the asymmetry plainly. build_command and the production deploy_command both have fallbacks; the two preview fields have hardcoded defaults that this form never applies:

[jo]: n && r && `build`  in n ? `${r} run build`  : ``,
[Fo]: n && r && `deploy` in n ? `${r} run deploy` : `npx wrangler deploy`,
[ji]: `npx wrangler versions upload`,   // non_production_branch_deploy_command
[Uo]: `npx wrangler preview`,           // preview_command

So on any account where a (isWorkerPreviewsEnabled) is true, i.preview_command is read from a form that never collects it. That is consistent with what we observed: affected accounts take the createPath: 'worker_previews' branch, and accounts that succeeded before 11 August did not.

Suggested fix, unchanged and one line — default h rather than letting it reach the schema as undefined:

h = (a ? i.preview_command : i.non_production_branch_deploy_command)
    ?? `npx wrangler versions upload`;

If this is the wrong repository, that is completely fair and I would rather it were routed than closed. Could you point me at where dashboard bugs are tracked? I filed here because the flow is the documented Deploy to Cloudflare button and it fails for cloudflare/templates itself, so it looked like Workers tooling rather than a dashboard-only concern. Happy to refile anywhere more useful.

For whoever picks it up: the user-visible cost is not the console error, which nobody sees. It is that a failed submit still leaves a two-file repository in the user's GitHub account, an unconfigured build, and a placeholder Worker answering Hello world, underneath a dashboard that says the deploy succeeded. Several of us lost a day to that before finding the error at all, and #31 is the same end state reported from the other side.

[workers-devprod]

Note

This is an automated, advisory triage report generated by workers-devprod. It is not an official maintainer response — a maintainer will follow up.

🤖 Automated triage report

Issue Triage: #70

Summary

The dashboard's "Deploy to Cloudflare" flow throws an uncaught ZodError on previews_base_config.deploy_command and silently aborts every submit — including for Cloudflare's own templates — leaving behind a half-created repo, an unconfigured build, and a placeholder Worker under a "success" message.

Classification

• Type: Bug
• Component: Cloudflare dashboard (dash.cloudflare.com / deploy.workers.cloudflare.com) — not workers-sdk
• Severity: High
• Has Reproduction: Yes (public URL + unauthenticated curl against the shipped bundle)
• Quality: Complete

Findings

• Created: 2026-08-12
• Author: thankywal
• Version: N/A (dashboard flow, no local wrangler)
• Labels: none
• Comments: 2

Analysis

• The defect lives in the shipped dashboard JavaScript bundle cf-ConfigureTemplate.CN_WXn13.js (frames :38:62815, :38:74781) served from dash.cloudflare.com. The reporter traced it precisely: on accounts with Worker Previews enabled (createPath: 'worker_previews'), previews_base_config.deploy_command is sourced only from preview_command, a form field that this template form never renders, so it reaches the Zod schema as undefined and throws before any request is sent.
• This is not a workers-sdk (wrangler/miniflare/vite-plugin/C3) bug. The failing code is a dashboard front-end artifact; there is no corresponding source in this repository to fix. Per triage guidance (Step 2e — wrong repo / platform issue), dashboard/API behavior is not fixable here.
• The report is exceptionally thorough: a public reproduction that needs no account (unauthenticated curl of the bundle), a controlled experiment across 4 repos / 3 Cloudflare accounts / 3 GitHub identities / 2 browsers, root-cause analysis, and a one-line suggested fix.
• The reporter explicitly acknowledges this may be the wrong repository and asks to be routed to where dashboard bugs are tracked, rather than closed.
• References Deploy to Cloudflare button: source import silently fails — created repo has only README + wrangler config, worker stuck on Hello World placeholder #31 as the same end-state (two-file repo + Hello World placeholder Worker) reported "from the other side" — a possible related workers-sdk issue worth a maintainer glance, but not evidence this belongs here.

Recommendation

Status: CLOSE

Reasoning: The root cause is in the live Cloudflare dashboard bundle, which is not part of the workers-sdk codebase and cannot be fixed from this repo. The reporter has done excellent diagnostic work and explicitly asked for routing to the correct tracker rather than a dismissal.

Action: Route this to the internal dashboard team (not a public workers-sdk fix). A maintainer should forward the root-cause analysis and one-line fix internally, then post the comment below acknowledging the finding and closing here. Also cross-check #31, which the reporter cites as the same end state — if that describes a genuinely workers-sdk-side symptom (e.g. the template/import producing a two-file repo), it may warrant separate follow-up.

Suggested Labels: (none — omitting rather than guessing at non-existent labels)

Suggested Comment

Thanks for the incredibly detailed write-up — the unauthenticated curl reproduction against the shipped bundle and the root-cause analysis are much appreciated. You're right that this is the wrong repo, though: the ZodError originates in the Cloudflare dashboard front-end (cf-ConfigureTemplate.CN_WXn13.js served from dash.cloudflare.com), which isn't part of workers-sdk and can't be fixed from here. I'm going to forward your analysis and suggested fix to the dashboard team internally and close this issue on the workers-sdk side. If you'd like to track it directly, dashboard issues are best raised via Cloudflare Support (https://dash.cloudflare.com/?to=/:account/support). Separately, we'll take a look at #31 to see whether the half-completed-repo end state has a workers-sdk-side component. Thanks again for the thorough report.

Structured summary (JSON)

{
  "issueNumber": 15147,
  "title": "Deploy to Cloudflare: ZodError on previews_base_config.deploy_command aborts every submit, including Cloudflare's own templates",
  "githubUrl": "https://github.com/cloudflare/cf-platform-issues/issues/70",
  "recommendation": "CLOSE",
  "difficulty": "n/a",
  "reasoning": "The bug is in the live Cloudflare dashboard front-end bundle (cf-ConfigureTemplate.js on dash.cloudflare.com), which is not part of the workers-sdk codebase and cannot be fixed from this repo. The reporter explicitly asked to be routed to the correct tracker.",
  "suggestedAction": "Forward the root-cause analysis and one-line fix to the internal dashboard team, then close on the workers-sdk side. Cross-check related issue cloudflare/cf-platform-issues#31 for any workers-sdk-side symptom.",
  "hasSuggestedComment": true,
  "suggestedLabels": []
}