Cloudflare ha publicado Void, un conjunto de tres piezas de código abierto (SDK, CLI y plataforma de despliegue) para construir apps full-stack con Vite y ejecutarlas en Workers. El anuncio es del 15 de octubre de 2026 y el repositorio, bajo licencia MIT, tenía 287 estrellas al consultarlo hoy: es un proyecto joven, no una apuesta consolidada.
Qué cambia
Void se instala como un único paquete de npm y un plugin de Vite (npm install void). Se reparte en tres partes:
- Void SDK: enrutamiento de API por ficheros, prerenderizado, caché y tipos de extremo a extremo desde la base de datos hasta la interfaz. Importar
void/dbda una base de datos local en desarrollo y aprovisiona D1 en producción;void/aiconfigura el acceso a IA a través de AI Gateway. - Void CLI: se apoya en la nueva CLI
cfde Cloudflare.void deploycompila con Vite, aplica migraciones, aprovisiona recursos y despliega;void connect <url>apunta la CLI a una plataforma propia. - Void Platform: una plataforma de despliegue compartida que un equipo puede alojar en su propia cuenta de Cloudflare sobre Workers for Platforms. Gestiona usuarios, accesos a proyectos, recursos, despliegues, logs, rollbacks y monitorización.
Según el anuncio, la idea original era una plataforma privada y, tras la incorporación de VoidZero a Cloudflare, pasó a ser abierta e instalable por cualquiera. Se integra con frameworks existentes (React Router, SvelteKit, Nuxt, TanStack Start, Astro, entre otros) y usa Hono, Better Auth y migraciones.
El plugin se declara así:
import { defineConfig } from "vite";
import { voidPlugin } from "void";
import { voidReact } from "@void/react/plugin";
export default defineConfig({
plugins: [voidPlugin(), voidReact()],
});Por qué importa en producción
El caso de uso que plantea Cloudflare es concreto: equipos donde los empleados, con ayuda de agentes de IA, crean aplicaciones internas, y la empresa no quiere darles acceso a la cuenta cloud. La plataforma pone una capa intermedia: la gente despliega con void deploy contra la plataforma de la empresa y no contra Cloudflare directamente, y el equipo de plataforma conserva los permisos, los logs y los rollbacks.
Para quien opera, eso es interesante y a la vez una responsabilidad. Alojar la plataforma exige una cuenta de Cloudflare con Workers for Platforms y R2 habilitados, una base de datos PostgreSQL, un proveedor de login y un dominio para las apps. Es decir, otro servicio más que mantener, parchear y vigilar. Además, el despliegue y el aprovisionamiento están pensados para Cloudflare; el artículo habla de adaptarlo a otros proveedores pero no explica cómo. Y no documenta precios, cuotas ni versiones soportadas.
Qué haría yo
- Probar solo el SDK y la CLI en un proyecto de prueba, desplegando directo a Cloudflare, antes de plantearme la plataforma.
- Revisar cómo gestiona los permisos de la cuenta de Cloudflare y qué puede hacer cada usuario de la plataforma.
- Si el objetivo son apps internas hechas con agentes, definir de antemano límites de recursos y un proceso de baja, porque el artículo no cuenta cómo se limitan.
- Esperar a ver releases etiquetadas: el repositorio no muestra ninguna versión publicada.