[Feature]: Cloudflare Workers deploy provider (Workers Static Assets), alongside Vercel and Pages

[zenprocess]

What problem are you trying to solve?

OpenDesign can deploy to Vercel and to Cloudflare Pages. The Cloudflare Pages provider uploads a static asset manifest only, so anything that needs code on the edge (an API route, a form handler, a Durable Object, environment bindings) cannot be deployed from OpenDesign to Cloudflare.

Cloudflare is also steering new projects to Workers with Static Assets rather than Pages. Today a user whose site is a Worker has to leave OpenDesign and run wrangler deploy by hand, and loses the deploy button, the deployment history and the link check.

Describe the solution you'd like

A third deploy provider, cloudflare-workers, that behaves exactly like the existing vercel-self and cloudflare-pages providers:

• Settings: the same settings pattern (API token + account ID, masked token, configured flag) through /api/deploy/config?providerId=cloudflare-workers.
• Deploy: the same deploy button, preflight, deployments list and check-link routes, and the same od deploy CLI path.
• Upload: the project's files go up as Workers Static Assets: an upload session with the manifest, only the missing buckets uploaded, then a completion token.
• Worker script: a Worker with an assets binding. By default it is a minimal assets-only Worker; if the project ships its own worker.js/_worker.js, that is used instead.
• URL: published on <name>.<subdomain>.workers.dev, with an optional custom domain on a zone the token can edit, mirroring the Pages zones picker.
• Preview vs production: preview deployments use Worker versions / preview URLs, so a preview does not replace production (the same concern as [Bug]: Cloudflare Pages deploys are always production — target: 'preview' is ignored, no way to publish a gated preview #4483 and Expose deploy target (preview/production) in the web UI and od deploy CLI #4577 for Pages).

No new runtime dependency is needed; this is all Cloudflare REST API calls, like the Pages provider.

Alternatives you've considered

• Pages Functions: the Pages provider would need _worker.js/Functions bundling. Cloudflare's own guidance points new work to Workers, and Pages cannot host Durable Objects.
• Shelling out to wrangler: this adds a heavy dependency and a Node toolchain requirement to the daemon image, and it is harder to test.
• A deploy plugin outside core: the deploy UI, settings and history are core today, so a plugin could not offer the same experience.

Additional context

• Related: [Bug]: Cloudflare Pages deploys are always production — target: 'preview' is ignored, no way to publish a gated preview #4483 (Pages preview vs production), Expose deploy target (preview/production) in the web UI and od deploy CLI #4577 (deploy target in UI/CLI), enhancement: Deploy to Railway/Vercel/Netlify buttons #1027 (more deploy targets).
• Two companion requests keep this one focused: "Connect Cloudflare" OAuth sign-in instead of pasting an API token, and deploying a site behind Cloudflare Access. Filed as [Feature]: "Connect Cloudflare" OAuth sign-in for Cloudflare deploy providers (instead of pasting an API token) #8412 (OAuth sign-in) and [Feature]: Deploy privately behind Cloudflare Access (Zero Trust) from the Cloudflare deploy dialog #8413 (Cloudflare Access).
• I'm happy to open a PR that mirrors the existing Pages provider file by file: daemon provider + routes + CLI, contracts, web registry + FileViewer button, i18n keys in all locales, and tests next to the existing deploy tests.

Would you be willing to contribute a PR?

Yes, I can take this on

[open-design-bot]

🎉 📡 You just leveled up to Giotto

📡 ✨ Sending steady signals.

🙌 Your contributions are sending a clear signal across the network: you care about making Open Design better. Keep transmitting.

💛 Thanks for helping Open Design move forward. Keep building in the open. 🚀

---

📊 Rank #189 among 100+ contributors

🔗 Share on X (English) · 分享到 X（中文）

[lefarcen]

Hi @zenprocess! 👋

The provider boundary is well thought out: keeping Workers Static Assets separate from the existing Pages flow is the right direction, especially since the current deployment code only has Vercel and Cloudflare Pages provider IDs. The preview/production work from #4483 and #4576 gives this a useful foundation, but the Worker upload session, optional worker script, bindings, and version promotion need their own provider contract rather than being folded into Pages.

help wanted is on this so an experienced contributor can pick it up. Since you’re ready to contribute, a PR that starts with the daemon provider/config and upload lifecycle plus focused mocked REST tests would be a solid first slice; we can then review the UI, CLI, custom-domain, and i18n wiring against that contract. The companion OAuth and Access requests in #8412 and #8413 are usefully separate. ✨

[lefarcen]

This is ready for an experienced community contributor. Comment /claim if you’d like to take it on, and we’ll track the implementation here.

[zenprocess]

Prior work I should have linked when filing, for maintainers weighing this:

• feat(web): add display.dev deploy option #3301 (display.dev) and feat(deploy): add native support for Netlify, Render, and Railway deployments #3388 (Netlify/Render/Railway) are open PRs that add deploy providers and touch the same files this would. feat(web): add display.dev deploy option #3301 also splits shared pieces out of deploy.ts (deploy/config-file.ts, deploy/deployment-response.ts, deploy/errors.ts).
• fix(deploy): honor target preview/production for Cloudflare Pages (#4483) #4576 (merged) added the Pages preview/production target, so the Workers provider should reuse that target contract rather than invent its own.

I searched open and closed issues, PRs, Discussions and branches, and found nothing for a Workers deploy, Cloudflare OAuth or Cloudflare Access.

To avoid a three-way conflict, I'd build this on the provider structure you prefer. Should it be on top of #3301's split, or is there another shape you want new providers to follow first?

[lefarcen]

Hey @zenprocess — this is valuable context. #3301’s extracted deploy modules are exactly the overlap we need to account for, while #4576’s preview/production target contract should remain shared rather than being recreated for Workers.

Because the choice between building on an open provider refactor and introducing a parallel provider shape affects the long-term deploy surface, we’ve routed the sequencing decision to the product lead. Please hold off on opening the PR until that direction is settled; we should have an update within about 12 hours, which should save you a conflict-heavy rebase.

[lefarcen]

Hey @zenprocess — I’ve rechecked the dependency points: #3301 and #3388 are both still open, so neither provides a merged provider shape that this work can safely depend on yet. Your overlap map is useful, and we’ll keep this parked under needs-product-direction until the sequencing decision identifies the base to target rather than asking you to absorb a speculative rebase.

[lefarcen]

PR #8451 is now open as a draft for the Workers Static Assets target described here, including the existing Pages-style deployment flow plus Worker bindings and custom-domain support. It remains under review, and this issue will stay open until the implementation lands.