Deploy to Cloudflare: option to fork the source repository instead of cloning

[tombeckenham]

Describe the feature

An option for Deploy to Cloudflare buttons to fork the source repository into the user's account instead of creating an independent clone — e.g. a URL parameter (&fork=true) or a checkbox in the deploy flow.

Current behavior

Per the deploy buttons docs: "Cloudflare clones your source repository into the user's GitHub/GitLab account where they can continue development after deploying."

The created repository has no upstream relationship: no fork network link, no "Sync fork" button, and no straightforward path to open PRs against the source repo.

Use case

We maintain an open-source, self-hostable app (openstory-so/openstory) and use the deploy button as the primary self-hosting path. For this kind of project — an evolving application rather than a one-shot starter template — the clone behavior works against both sides:

• Self-hosters silently fall behind. The app keeps shipping fixes and features, but button users have no visible mechanism to pull them. With a fork, GitHub's "Sync fork" button makes staying current a one-click operation.
• Contributions are harder than they should be. Users who fix something in their deployed copy can't open a PR upstream without re-forking and re-applying their work.
• Discovery/attribution is lost. Forks show up in the fork network and link back to the source project; clones don't.

The clone behavior makes sense for starter templates where the user's copy is expected to diverge immediately. For deployable applications, a fork is usually what both the maintainer and the user want.

Workaround today

We document adding the remote manually after a button deploy (git remote add upstream … && git pull upstream main), which works since the clone carries full history — but it's invisible to users who don't read that doc, and it still doesn't restore the fork-network relationship.

Related

#14075 touches the same deploy-flow setup screen (secrets handling).