OpenOrange: Cloudflare Workers en tu nube, 4,8× más barato

OpenOrange promete correr tus Cloudflare Workers donde tú decidas —AWS, Google Cloud, Azure, un clúster de Rivet o tus propios servidores— con una factura hasta 45,4× menor en algunos medidores. La herramienta, mantenida por Rivet y publicada bajo licencia Apache 2.0, cambia la capa de plataforma de Cloudflare por Node.js con SQLite real, y asegura que puede migrar tus Durable Objects sin cortar el servicio. Para un founder con agentes de IA o workflows corriendo 24/7, la pregunta dejó de ser si el edge es elegante: es cuánto cuesta cada GB-hora.

El detalle que más pesa en la decisión: no cambias tu código. El CLI orange lee tu wrangler.jsonc y tus bindings, entornos, comandos de build y .dev.vars siguen funcionando igual.

¿Qué es OpenOrange y en qué se diferencia de Cloudflare?

OpenOrange no es un fork de Cloudflare ni una copia de su runtime. Implementa la API de Workers sobre Node.js y mapea cada servicio de Cloudflare —KV, D1, R2, Queues, Workflows— sobre Rivet, que aporta la capa de actores y almacenamiento. Según su propia documentación, usa Wrangler para leer la configuración y reutiliza código de Cloudflare con licencia MIT, como el motor de Workflows, pero no ejecuta workerd.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

La diferencia con autoalojar workerd es exactamente esa capa. Como reportó XDA Developers al probar el runtime de código abierto de Cloudflare, con workerd el desarrollador obtiene el runtime y nada más: KV, D1, R2, Queues, Workflows y la Cache API son bindings que llaman a servicios que hay que construir aparte, y los Durable Objects mantienen sus datos en una sola máquina sin nada que los coloque, replique o escale.

OpenOrange tampoco obliga a aprender Rivet. La empresa lo describe como el plano de control que queda debajo: tú sigues usando el CLI orange y tu configuración de Wrangler.

¿Cuánto más barato sale correr tus Workers en tu propia nube?

Aquí está el corazón del lanzamiento. OpenOrange publica una tabla que compara precios de lista de Cloudflare contra precios on-demand de AWS Graviton en us-east-1, aprovisionando 40% por encima del uso real para autoscaling. Los precios se verificaron el 8 de octubre de 2026 y el resultado, según esa comparativa, es:

Durable Object compute: US$0,045 por GB-hora en Cloudflare contra US$0,0094 — 4,8× menos.
Escrituras SQLite: US$1,00 contra US$0,18 por millón de filas — 5,7× menos.
D1: US$0,75 contra US$0,023 por GB-mes — 32,6× menos.
Escrituras de KV: US$5,00 contra US$0,18 por millón — 28,4× menos.
Pasos de Workflows: US$8,00 contra US$0,18 por millón — 45,4× menos.
Mensajes de Queues: US$1,20 contra US$0,35 por millón — 3,4× menos.
CPU de Workers: US$0,072 contra US$0,051 por vCPU-hora — 1,4× menos, y sin tarifa por request.

Rivet respalda la parte de escrituras con una medición propia: 5.000 agentes concurrentes, cada uno haciendo un upsert de 64 bytes en SQLite cada 10 segundos, generaron 1.320 millones de escrituras al mes por US$232 en requests a S3.

Hay dos líneas más que un CFO mira con atención. La primera es el egress: el tráfico dentro de tu VPC es gratis, mientras que cada llamada desde Cloudflare hacia tu base de datos o tus APIs en AWS paga egress a US$0,09 por GB. La segunda son los créditos: AWS, Google y Azure permiten pagar OpenOrange con créditos y compromisos de gasto, algo que Cloudflare no acepta porque es una segunda factura.

OpenOrange también reconoce cuándo no conviene moverse. Para Workers pequeños y esporádicos, Cloudflare suele ser más barato: el free tier y el precio por request son difíciles de superar. Los medidores empiezan a doler cuando los Durable Objects pasan mucho tiempo activos y cuando el volumen de filas escritas en SQLite crece.

¿Qué límites de Cloudflare desaparecen cuando corres en tu infraestructura?

El argumento técnico es tan importante como el económico. Un Worker de Cloudflare tiene 128 MB de memoria disponible. OpenOrange corre tus Workers y Durable Objects sobre máquinas que tú eliges, así que los límites pasan a ser los del hardware. La comparación que publica la compañía:

