An open pipeline that runs in your CI
Cloudflare has released Forge, an open source, pluggable generation pipeline for SDKs, CLIs, docs, and libraries. It is free to deploy and run. Forge is early in its life, but it already produces the output required for the cf CLI, and over the next few months it will power Cloudflare's API documentation, SDKs, and more.
The project exists because Cloudflare needed it internally in order to treat agents as customers, and it is being opened up so anyone can generate the surfaces agents need. CLIs, API SDKs, and MCP servers with matching documentation used to be expected only of developer products; they are now table stakes for every product.
Why Cloudflare built its own generator
Cloudflare's API spans over 3,500 operations, and the hundreds of services behind it are written in a mix of languages including Rust, Go, TypeScript, and Python. Building a CLI for the entire API, along with SDKs and docs, called for a generation pipeline that could operate at that scale while accommodating different languages and the way each engineering team works.
Coordination overhead was the other driver. When a product team changes an API, they need to install a preview build of the Cloudflare-wide CLI, SDK, and docs site generated from that change before merging and shipping. They also need assurance they haven't broken the pipeline itself. And the system had to be extensible beyond SDKs — toward Cap'n Web, MCP, and other targets.
Cloudflare tried several hosted products for this and relied on some in production. None solved the problem, and some shut down entirely. Changes from one team would silently break the generation pipeline, another team would find out at release time, and effort went into working around hosted tools they could not control and coordinating between teams and vendors.
Forge addresses this by running in CI, on each team's API repos, alongside pipelines such as Cloudflare's AI code reviewer and test suites. It lints every change and generates preview builds of the CLI, docs, and SDKs with only that change highlighted, ready to install and test. The premise matches Workers Previews: a full preview build per change, applied to SDK generation at scale, even when the API surface is spread across hundreds of services and repositories.
Transformers, chaining, and outputs beyond language SDKs
Forge is designed to be pluggable and to support many input and output types. It ships with CLI, SDK, and docs generators, and nothing prevents you from adding a transformer that emits a library-specific package or a whole dashboard or application. OpenAPI is the input format supported today, but the design leaves room for AsyncAPI, GraphQL, Cap'n Proto, Protobuf, or other formats later.
More importantly, outputs can be chained: one target's output becomes the input for another. Producing CLI and Terraform targets from a Go SDK is common in other generators, but Forge gives the user control over that chaining system rather than deciding it for them. Cloudflare needed this itself, since the cf CLI is written in TypeScript, a language other SDK generators generally don't chain from for CLIs.
CLIs are different from SDKs because they often add local-only behaviors that no API call backs — code written by hand. The cf CLI, for example, has cf dev and cf build commands layered on top of the generated output, and those commands need to call TypeScript APIs from packages like Vite. That raises a documentation question: if the CLI and docs are generated purely from the OpenAPI spec, how do handwritten commands get documented alongside the rest? Cloudflare could not find an existing tool that handles this, so it is building it into Forge.
Cloudflare has more reason than most to want targets beyond the usual languages. Cap'n Web is its RPC system that lets TypeScript call a remote API as if it were a local method:
Forge can take an OpenAPI spec and generate Cap'n Web directly, which opens the door to generating bindings from Workers to other APIs — bindings in the Workers runtime are implemented as Workers exposing RPC methods. Other widely used tools need the same treatment: TanStack Query users would want query bindings generated straight from the API, always current and validated against the real thing. The same applies to Zod or Valibot schemas, MCP servers, or anything else that makes an API easier to consume.
Versioning, future SDKs, and licensing
Forge also sets Cloudflare up for better API versioning. Its v4 API has been the one major version for 10 years; by SemVer definitions, many changes since would have warranted a new major version, and several operations still carry internal 'v2' tags or 'beta' identifiers that outlived that part of the product's lifecycle. A big new v5 would leave many customers behind, so Cloudflare is working on a versioning approach that lets it release new major API versions without breaking old clients or SDKs, with Forge releasing artifacts along the way.
More on the SDKs is coming soon, including TypeScript, Rust, Python, Go, PHP, and Terraform — especially Terraform, where upgrades carry their own rigor and the transition will get extra care.
Forge is released under the permissive Apache 2.0 license. Cloudflare's position is that building tools for APIs is a core part of the Internet and should not require a SaaS product: you should own your SDKs, CLIs, and docs, and be able to generate them wherever you want, for free. Contributions are welcome, and running Forge privately for any purpose with custom modifications is equally fine.
Acknowledgements: This project was also made possible by the design and implementation efforts of Dan Carter, Steven Chong, Krishna Paritala, and Shelley Jones.
