Deploy to Cloudflare button: source import silently fails — created repo has only README + wrangler config, worker stuck on Hello World placeholder

[freefrank]

What happened

Clicking a Deploy to Cloudflare button (deploy.workers.cloudflare.com/?url=...) completes with no visible error, but the deployment is broken:

• The newly created GitHub repo contains only two files: README.md and the wrangler config. All source is missing (src/, package.json, lockfile, everything else).
• The wrangler config's name field is rewritten to the new worker name, with all other content — including comments — preserved verbatim. So the repo was clearly synthesized from the deploy page's parsed state, not cloned from git.
• Commit fingerprint of the broken path: Initial commit (adds README.md) + Uploading template. (adds the wrangler config) — instead of the normal single source repo import commit that successful deploys produce.
• The worker is created but stays on the "Hello World" placeholder (deployments show Source: Upload at flow time). Since the repo has no source, any build would fail anyway.
• Secrets are provisioned (a Secret Change deployment appears seconds after creation).
• Workers Builds doesn't appear to be wired up either: later pushes to the created repo trigger no builds and no check-runs (commit status stays pending with zero contexts).
• The deploy UI reports neither success nor failure — it just returns to the deploy screen.

Evidence this is a service-side intermittent failure (not repo content)

GitHub commit search shows two distinct outcomes happening in parallel, same day:

Path	Commits	Created repo content
✅ success	single source repo import	full source tree
❌ fallback	Initial commit + Uploading template.	README.md + wrangler config only

Same source, different outcomes:

• chanfana-openapi-template (official Cloudflare template): chaunceyv2-byte/chanfana-openapi-template imported the full source on 2026-07-04, while walusimbikassim9-lab/chanfana-openapi-template got the 2-file fallback on 2026-07-03.
• wloc-spoofer (community repo): xw-yin/wloc-spoofer succeeded and qqqqqqqqqqqq23131/wloc-spoofer got 2 files — same day.

Ruled out (each disproven by at least one observed case):

• monorepo subdirectory URLs — a fully self-contained standalone repo fails too
• wrangler.toml vs wrangler.jsonc — plenty of .jsonc victims, including the official template above
• private repos — all repos involved are public
• missing template metadata (.gitignore, cloudflare key in package.json, .dev.vars.example) — official templates have all of these and still hit the fallback

Scale: a commit search for "Uploading template." surfaces dozens of affected repos in 2026-07-03 → 07-05 alone. Failures also look sticky per user/session: one user hit it 3× in one day (peterniss/proxycontroller, ...02, ...03), and I hit it twice in one day with two different source repos.

My repro (account a6f98d533d0a0c22b3fdaded5cd8b8b2)

1. 2026-07-04 ~19:02 UTC — ?url=https://github.com/Javis603/token-monitor/tree/main/worker (public monorepo subdir) → repo freefrank/token-monitor-hub created with 2 files, worker token-monitor-hub left on the Hello World placeholder.
2. 2026-07-04 ~19:53 UTC — ?url=https://github.com/freefrank/token-monitor-hub (standalone, fully self-contained, public — I had pushed the full source into it by then) → repo token-monitor-hub-test created, again with only 2 files.