Memoria por Worker o Durable Object: de 128 MB a la memoria de tu máquina, con un heap de Node.js de hasta unos 4 GB por defecto y configurable.
Tiempo de CPU por request: de 30 segundos por defecto (5 minutos máximo) a sin tope.
Handlers de cron, colas y alarmas: de 15 minutos de wall time a sin tope.
Conexiones abiertas por request: de 6 simultáneas a los límites del sistema operativo.
Almacenamiento por Durable Object: de 10 GB a sin tope.
Bundle del Worker: de 64 MiB a sin tope.
Node.js: del subconjunto nodejs_compat a Node.js estándar.

El subconjunto de compatibilidad es un detalle que muchos equipos descubren tarde: si tu Worker depende de un módulo nativo de npm, en Cloudflare no arranca. Con Node.js estándar, sí.

¿Cómo migras sin cortar el servicio?

El proceso que describe la compañía tiene cinco pasos y no exige ventana de mantenimiento. Primero, todo el tráfico sigue en Cloudflare. Segundo, el registro DNS pasa a apuntar a OpenOrange. Tercero, cada Durable Object se copia la primera vez que se solicita y a partir de ahí se sirve desde la nueva infraestructura. Cuarto, un job de backfill copia el resto. Quinto, cada request corre en OpenOrange con la aplicación siempre arriba.

La letra chica importa: Cloudflare no ofrece una forma de migrar D1 en vivo, así que las peticiones a esa base se interrumpen unos minutos mientras se copian los datos. Para R2 el camino es distinto, porque es compatible con S3 y se mueve con rclone o aws s3 sync.

¿Qué no está listo todavía?

Antes de planificar la migración, revisa qué bindings usas. Vectorize, Images, Pipelines y certificados mTLS aún no están implementados: cargan, pero cada llamada lanza un error que nombra el binding.

El otro punto abierto es la geografía. OpenOrange corre donde lo despliegues y en tantas regiones como quieras, pero para Durable Objects una actualización próxima de Rivet añadirá soporte multi-región, incluidas regiones de edge. Hoy, para objetos con estado, la apuesta es correr junto a la base de datos en lugar de en el borde.

¿Qué significa esto para tu startup?

La decisión no se toma con el titular de 4,8×, sino con tu factura. Estas son las acciones concretas:

Haz el cálculo con tus propios números. Toma los GB-hora de Durable Objects y el millón de filas escritas del último mes y aplícales US$0,0094 y US$0,18. Si tu gasto está concentrado en duración y escrituras, la migración tiene sentido económico. Si está concentrado en requests, probablemente no.
Prueba en local y en dry-run antes de tocar producción. orange dev levanta tu Worker en segundos y orange deploy --dry-run no construye ni envía nada a Rivet Cloud: es la forma más barata de saber si tus bindings sobreviven.
Elige el modelo de despliegue según tu realidad fiscal. Self-hosted con Apache 2.0 y Rivet propio significa que tu factura de nube es la única factura. BYOC opera Rivet sobre tu cuenta de AWS, Google Cloud o Azure, y sirve si tienes créditos o gasto comprometido. Rivet Cloud es la vía gestionada.
Documenta tu dependencia de bindings no soportados. Si tu producto vive de Vectorize o de Images, moverte hoy es prematuro; mejor esperar a que esa lista se acorte.

Conclusión

OpenOrange no compite por tener el edge más elegante, compite por la factura de quien corre cargas con estado de forma sostenida. La tesis es simple: la mayoría de los backends hablan con una sola base de datos, y correr al lado de esa base es más rápido y más barato que correr en el borde. El propio Cloudflare es consciente de las tensiones de su arquitectura: como recordó InfoQ, tras la caída global de Google Cloud del 12 de junio de 2025 rediseñó Workers KV con una arquitectura híbrida y bajó la latencia p99 de lectura de 200 ms a menos de 5 ms.

Para un founder hispanohablante con un SaaS que ya factura, la lectura práctica es esta: el serverless dejó de ser una decisión binaria. Puedes quedarte con la experiencia de desarrollo de Workers y elegir dónde corre el cómputo. Lo que conviene hacer ahora no es migrar por reflejo, sino abrir la factura del último mes, correr los números con los precios publicados y decidir con datos. Si tu carga es esporádica, Cloudflare sigue ganando; si tienes agentes y workflows encendidos todo el día, la conversación es otra.