Recorrido por Void Platform: instalar una plataforma compartida de despliegue en Cloudflare

Configurar infraestructura compartida de despliegue es fácil de posponer, hasta que tres desarrolladores publican cada uno en su propia cuenta de Cloudflare y nadie puede revertir la misma versión. Un recorrido por Void Platform lo soluciona convirtiendo una ambición vaga de "deberíamos autoalojarlo" en una lista de verificación ordenada. A continuación encontrarás un recorrido práctico por Void Platform que cubre qué es realmente la plataforma, qué credenciales reunir primero, cómo se secuencia la instalación del núcleo y qué servicios opcionales suelen añadir los equipos más adelante.

La mayor parte de la confusión en torno a este producto proviene de una única bifurcación en el camino: desplegar para ti mismo frente a desplegar para un equipo. Si publicas tu propia aplicación, despliegas directamente en Cloudflare y nunca tocas una instalación de plataforma. Si eres el administrador que levanta infraestructura compartida, la plataforma se convierte en aquello que instalas, mantienes y entregas mediante una URL. Todo lo que sigue asume que estás en ese segundo grupo.

Qué hace realmente una Void Platform

Una plataforma Void permite que un equipo despliegue aplicaciones en una cuenta compartida de Cloudflare. Esa única frase concentra la mayor parte del valor: en lugar de que cada desarrollador configure su propia cuenta, tokens y gateway, el administrador instala y mantiene una sola plataforma. Los desarrolladores entonces apuntan el Void CLI a su URL, inician sesión mediante un método de inicio de sesión habilitado y despliegan.

La plataforma no es un producto de alojamiento separado. Ambos destinos de despliegue usan las mismas APIs de aplicación, así que una app no necesita reescribirse para pasar de un despliegue directo en Cloudflare a una plataforma de equipo. Lo que añade la plataforma es acceso compartido más historial de despliegues conservado: dos cosas que importan enormemente en cuanto más de una persona publica código.

La división importa porque define tu trabajo. Durante la instalación eres el administrador, no un desarrollador. Tu métrica de éxito no es "mi app está en vivo", sino "un compañero de equipo al que nunca he conocido puede autenticarse y desplegar sin escribirme".

Requisitos previos y credenciales que reunir primero

La forma más rápida de atascar un recorrido por Void Platform es descubrir a mitad de camino que te falta un nivel de plan o un permiso de cuenta. La guía oficial de instalación de la plataforma autoalojada Void divide esto en requisitos previos y credenciales por una buena razón: son decisiones separadas con responsables separados.

Trabaja la siguiente lista antes de tocar el instalador. Cada fila es algo que deberías poder responder con un nombre, no con un encogimiento de hombros.

Dos de estos se subestiman con frecuencia. El primero es la elección de cuenta: migrar una plataforma más adelante es mucho más doloroso que elegir una cuenta dedicada desde el principio. El segundo es el método de inicio de sesión: no es una idea de última hora posterior a la instalación, es la puerta por la que pasa cada desarrollador.

El recorrido por Void Platform, paso a paso

La secuencia siguiente sigue las guías de instalación en orden, desde los requisitos previos pasando por las credenciales hasta la instalación del núcleo. Trata cada paso como una puerta: no avances hasta que la columna "hecho" sea genuinamente cierta.

Pasos 1–3: alcance, requisitos previos, credenciales

Empieza anotando la respuesta a una pregunta directa: ¿esta plataforma es para una persona o para un equipo? Si es para una persona, detente: despliega directamente en Cloudflare en su lugar. Si es para un equipo, la respuesta te compromete con Workers for Platforms y la infraestructura documentada, así que presupuesta eso antes de programar cualquier ventana de instalación.

Pasos 4–5: instalar el núcleo y activar el correo

La instalación del núcleo incluye Sandboxes gestionados y un gateway de correo. El correo no se pone en marcha por sí solo; se habilita cuando configuras un dominio de correo compartido y una zona. Si el correo transaccional desde las apps desplegadas forma parte de tu plan, trátalo como un paso obligatorio en lugar de un extra agradable, y verifícalo con un envío real antes de invitar a los desarrolladores.

Pasos 6–8: autenticación, primer despliegue y la hoja de ruta

Habilita un método de inicio de sesión, entrega la URL de la plataforma a un desarrollador piloto y haz que conecte el Void CLI y despliegue algo pequeño. Esa única prueba revela más problemas de configuración que cualquier lista de verificación. Una vez que pase, anota los servicios opcionales que estás aplazando —builds de GitHub, Build Containers, dominios de proyecto personalizados— para que nadie asuma que se incluyeron con el núcleo.

Cloudflare directo vs. la plataforma autoalojada del núcleo

Esta es la tabla comparativa que vale la pena guardar, porque responde a "¿qué estoy ganando realmente?". Ambos destinos comparten las mismas APIs de aplicación; las diferencias tienen que ver con el acceso compartido, la retención y por dónde fluyen las solicitudes.

Lee con atención las dos últimas filas. Los Sandboxes en la plataforma solo necesitan Workers Paid en la cuenta de la plataforma, mientras que el despliegue directo también espera Docker en tu flujo de trabajo local. Y el panel más los builds gestionados de GitHub no forman parte de una instalación estándar en ninguno de los dos lados: son añadidos que eliges.

Para un proyecto en solitario, la columna izquierda es menos trabajo para las mismas APIs de aplicación. Para un equipo, los registros conservados y los despliegues conservados de la columna derecha son lo que hace posible depurar una versión compartida.

Servicios opcionales y trampas de configuración

Una vez que tu recorrido por Void Platform supera la instalación del núcleo, el trabajo restante es optativo, pero cada opción tiene una consecuencia de configuración. Planifícalas deliberadamente en lugar de descubrirlas cuando un desarrollador pregunta por qué falta su vista previa de rama.

Dos hábitos previenen la mayoría de estos casos. Primero, mantén un registro breve de configuración: qué métodos de inicio de sesión están habilitados, qué dominio de correo es compartido y qué servicios opcionales están activos. Segundo, cuando Cloudflare Access protege la API y ejecutas una plataforma construida desde código fuente con servicios de GitHub, sigue la configuración de ingreso aislado de webhooks en lugar de relajar Access: la solución pertenece a la ruta de ingreso, no a tu postura de seguridad.

Por último, recuerda que una plataforma de equipo depende de su configuración. Las funciones documentadas para una instalación pueden estar ausentes en la tuya simplemente porque no se habilitaron, así que verifica contra tu propia configuración en lugar de asumir un valor por defecto.

Preguntas frecuentes

¿Necesito un recorrido por Void Platform si solo despliego mi propia app? No. Si estás desplegando una app para ti mismo, despliega directamente en Cloudflare. Instalar una plataforma solo vale la pena por la sobrecarga cuando un equipo necesita acceso compartido e historial de despliegues conservado.

¿El panel de usuario está incluido en una instalación estándar? No. El panel de usuario, los builds y webhooks gestionados de GitHub, los Build Containers y los dominios de proyecto personalizados no forman parte de la instalación del núcleo. Planifícalos como añadidos separados.

¿Qué necesita la cuenta de la plataforma para ejecutar Sandboxes? Workers Paid en la cuenta de la plataforma. El despliegue directo en Cloudflare tiene un requisito ligeramente distinto y también espera Docker para los Sandboxes.

¿Podemos añadir builds de GitHub después de la instalación del núcleo? Sí: es un servicio opcional. Si estás en una plataforma construida desde código fuente y Cloudflare Access protege la API, configura el ingreso aislado de webhooks para que los builds y webhooks sigan funcionando sin debilitar el control de acceso.