Cloudflare Workers SDK: Wrangler CLI & Toolchain
/workers-sdk
Cloudflare Workers SDK is the official toolchain for building, testing, and deploying Cloudflare Workers, centered on the Wrangler CLI. It packages scaffolding, a local simulator, and deployment tooling into one Apache-2.0 monorepo. Reach for it if you're already building on Cloudflare's platform and want one CLI for the whole workflow; skip it if you don't plan to run workloads on Cloudflare's edge.
What is Cloudflare Workers SDK?
Cloudflare Workers SDK is the GitHub home for Wrangler, the command-line tool used to build, test, and publish Cloudflare Workers. The monorepo also houses create-cloudflare (C3) for scaffolding new projects, Miniflare for local Workers simulation, and pages-shared, the code shared between Wrangler and Cloudflare Pages. Cloudflare licenses the whole toolchain under Apache-2.0, and the repository itself is written mainly in TypeScript.
Key Tools in the Cloudflare Workers SDK
- ✓Wrangler — the CLI you use to build, develop, and publish Workers directly from the command line; docs live at developers.cloudflare.com/workers/wrangler/.
- ✓create-cloudflare (C3) — a separate CLI focused on scaffolding a brand-new app and pushing it live on Cloudflare, docs under pages/get-started/c3.
- ✓Miniflare — the package that lets you run and test Workers on your own machine, built on workerd according to the README, before anything touches production.
- ✓chrome-devtools-patches — Cloudflare's own DevTools fork, adapted specifically for inspecting Workers running locally or already deployed.
- ✓pages-shared — internal code shared between Wrangler and Cloudflare Pages, not something you'd install or call directly yourself.
- ✓Beta packages — generated automatically by the pkg.pr.new tool on every commit to main, letting you pull an unreleased fix before it ships as a tagged npm release.
Use Cases for Cloudflare Workers
- •Scaffolding a new Cloudflare Workers project with one command (npm create cloudflare@latest) instead of hand-assembling the config yourself.
- •Testing a Worker on your machine with Miniflare, which the README describes as built on workerd, before pushing anything live.
- •Debugging a Worker running locally or already deployed using chrome-devtools-patches, Cloudflare's own DevTools fork made for that job.
- •Trying an unreleased Wrangler or Miniflare fix early through the pkg.pr.new beta packages, ahead of the next tagged npm release.
- •Building on Cloudflare Pages alongside Workers, where pages-shared keeps Wrangler and Pages behavior in sync.
Getting Started with Cloudflare Workers
The README's Quick Start is one command: run `npm create cloudflare@latest` (or the pnpm/yarn equivalents, `pnpm create cloudflare@latest` / `yarn create cloudflare@latest`) to scaffold a new project. From there, Cloudflare points to a separate Getting Started guide on developers.cloudflare.com for the full walkthrough. Each individual package — wrangler, create-cloudflare, miniflare — also has its own docs link listed in the repo's package directory. Installing Wrangler on its own, outside that scaffolding command, isn't clearly documented in this repo's own README.
Developing and Testing Workers
Local development and testing run through Miniflare, which the README says is built on workerd. Beyond that architecture note, the README doesn't walk through day-to-day Wrangler commands — starting a dev server, deploying, tailing logs — inline; it defers those to the external Workers documentation and the Wrangler-specific docs page, so exact command usage isn't clearly documented in this repo's own README.
Strengths
- ✓One monorepo covers project scaffolding (create-cloudflare/C3), local testing (Miniflare), and the deploy CLI (Wrangler) instead of three separately maintained projects.
- ✓Miniflare runs on workerd, per the README, so local testing has a real engine behind it rather than a generic mock server.
- ✓Beta packages publish on every commit via pkg.pr.new, so you can pull an unreleased fix without waiting for a tagged npm release.
- ✓Apache-2.0 licensing with a public CONTRIBUTING.md process, a Discord server, and GitHub Discussions for support.
- ✓chrome-devtools-patches gives you a DevTools build adapted specifically for inspecting Workers, not just generic browser devtools pointed at a Worker.
Considerations for Cloudflare Workers Development
- △The README documents only the single scaffolding command (npm create cloudflare@latest) inline; day-to-day Wrangler usage and install details are pushed out to Cloudflare's external docs rather than covered here.
- △Running a Worker in production requires a Cloudflare account (a free tier exists) — the SDK itself is open source, but the platform it deploys to is not something this repo lets you self-host.
- △Beta releases via pkg.pr.new are explicitly flagged in the README as unsuitable for stable use — fine for testing an unreleased fix, not for pinning a project to.
- △No version number or roadmap appears in the facts available here, so there's no documented release cadence to point to.
- △The toolchain is split across five packages (wrangler, create-cloudflare, miniflare, chrome-devtools-patches, pages-shared) each with its own docs link, so there's no single unified reference — you end up cross-referencing several.
Alternatives for Edge Serverless
Cloudflare Workers SDK FAQs
Cloudflare Workers SDK exists to package the tooling for building, testing, and deploying Cloudflare Workers into one repository, most centrally Wrangler, the CLI Cloudflare ships for that job.
Local development and testing are supported — Cloudflare Workers SDK includes Miniflare, a simulator the README describes as built on workerd, so you can iterate before deploying anything.
The Cloudflare Workers SDK monorepo includes Wrangler (the CLI for building and publishing Workers), create-cloudflare/C3 (project scaffolding), Miniflare (local testing), chrome-devtools-patches (a DevTools fork for inspecting Workers), and pages-shared (code shared between Wrangler and Cloudflare Pages).
Cloudflare Workers SDK is licensed under Apache-2.0, as listed on its GitHub repository.
Run `npm create cloudflare@latest` (or the pnpm/yarn equivalent) — that's the Quick Start command Cloudflare Workers SDK's README gives for scaffolding a new project.
The README doesn't enumerate every supported language, but the repo's own GitHub topics list javascript and wasm, and Cloudflare Workers SDK itself is written mainly in TypeScript — beyond JavaScript, TypeScript, and WebAssembly, exact language support isn't clearly documented here.
The problem it solves
Building for Cloudflare's edge involves several distinct steps — scaffolding a new Worker, running it locally against something close to the real environment, and shipping it — and doing that with disconnected, third-party tools is the gap this repo closes by keeping Wrangler, create-cloudflare, and Miniflare together in one place. Cloudflare frames the whole repository around one tool, Wrangler, its own CLI for Workers, rather than shipping a general-purpose serverless framework — so what it actually solves is narrower: give Workers developers a first-party toolchain instead of assembling community tooling around Cloudflare's platform.
Who should try it — and who should skip
Try Cloudflare Workers SDK if you're building on Cloudflare Workers and want Wrangler, C3, and Miniflare under one roof instead of hunting down separate tools — it fits naturally once you're already committed to Cloudflare's edge network. Skip it if you're not deploying to Cloudflare specifically: Wrangler's CLI surface is built around Cloudflare's platform, and Miniflare's local simulator mirrors workerd, not a generic serverless environment, so the SDK doesn't carry over to other clouds.
Related repositories
Want a second opinion on workers-sdk?
Ask an AI that can read this page — one click and you get its take on workers-sdk.