Cloudflare Open-Sources Forge to Generate SDKs, CLIs, and Documentation

Cloudflare Open-Sources Forge to Generate SDKs, CLIs, and Documentation Cloudflare has introduced Forge, an open-source and pluggable generation pipeline under the Apache 2.0 license designed to generate SDKs, CLIs, documentation, and other developer surfaces from API specifications. Forge is released under the Apache 2.0 license to allow teams to deploy and self-host generation pipelines for free without SaaS lock-in. Built to handle Cloudflare's scale of over 3,500 API operations, Forge integrates into CI workflows to provide preview builds and prevent pipeline breakages. The tool supports chained generators and custom handwritten CLI commands, feeding composite outputs back into documentation. Forge currently generates the 'cf' CLI and supports OpenAPI, with plans to support formats like AsyncAPI, GraphQL, and Protobuf, as well as an improved API versioning model. Scaling Code Generation Across Teams Cloudflare developed Forge to address the operational challenges of managing over 3,500 API operations distributed across hundreds of microservices written in Rust, Go, TypeScript, and Python. Existing hosted tools frequently caused cross-team coordination bottlenecks and broke when teams merged API changes. Forge runs directly in CI pipelines on API repositories, linting updates and generating isolated preview builds of CLIs, SDKs, and documentation to validate changes before merging. Pluggable Architecture and Chained Outputs Forge accepts OpenAPI specifications today and is designed to accept inputs such as AsyncAPI, GraphQL, Cap’n Proto, and Protobuf in the future. It allows developers to control output chaining, enabling one target (such as a TypeScript CLI) to feed into others, and accommodates handwritten commands—like local build steps—directly alongside generated endpoints so they can be accurately reflected in API documentation. Extended Targets and Versioning Strategy Beyond standard language SDKs (including TypeScript, Rust, Python, Go, PHP, and Terraform), Forge enables specialized outputs such as Cap’n Web RPC bindings, TanStack Query hooks, Zod schemas, and MCP servers. Cloudflare is also leveraging Forge to implement an API versioning system that will allow releasing major API updates without breaking older clients or SDKs.

Cloudflare 开源代码生成流水线 Forge：支持自动化构建 SDK、CLI 与文档 Cloudflare 宣布推出并开源代码生成流水线 Forge（采用 Apache 2.0 协议）。该工具专为应对大规模分布式 API 架构而设计，可在 CI 中自动校验变更并生成对应的 SDK、命令行工具（CLI）、文档以及 MCP 服务器等产物，目前已支撑 Cloudflare 自身的 cf CLI。 旨在应对 Cloudflare 超过 3,500 项 API 操作跨数百个多语言服务构建产物时的协调与维护痛点。 直接集成于 CI 流程，可在团队合并代码前提供全套 CLI、文档与 SDK 的变更预览构建。 支持产物链路串联与扩展，可将手写 CLI 逻辑注入文档，并生成 Cap’n Web 或 Workers 绑定。 助力改进长期维持的 v4 API 版本演进策略，避免破坏性更新影响既有客户端。 研发背景与协作痛点 Cloudflare 的 API 拥有超过 3,500 项操作，后台数百个服务采用 Rust、Go、TypeScript 及 Python 等多种语言编写。以往使用的第三方托管生成工具频繁因单团队的代码合并而意外中断流水线，且难以在发布前完整验证。Forge 将生成流程移至各团队的 API 仓库 CI 中运行，提供类似 Workers Previews 的预览构建，让团队在合并前即可直观测试带有高亮差异的 CLI、SDK 与文档。 可插拔架构与目标链式生成 Forge 目前支持 OpenAPI 规范输入，未来计划拓展至 AsyncAPI、GraphQL、Cap’n Proto 与 Protobuf 等格式。该系统允许开发者自主控制产物链路串联（chaining），支持把针对特定语言编写的本地行为（如 cf CLI 中基于 TypeScript 手写的 dev 和 build 扩展命令）重新反馈到自动生成的文档中。此外，它还能将规范编译为 Cap’n Web RPC、TanStack Query 绑定以及 MCP 服务器。 API 版本管理与完全开源 针对已使用 10 年的 v4 API，Cloudflare 借助 Forge 在发布产物时的灵活性，探索平滑的版本迭代机制，力求在推出新版本时避免中断旧版客户端或 SDK。团队后续将推出覆盖 TypeScript、Rust、Python、Go、PHP 以及经过重点针对性升级的 Terraform Provider。Forge 现以 Apache 2.0 协议在 GitHub 正式开源，支持任意开发者免费部署或私有修改运行。

