🐛 BUG: Deploy to Cloudflare button fails with misleading "problem parsing the Wrangler configuration file" when package.json cloudflare metadata has empty preview_image_url

[tombeckenham]

Note

Updated after systematic bisection — the original report below the fold blamed instance_type: "standard-4", which turned out to be wrong. The actual root cause is in package.json template metadata, and the error message misattributes it to the Wrangler config file.

Root cause

The Deploy to Cloudflare button (POST /api/v4/workers/template-from-worker, returns 400) fails when package.json's "cloudflare" template-metadata block contains an empty "preview_image_url": "" — and the dashboard reports it as:

There was a problem parsing the Wrangler configuration file. Please raise an issue in the Workers SDK repo.

The Wrangler config file is not the problem. That misattribution sent us down a long false trail.

Bisection evidence

All tests run against fresh paths of the same public repo (tombeckenham/hyperframes-cloudflare-template-tom), each path a distinct subdirectory so results couldn't be cached (see caching note below):

Test	Contents	Result
official containers-template verbatim	—	✅ pass
official + this template's full wrangler.jsonc (containers, Dockerfile image, standard-4-equivalent custom instance type, custom build, assets, R2, vars)	config exercised alone	✅ pass
official + this template's package.json	metadata exercised alone	❌ fail
same, wrangler devDependency pinned 4.88.0, no lockfile	rule out wrangler version resolution	❌ fail
same, "cloudflare" block deleted		✅ pass
official + only the "cloudflare" block transplanted	converse	❌ fail
block with "preview_image_url": "" removed (empty "icon_urls": [] kept)		✅ pass
block with "icon_urls": [] removed, "preview_image_url": "" kept		❌ fail
full app, original wrangler.jsonc with instance_type: "standard-4", only preview_image_url removed	end-to-end	✅ pass

So: "preview_image_url": "" (empty string) → hard failure with a misleading error. instance_type: "standard-4" and the rest of the config are fine. Empty "icon_urls": [] is fine.

Reproduction

Any public repo whose package.json contains:

"cloudflare": {
  "label": "...",
  "preview_image_url": ""
}

opened via https://deploy.workers.cloudflare.com/?url=<repo> shows the "problem parsing the Wrangler configuration file" error.

Suggested fixes

1. Treat an empty/missing preview_image_url as "no preview image" instead of failing (it's easy to end up with "" when scaffolding metadata).
2. If it must be rejected, say so: "Invalid cloudflare.preview_image_url in package.json" — not a Wrangler-config parse error pointing at the wrong file.

Secondary issue: verdict caching makes this near-impossible to debug

The parse verdict appears to be cached per repo/path for at least ~30 minutes, ignoring new commits. Concretely: after a path had passed once, we committed a deliberately corrupted wrangler.jsonc (unbalanced braces) to that path and the flow still showed the passing configure step; conversely a failing repo kept failing across many fix commits. Anyone iterating on a template fix will conclude their fixes don't work. A cache key including the commit SHA (or a shorter TTL) would fix this.

---

Original (incorrect) report — kept for history

The original report reproduced the same dashboard error on heygen-com/hyperframes-cloudflare-template and, based on old wrangler versions locally rejecting "instance_type": "standard-4" (wrangler@4.40.0: Expected "containers.instance_type" field to be one of ["dev","basic","standard"]), concluded the server ran an outdated config schema. That local repro was a coincidence: the server-side failure was the empty preview_image_url in package.json all along (that repo has both). Environment: macOS 26.5, Node 25.9.0, wrangler 4.85–4.114 all deploy the config fine via CLI.

[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: #14831

Summary

The "Deploy to Cloudflare" button's server-side config parser (template-from-worker API) rejects container instance_type values like standard-4, returning HTTP 400, even though current Wrangler versions accept them.

Classification

• Type: Bug
• Component: packages/wrangler (config validation / container instance types) — but the failing parser is a server-side dashboard/API service (template-from-worker), not code in this repo
• Severity: Medium
• Has Reproduction: Yes (with link)
• Quality: Complete

Findings

• Created: 2026-07-24
• Author: tombeckenham
• Version: wrangler 4.85.0 (also tested 4.113.0/4.114.0); repro traced to wrangler < 4.60 locally
• Labels: none
• Comments: 0

Analysis

• The reporter is explicit and precise: the failure is server-side, in the dashboard's POST /api/v4/workers/template-from-worker endpoint, which parses the repo's wrangler.jsonc with an outdated config schema that predates the named container instance types (standard-1…standard-4, lite) added in October 2025.
• Local Wrangler is not at fault — the CLI parses and deploys the config fine on ≥ 4.60. The reporter reproduced the identical instance_type enum error only on old Wrangler (4.40.0), which supports the "stale server-side schema" theory.
• The actual code fix lives in the Cloudflare server-side service behind template-from-worker, which is not in the workers-sdk repo. This overlaps with the 2e ("wrong repo") category — but the dashboard UI error explicitly tells users to file here, and the config schema itself originates from workers-sdk's validation, so a maintainer should verify/route rather than close outright.
• The report is high quality: clear repro link, inferred root cause, HTTP status, offending config block, and a verified workaround (expressing instance_type as an explicit { vcpu, memory_mib, disk_mb } object, which both old and new parsers accept). The reporter also flags a real footgun: downgrading to the legacy "standard" name silently aliases to standard-1 (½ vCPU / 4 GiB), shrinking the container.
• Fresh issue (opened today), no maintainer response yet, so it is not stale, not a confirmed duplicate, and not fixable purely in this repo.

Recommendation

Status: KEEP OPEN

Reasoning: This is a well-documented, reproducible bug, but the failing parser is a Cloudflare server-side service (template-from-worker), not code in workers-sdk. It needs a maintainer to verify and route it to the dashboard/API team rather than being closed or fixed directly here.

Action: A maintainer should confirm the server-side schema is stale, then route to the internal team that owns the template-from-worker endpoint (Deploy to Cloudflare button). Post the suggested comment to set expectations while routing.

Suggested Labels: (none — omitted; cannot confirm exact repo label names)

Suggested Comment

Thanks for the detailed report — the root-cause analysis and workaround are really helpful. You're right that current Wrangler accepts these named container instance types; the failure is in the server-side parser behind the Deploy to Cloudflare button (template-from-worker), which isn't part of the workers-sdk codebase. We'll route this to the team that owns that service so the parser can be updated to track the current container config schema. In the meantime, the explicit { "vcpu": …, "memory_mib": …, "disk_mb": … } form you found is a good workaround. We'll follow up here as we learn more.

Structured summary (JSON)

{
  "issueNumber": 14831,
  "title": "Deploy to Cloudflare button rejects configs using container instance_type \"standard-4\" — server-side parser runs an outdated config schema",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/14831",
  "recommendation": "KEEP OPEN",
  "difficulty": "n/a",
  "reasoning": "Well-documented, reproducible bug, but the failing parser is a Cloudflare server-side service (template-from-worker) behind the Deploy to Cloudflare button, not code in workers-sdk. It needs maintainer verification and routing to the dashboard/API team.",
  "suggestedAction": "Confirm the server-side config schema is stale and route to the internal team that owns the template-from-worker endpoint; post the suggested comment to set expectations.",
  "hasSuggestedComment": true,
  "suggestedLabels": []
}