Gestionar variables sensibles en múltiples workers puede convertirse en un dolor de cabeza cuando necesitas rotar una API key y tienes diez proyectos conectados a ella. Cloudflare ofrece herramientas específicas para centralizar, proteger y compartir secretos de forma eficiente, y además pone a disposición mecanismos como waitUntil para ejecutar tareas en segundo plano sin bloquear la respuesta de tu API.
¿Cómo se administran los secretos en un worker de Cloudflare?
Desde la interfaz de Cloudflare puedes ver que un backend o API ya tiene secretos cargados [0:08]. Al tratarse de secrets, no es posible ver su valor, solo rotarlo o agregar nuevos. También puedes gestionarlos desde la terminal con comandos del CLI, siempre que ya estés autenticado con tu cuenta de Cloudflare.
En el archivo README del proyecto se documentan los comandos necesarios. Basta con entrar a la carpeta del backend y ejecutar el comando correspondiente [0:42]. Estos son considerados secretos primitivos: están ligados exclusivamente a un worker específico.
¿Qué es Secrets Store y por qué centralizar tus secrets?
Secrets Store es un servicio disponible en el apartado de Storage and Database de Cloudflare [1:06]. Su propósito es centralizar variables sensibles que se usan en varios workers al mismo tiempo.
- Si tienes 10 workers conectados a la misma clave de OpenAI, ya no necesitas hacer 10 deployments para rotarla.
- Rotas el secreto una sola vez y Cloudflare actualiza todos los workers vinculados automáticamente.
En la práctica, se creó un secreto para almacenar la API key de Resend [2:04], un servicio sencillo para enviar correos electrónicos en modo desarrollador. Se registró en Secrets Store con un comentario descriptivo y el estatus pasó de Pending a Active.
¿Cómo se declaran los secrets requeridos en el archivo wrangler?
El archivo wrangler (referido en la clase como "Grangler") permite especificar qué secrets son obligatorios para que el worker funcione [2:30]. Esto bloquea el deployment si falta algún secreto requerido, evitando errores en producción.
- Existe un archivo
.dev.vars con valores para el entorno local.
- En producción se asignan valores diferentes, por ejemplo la URL exacta del frontend para la variable de CORS.
- El binding del Secrets Store incluye el nombre del binding, el nombre del secreto y el store ID, que los MCPs obtienen automáticamente al autenticarse [3:18].
¿Qué es waitUntil y cómo ejecutar tareas en segundo plano?
Cuando se agregó el servicio de envío de emails, en lugar de enviar el correo directamente y esperar la respuesta, se utilizó waitUntil [4:22]. Esta propiedad está disponible dentro del contexto de ejecución del worker y permite lanzar operaciones en segundo plano.
- La API no necesita esperar a que el servicio de correos responda para devolver su resultado al cliente.
- El límite principal: las operaciones ejecutadas con waitUntil deben completarse en máximo 30 segundos [4:52].
- Si una tarea puede superar ese tiempo, waitUntil no es la herramienta adecuada.
El impacto en rendimiento es significativo. Una API que ejecuta múltiples operaciones en primer plano podría tardar dos o tres segundos, pero al moverlas a segundo plano con waitUntil, el tiempo de respuesta puede bajar a 50 o 100 milisegundos [5:18].
¿Cómo funciona un binding en Cloudflare Workers?
Un binding es la forma en que Cloudflare conecta recursos externos a un worker sin necesidad de credenciales ni tokens explícitos en el código [6:28]. En el archivo wrangler se declara:
- El nombre del binding: cómo tu código accede al recurso.
- El nombre del secret: cómo está registrado en Secrets Store.
- El ID del store: identificador del almacén en Cloudflare.
A diferencia de un secreto primitivo aislado, el binding apunta a un recurso compartido. No hay tokens hardcodeados; Cloudflare gestiona la conexión internamente. Esto se verifica tanto en el código como en la interfaz visual del panel.
Para probar la funcionalidad, se utilizó el ambiente de preview y se envió un correo de prueba [5:52]. El resultado confirmó la recepción exitosa del email con el mensaje esperado. Tras validar, se hizo merge del pull request y el monorepo compiló tanto la API como el frontend.
Si ya estás trabajando con workers, te invito a compartir cómo gestionas tus secretos y si has probado Secrets Store en tus proyectos.