(I've since recovered manually: pushed the source and ran wrangler deploy — the worker itself runs fine, so the source is not the problem. The -test worker has been deleted.)

Expected behavior

Either the created repo contains the full source (source repo import), or the flow surfaces an error instead of silently committing a placeholder template and leaving a Hello World worker that looks deployed.

Ask

1. Fix / add retries to the source-import step of the deploy flow.
2. Surface import failures in the deploy UI — the silent fallback makes users debug their own repos for hours when nothing is wrong with them.

[thaleslaray]

Independent reproduction on 2026-08-11 (three consecutive attempts) confirms the same failure.

Minimal public source: https://github.com/thaleslaray/smartzap-deploy-button-probe

The source contains exactly four root items: README.md, package.json, src/index.js, and wrangler.jsonc. I tested it both as a normal repository and after enabling GitHub's Template repository setting.

Generated targets (archived to preserve evidence):

• https://github.com/thaleslaray/smartzap-deploy-probe-a811
• https://github.com/thaleslaray/smartzap-deploy-probe-b811
• https://github.com/thaleslaray/smartzap-probe-template-811

All three targets received only README.md plus wrangler.jsonc; none received package.json or src/index.js, none connected Workers Builds, and none started a first build.

The GitHub app permission hypothesis is ruled out in this reproduction: the public Cloudflare Workers and Pages app currently requests administration: write and contents: write, and the target commits named Uploading template. were authored successfully by cloudflare-workers-and-pages[bot].

A larger application reproduced the same path. After manually copying the missing source and connecting Workers Builds, the build completed and the Worker ran correctly, confirming that the package itself was deployable. Cleanup removed the exact Worker, D1, R2, Workflows, and Queues/DLQs created by the failed canary.

This continues to look like a provider-side source-import/fallback defect. The deploy flow should fail visibly instead of presenting a partial two-file repository as a usable deployment.

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

Summary

The "Deploy to Cloudflare" button (deploy.workers.cloudflare.com/?url=...) intermittently fails silently: the generated GitHub repo contains only README.md + the wrangler config (no source), the worker stays on the "Hello World" placeholder, and Workers Builds is never wired up — with no success/failure shown in the UI.

Classification

• Type: Bug
• Component: Deploy to Cloudflare button / dashboard deploy flow (server-side). Not a Wrangler CLI issue; possibly packages/workers-shared or an internal service, hence the existing internal label.
• Severity: High
• Has Reproduction: Partial — no clonable minimal repro, but concrete evidence with the official chanfana-openapi-template and example repo chaunceyv2-byte/chanfana-openapi-template, plus commit-fingerprint analysis distinguishing success vs. fallback paths.
• Quality: Complete

Findings

• Created: 2026-07-04
• Author: freefrank (dotSlash)
• Version: not specified (N/A — server-side deploy flow, not a local CLI version)
• Labels: internal
• Comments: 1 (from the maintainer bot workers-devprod)

Analysis

• The report is unusually detailed and well-evidenced. It identifies a specific failure signature: broken deploys produce Initial commit (adds README.md) + Uploading template. (adds wrangler config) commits instead of the normal single source repo import commit, meaning the repo is synthesized from the deploy page's parsed state rather than imported from git.
• The reporter explicitly argues this is a service-side intermittent failure, not repo content: the same official template produces both successful and broken outcomes on the same day.
• Downstream effects are captured: worker left on placeholder (Source: Upload), secrets still provisioned, and Workers Builds not wired up (later pushes trigger no builds/check-runs; commit status stays pending).
• This is the dashboard "Deploy to Cloudflare" button flow (deploy.workers.cloudflare.com), which is a Cloudflare platform/service surface rather than the Wrangler CLI. The internal label and the workers-devprod bot's acknowledgement/"thanks for the report"/team-routing comment indicate it is already being routed internally.
• Not spam, not stale (created ~1 month ago, recently updated), not a duplicate, and not user error. The reporter's framing points away from a fixable-in-CLI change and toward an internal service investigation.

Recommendation

Status: KEEP OPEN

Reasoning: This is a credible, well-documented bug in the server-side "Deploy to Cloudflare" flow that is already tagged internal and acknowledged by the maintainer bot. It is not resolvable purely in the workers-sdk CLI, so it should stay open as a tracking item while the relevant internal team investigates the intermittent import/build-wiring failure.

Action: Route to the team that owns the Deploy to Cloudflare button / dashboard deploy flow and Workers Builds provisioning. Confirm whether the intermittent source repo import vs. Initial commit + Uploading template. fallback is a known service-side regression, and whether the missing Workers Builds wiring is the same root cause. Keep the internal label.

Suggested Labels: internal

Suggested Comment

Thanks for the detailed write-up and the success-vs-fallback commit analysis — that's really helpful for narrowing this down. This looks like a server-side issue in the Deploy to Cloudflare flow (the source import falling back to a synthesized repo, and Workers Builds not being wired up) rather than something in the Wrangler CLI. We're routing it to the team that owns that flow to investigate the intermittent behavior. We'll keep this open to track it — if you can note the approximate timestamps/worker names of a couple of broken deploys, that would help correlate against service logs.

Structured summary (JSON)

{
  "issueNumber": 14553,
  "title": "Deploy to Cloudflare button: source import silently fails — created repo has only README + wrangler config",
  "githubUrl": "https://github.com/cloudflare/cf-platform-issues/issues/31",
  "recommendation": "KEEP OPEN",
  "difficulty": "hard",
  "reasoning": "Well-documented, actively-triaged bug in the server-side Deploy to Cloudflare flow (already labeled internal). Source import intermittently falls back to a synthesized repo with no source and no Workers Builds wiring, which is not fixable in the Wrangler CLI.",
  "suggestedAction": "Route to the team owning the Deploy to Cloudflare button / dashboard deploy flow and Workers Builds provisioning; confirm whether the intermittent source-import fallback is a known service-side regression. Keep the internal label.",
  "hasSuggestedComment": true,
  "suggestedLabels": ["internal"]
}

[pejmanjohn]

Independent reproduction from another Cloudflare account confirms the same failure with https://github.com/pejmanjohn/chickpea.

Four attempts on 2026-08-11 created the Worker, D1 database, and target GitHub repository, but every generated repository contained only README.md and wrangler.jsonc. None received the source-import commit, connected Workers Builds, started a build, or navigated to the build logs.

The Cloudflare dashboard console exposed a more specific failure:

ZodError:
path: ["previews_base_config", "deploy_command"]
expected string, received undefined

at cf-useBuilds.uddqqOQN.js
at cf-ConfigureTemplate.4YSxnyZh.js

Dashboard version:

x-dash-version: 9e15931e-027e-46cf-941c-d6b87c6580b4

One controlled attempt disabled “Builds for non-production branches”; it still produced the identical exception and two-file repository. With previews enabled, the form visibly contained the expected default command, npx wrangler versions upload, so the form input itself was not blank.

The stack and resulting state suggest that the dashboard successfully creates the initial resources, then aborts while parsing the build-settings response—before source import and the first Workers Build are started. This looks like a frontend/backend response-schema mismatch involving previews_base_config.deploy_command, rather than a source-repository or GitHub-permission failure.

All disposable Workers, databases, and repositories were removed after capturing the evidence. Could the platform team check whether the build-settings API recently stopped returning this field, or whether the dashboard schema should accept it as absent?

[thaleslaray]

Reteste adicional em 2026-08-11 após eliminar as duas hipóteses operacionais restantes:

• Conta GitHub pessoal thaleslaray com o GitHub App Cloudflare Workers and Pages instalado.
• A primeira tentativa encontrou a cota de 50 User API Tokens; removemos dois tokens de build obsoletos e repetimos com vagas disponíveis.
• Origem pública, standalone e mínima: https://github.com/thaleslaray/smartzap-deploy-button-probe
• A origem contém README.md, package.json, src/index.js e wrangler.jsonc.
• Destino pós-limpeza: https://github.com/thaleslaray/smartzap-deploy-probe-d811
• Resultado: somente README.md e wrangler.jsonc.
• Fingerprint reproduzido novamente:
  • 01ef2a85e7c4 Initial commit
  • 33f113724e48 Uploading template.
• Cloudflare criou deployments com source dash_template.
• Nenhum check-run de Workers Builds apareceu no commit principal.
• A UI voltou silenciosamente ao formulário sem sucesso ou erro.

O mesmo resultado ocorreu imediatamente antes no destino smartzap-deploy-probe-c811. Portanto, reinstalação/autorização do GitHub App e liberação da cota de tokens não corrigiram o source import; o fallback service-side permanece reproduzível.