Cloudflare lanza Forge, el pipeline open source para SDKs y CLIs

Qué es Forge y por qué Cloudflare lo libera ahora

Cloudflare presentó Forge, un pipeline open source bajo licencia Apache 2.0 para generar automáticamente SDKs, CLIs, documentación y otras «superficies» que un producto expone hacia desarrolladores y agentes de IA. El comunicado oficial lo describe como un sistema «pluggable» que cualquiera puede desplegar y correr gratis, sin ataduras a un SaaS.

La motivación principal es pragmática: la API de Cloudflare supera las 3.500 operaciones repartidas entre cientos de servicios escritos en Rust, Go, TypeScript y Python. Coordinar SDKs, CLIs y docs a esa escala con generadores hosted se había vuelto, en sus palabras, «nadar contracorriente» — un equipo rompía el pipeline y otro lo descubría al momento del release. Forge corre dentro del CI de cada repositorio, hace lint de cada cambio y produce preview builds con los diffs resaltados, replicando para generación de SDKs lo que Workers Previews ya hace para código de aplicaciones.

El timing no parece casual. Días antes, según reportó ADTMag, Google y Speakeasy habían anunciado su propio generador open source tras el cierre abrupto del proveedor comercial que Google usaba para los SDKs de Gemini. Google reconoció que esa dependencia les retrasó la GA de su Interactions API y dijo, textual: «la tooling para compilar interfaces en client libraries, CLIs y agent tools debería ser open infrastructure». El mensaje de Forge apunta exactamente al mismo lugar.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Qué problema resuelve para los builders

Hoy cualquier producto medianamente serio necesita varios frentes bien mantenidos:

