Skip to content

SYSTEM Cited by 2 sources

Forge (Cloudflare open-source generation pipeline)

Disambiguation. This is Cloudflare Forge, an open-source code-generation pipeline (GitHub, Apache 2.0). It is unrelated to Atlassian Forge, the app-extensibility platform.

Forge is Cloudflare's pluggable, open-source generation pipeline for producing SDKs, CLIs, docs, and other API "surfaces" from an interface spec. Announced and open-sourced 2026-09-28 under Apache 2.0, it is "early in its life" but already generates the output required for the cf CLI, and is slated to power Cloudflare's API documentation and SDKs (TypeScript, Rust, Python, Go, PHP, Terraform) "over the next few months" (Source: sources/2026-09-28-cloudflare-introducing-forge-the-open-source-pipeline-for-generating-sd).

Forge is the pipeline that realizes the "one interface spec generates every surface" thesis that the 2026-04-13 cf CLI launch post first described. Where that post revealed an internal TypeScript schema as source of truth, this post open-sources the generation engine that consumes specs and emits artifacts.

Why it exists

Cloudflare's API spans 3,500+ operations across hundreds of services and repositories, whose backends are written in Rust, Go, TypeScript, and Python. Building a CLI, SDKs, and docs for that whole surface required a generation pipeline "flexible enough to work across languages and the ways each of our engineering teams operate," and one that reduces cross-team coordination overhead.

Hosted generation products didn't work: Cloudflare tried several, relied on some in production, and "none of them solved this problem for us, and some have shut down entirely." The concrete failure mode was a shared pipeline broken by one team's change, discovered by another team at release time — too much time "swimming upstream through hosted tools we couldn't control, coordinating changes between teams and vendors."

Design pillars

1. Preview build for every change, in CI, across hundreds of repos

Forge "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." This is explicitly the Workers Previews premise — a full preview build for every change — applied to SDK/CLI/docs generation at fleet scale, "including when the API surface is distributed across hundreds of services and repositories." The goal is to detect problems in CI before they cause issues downstream (preview-build-per-change / preview-per-PR).

2. Transformers can generate anything

Forge ships CLI, SDK, and docs generators, but a transformer can emit anything — a library-specific package, a full dashboard or application, Cap'n Web, TanStack Query bindings, Zod/Valibot schemas, MCP servers — "anything else that makes it easier to consume your API," "always up to date, always validated against your real API." Notably, Forge can take an OpenAPI spec and generate Cap'n Web directly, opening the door to generating Workers bindings, since Workers bindings are implemented as Workers exposing RPC methods.

3. Transformers can be chained — and the user controls the chain

Forge is designed for information flowing from one output to another: one generated artifact becomes the input for the next. Existing generators do some of this (CLI + Terraform targets produced from a Go SDK), "But what's missing, and what Forge provides, is a way for the user to control this chaining system themselves." Cloudflare's own chain:

OpenAPI spec
   └─▶ TypeScript SDK
          ├─▶ cf CLI
          └─▶ Cap'n Web specifications

They needed user-controlled chaining because cf is written in TypeScript, "which other SDK generators don't generally chain from for CLIs" — and more generally, "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." (transformer-chaining / output-from-output codegen)

4. Multiple input formats

Forge supports OpenAPI as an input type today and is designed to allow AsyncAPI, GraphQL, Cap'n Proto, Protobuf, or other formats in the future.

CLIs are different — hand-written surface must reach docs too

A CLI carries local-only behaviors that wouldn't make sense in an SDK and aren't backed by any API call — e.g. cf dev and cf build, hand-written on top of the generated output, calling TypeScript APIs from packages like Vite. This forces a question Cloudflare "couldn't find an existing tool" to answer: if the CLI and docs are generated purely from OpenAPI, how do the hand-written commands get fed back into the docs so they're documented alongside the generated ones? Merging hand-written surface into generated docs is being built into Forge. See concepts/machine-readable-documentation.

API versioning without breaking clients

Forge is the foundation for Cloudflare's forthcoming major-version API evolution approach. The v4 API has been the single major version for 10 years; by SemVer they've shipped many breaking-worthy changes without a bump, and several operations still carry stale internal v2/beta tags. A big-bang v5 "would leave a lot of our customers behind," so — with Forge releasing artifacts along the way — they're building "an API versioning approach that allows us to release new major API versions without breaking old clients or SDKs." Terraform gets "extra special care" given upgrade rigor. See concepts/schema-evolution and concepts/backward-compatibility.

Licensing / availability

Open source under Apache 2.0 (github.com/cloudflare/forge). Deployable and runnable by anyone for free — including privately, with custom modifications. The thesis: agents are now customers of every product, so CLIs / SDKs / MCP servers / docs are "table stakes for every product," and "building tools for APIs is a core part of the Internet, and you should be able to do that without needing a SaaS product."

Caveats

  • Early / roadmap-heavy. Only the cf CLI generation is confirmed shipped; docs, multi-language SDKs, and the broader target list are near-term roadmap.
  • Only OpenAPI input is live today; AsyncAPI / GraphQL / Cap'n Proto / Protobuf are design-for.
  • Cap'n Web / MCP / TanStack / Zod outputs beyond the cf CLI are illustrative of the extensibility model, not confirmed shipped generators.
  • No CI build-time, preview-generation latency, or per-PR volume numbers are given.
  • API-versioning scheme is stated intent, not a disclosed mechanism.

Seen in

Last updated · 766 distilled / 2,225 read