Today we’re introducing [Forge](https://github.com/cloudflare/forge), a fresh approach to generating SDKs, CLIs, docs, and libraries. Forge is an open source, pluggable generation pipeline that anyone can deploy and run for free. Forge is early in its life, but already generates the output required for the [cf CLI](https://blog.cloudflare.com/cloudflare-cf-cli-launch/), and over the next few months will power Cloudflare’s API documentation, SDKs, and much more. We built Forge because we needed it ourselves in order to treat agents as our customers. Now, we’re open sourcing it because we think everyone should be able to generate all the surfaces that agents need. It used to be that only developer products needed CLIs, API SDKs, MCP servers, all with great corresponding docs. Now these are table stakes for every product. Cloudflare’s API has over 3,500 operations, and the hundreds of services that power these APIs are written in many languages, including Rust, Go, TypeScript, and Python. As we embarked on building a CLI for the entire Cloudflare API, including our SDKs and API docs, we needed a code generation pipeline that could handle this scale. That pipeline needs to be flexible enough to work across languages and the ways each of our engineering teams operate. We needed a way to reduce coordination overhead between teams. When a Cloudflare product team makes an API change, they need to be able to use a preview build of the Cloudflare-wide CLI, SDK, and docs site that will be generated, before merging that change and shipping to customers. We needed a way to ensure they didn’t inadvertently break the generation pipeline. And we needed a system that we could extend to generate more than just an SDK, from Cap‘n Web to MCP and beyond. We’ve tried several hosted products that attempt to solve this, and relied on some in production. None of them solved this problem for us, and some have shut down entirely. One team would merge a change that inadvertently would break the generation pipeline, another team would discover this at release time, and we spent too much time swimming upstream through hosted tools we couldn’t control, coordinating changes between teams and vendors. That’s how we started building Forge. Forge seeks to fix all these problems: it runs in CI, on each team’s API repos, just like our AI code reviewer and test pipelines. It lints every change, and then generates preview builds of the CLI, docs, and SDKs with just your changes highlighted that you can install to test. It’s the same premise as [Workers Previews](https://blog.cloudflare.com/worker-previews/): a full preview build for every change, but applied to SDK generation at scale, including when the API surface is distributed across hundreds of services and repositories. That’s what Forge seeks to deliver. Cloudflare has more reasons than most to want a generator that can go well beyond the normal language targets. [Cap’n Web](https://capnweb.com/) is Cloudflare’s RPC system that lets TypeScript call a remote API as if it were calling a local method: Forge makes it possible to take an OpenAPI spec and generate Cap’n Web directly. This opens the door to generating [bindings](https://developers.cloudflare.com/workers/runtime-apis/bindings/) from Workers to other APIs. After all, bindings in the Workers runtime are implemented as Workers that expose RPC methods. This isn’t specific to Cap’n Web: other popular tools you may already rely on need the same thing. If you use [TanStack Query](https://tanstack.com/query/), you’d ideally want to be able to generate TanStack Query bindings for your application, built directly from your API itself. Always up to date, always validated against your real API. The same is true of generating Zod or Valibot schemas, MCP servers, or anything else that makes it easier to consume your API. This is possible because Forge code generators are flexible. They’re built for flowing information from one output to another. We’ve designed Forge to be pluggable, and support many input and output types. Forge provides CLI, SDK and docs generators, but there’s nothing stopping you from adding a transformer that generates a library-specific package or even a full dashboard or application. Forge supports OpenAPI as an input type today, but we’ve designed it to allow [AsyncAPI](http://asyncapi.com), GraphQL, Cap’n Proto, Protobuf, or other input formats in the future. This is about more than just compatibility: it lets you chain targets, using one target output to produce others. This is common in other generators where the CLI and Terraform targets are produced from the Go SDK. But what’s missing, and what Forge provides, is a way for the user to control this chaining system themselves. We needed a solution for this ourselves, because our own cf CLI is written in TypeScript, which other SDK generators don't generally chain from for CLIs. But our own situation made us recognize the deeper problem: why should any SDK generator tool make this decision for you? Maybe you’re a Python shop, and you want the CLI to be in Python. If you’re thinking “Well, but who cares if it’s in Python or not? The code is automatically generated,” it’s because CLIs are *different.* CLIs often introduce local-only behaviors that wouldn’t make sense in an SDK. Behaviors that you write by hand since they’re inherently not something backed by any API call. For example, the cf CLI has commands like cf dev and cf build that are added on top of the rest of the generated output. These commands need to call TypeScript APIs from other packages like Vite. Now let’s add docs to the mix. If you’re generating your CLI and your docs *purely* from your OpenAPI spec, how do you feed those handwritten commands back into your docs, so they can be documented alongside the rest? We couldn’t find an existing tool that does this today, and yet this is exactly what we need for cf. So we’re building it into Forge. Forge is also setting us up for better API versioning. Cloudflare’s v4 API has been the one major version of our API for 10 years. Since then, it appears like we haven’t launched any new major versions, but by SemVer definitions we’ve made quite a few changes worthy of a new major version. At the same time, several operations across our API feature internal ‘v2’ tags or ‘beta’ identifiers that have long outlived that part of the product’s lifecycle. After so many years of our v4 API, we’re keenly aware that a big new v5 would leave a lot of our customers behind. That’s why, with Forge releasing artifacts along the way, we’re working on an API versioning approach that allows us to release new major API versions without breaking old clients or SDKs. We’ll have more on our SDKs very soon, including TypeScript, Rust, Python, Go, PHP, and Terraform. Especially Terraform. We know that upgrading any Terraform provider comes with its own set of rigor, and we’re going to put extra special care into the Terraform transition. We believe that building tools for APIs is a core part of the Internet, and you should be able to do that without needing a SaaS product. You should own your SDKs, CLIs, and docs. And if you generate them, then you should be able to do whatever you want, wherever you want, for free. That’s why we’re making [Forge available open source](https://github.com/cloudflare/forge) under the permissive Apache 2.0 license. We want people to join in on this journey with us, and contribute. Or not? Maybe you want to keep everything to yourself. Go for it! You can run Forge on your own for any purpose, with custom modifications, for free, in private. *Acknowledgements: This project was also made possible by the design and implementation efforts of Dan Carter, Steven Chong, Krishna Paritala, and Shelley Jones.*