SDKs idiomáticos en varios lenguajes (TypeScript, Python, Go, Java, C#, PHP, Ruby, Rust…)
CLIs con comandos a veces escritos a mano (deploy, build, dev) que no salen de ningún spec
Docs que reflejen el estado real de la API
Servidores MCP para que agentes de IA descubran y llamen a la API
Schemas de validación (Zod, Valibot) y bindings a librerías como TanStack Query

La comparación publicada por Speakeasy en abril de 2026 mapea el mercado actual: cinco generadores dominantes —Speakeasy, Stainless, Fern, APIMatic y OpenAPI Generator— con diferencias notables en cobertura de lenguajes, runtime type safety, footprint de dependencias y modelo de despliegue. Stainless (que hoy genera los SDKs oficiales de OpenAI, Anthropic y Cloudflare) requiere conectividad a su cloud; Fern (adquirido por Postman en enero de 2026 según la misma comparativa) usa un DSL propietario; OpenAPI Generator tiene más de 50 lenguajes pero más de 4.500 issues abiertos y suele requerir varios ingenieros manteniendo forks internos. Precios comerciales arrancan en US$250/mes por SDK en varios de ellos.

Forge entra a competir justamente en el hueco que esos productos no cierran: pluggability real y chaining de transformaciones, ejecutándose en tu propio CI.

Las decisiones técnicas que diferencian a Forge

Transformers encadenables. Forge está pensado para que la salida de un target alimente a otro. El ejemplo canónico: en muchos generadores el CLI y el provider de Terraform se producen a partir del SDK de Go. Forge deja al usuario controlar quién genera qué a partir de qué — por eso el CLI de Cloudflare (cf) está escrito en TypeScript y aún así puede ser output final de un pipeline que arrancó en OpenAPI.

Cap’n Web como target. El RPC de Cloudflare para que TypeScript llame a una API remota como si fuera código local. Forge permite generar bindings de Cap’n Web desde un OpenAPI, lo que abre la puerta a bindings entre Workers y APIs externas — útil porque los bindings de Workers son, técnicamente, Workers que exponen métodos RPC.

Inputs y outputs extensibles. Hoy soporta OpenAPI; el diseño contempla AsyncAPI, GraphQL, Cap’n Proto y Protobuf como futuros inputs. Como outputs, además de SDKs y docs, se pueden generar paquetes específicos por librería o incluso dashboards.

Versionado de API pensado para no romper a los clientes. La API v4 de Cloudflare lleva 10 años como versión mayor única, y el post adelanta un esquema que permitiría releases de nuevas versiones mayores sin romper SDKs viejos — un dolor clásico que cualquier founder con una API pública reconoce.

Preview por PR, no por release. Cada cambio en una API genera un preview instalable del CLI/SDK/docs sólo con ese cambio. Es el modelo «preview per change» que Cloudflare ya aplicaba en Workers, llevado al mundo de la generación de SDKs.

Qué significa esto para tu startup

Si sos founder técnico y vendés una API, esta movida te toca de cerca. Tres implicancias concretas:

El lock-in con generadores hosted se está rompiendo. El discurso de Google y Cloudflare en pocas semanas dice lo mismo en distintos tonos: la infraestructura que produce tus SDKs no debería ser una caja negra SaaS. Forge (Apache 2.0) y la suite Google-Speakeasy (AGPLv3, con opción comercial de Speakeasy) cubren dos perfiles distintos del mismo problema.
MCP servers pasan a ser un output de primera clase. Tanto Forge como la suite Google-Speakeasy generan servidores MCP desde OpenAPI. Si tu producto va a ser consumido por agentes de IA, este es el momento de planificar un MCP server y tratarlo con la misma seriedad que tu SDK de TypeScript.
El coste de mantener SDKs cae, pero no a cero. Speakeasy estima que el pipeline de Google requiere «roughly one engineer» donde antes hacían falta varios para SDKs artesanales. Para una startup hispana con API pública eso es la diferencia entre tener SDK en dos lenguajes o en seis.

Acciones concretas que podés tomar esta semana

Auditá tu generación actual. Si dependés de Stainless, Fern, Speakeasy hosted o un fork interno de OpenAPI Generator, mapeá qué pasa si ese proveedor cambia de precio, se vende o cierra. El caso de Google — retraso de GA incluido— es el antecedente más reciente.
Probá Forge sobre tu OpenAPI real. El repo abierto bajo Apache 2.0 permite correrlo en tu CI. Aunque no lo adoptes hoy, el ejercicio te sirve para entender qué partes de tu pipeline son genuinamente reemplazables.
Agregá MCP a tu roadmap. Tanto Forge como Google-Speakeasy apuntan a MCP como output estándar. Un servidor MCP mal documentado hoy es un agente que mañana va a ignorar tu API.

El contexto que no se ve en el comunicado

La decisión de Cloudflare de abrir Forge llega en un momento en que la infraestructura para agentes de IA se está consolidando como una capa nueva del stack. Hasta hace poco, sólo los productos «developer-first» necesitaban CLIs, SDKs y docs impecables. El post lo dice sin rodeos: ahora esas superficies son table stakes para cualquier producto, porque el siguiente cliente puede ser un agente, no un humano frente a un navegador.

Hay también una lectura geopolítica. Investigadores de Novee Security documentaron en junio de 2026 que Cloudflare Workers SDK (la base sobre la que corre Wrangler) fue uno de los repositorios afectados por la clase de fallos CI/CD bautizada Cordyceps — un patrón que permitió ejecución de código arbitrario a usuarios sin autenticar en repos de Microsoft, Google, Apache y la Python Software Foundation. Cloudflare acreditó el reporte y aplicó hardening. En ese contexto, que la propia Cloudflare ahora impulse un generador open source ejecutándose dentro del CI del cliente, en lugar de un SaaS opaco, también es una apuesta por reducir superficie de ataque.

Para founders hispanos, el movimiento abre una puerta interesante: la barrera para mantener SDKs de calidad en español, con docs que reflejen la realidad de la API y sin pagar licencias recurrentes, es la más baja en años. La pregunta ya no es si podés generar un SDK en seis lenguajes — Forge y la suite Google-Speakeasy dicen que sí — sino cuánto tardás en ponerlos en producción.