GitHub publicó el 21 de agosto los cambios que aplicará tras el apagón del 17 de agosto, Vue.js llegó a la quinta candidata de la serie 3.6 con Vapor Mode, Prisma sumó su quinta candidata de la versión 8, SvelteKit publicó una nueva vista previa de su serie 3, y Cloudflare workerd llegó a once días consecutivos de lanzamientos, personaje de la semana en esta sección.
GitHub publicó, el 21 de agosto de 2026, una entrada de blog firmada por su director de tecnología, Vladimir Fedorov, titulada "The August 17 outage, and the work ahead", según el sitio oficial de la compañía. El texto detalla las causas del apagón del 17 de agosto, que dejó fuera de servicio GitHub.com, Actions, Copilot, la API y el sistema de autenticación durante 7 horas y 47 minutos, con tasas de error cercanas al 20% en tráfico web y de API y de hasta el 50% en descargas de archivos comprimidos y contenido crudo de repositorios, según cifras de la compañía recogidas por el medio especializado The Register. "Si usted estaba tratando de lanzar software ese día, le fallamos", escribió Fedorov, según la misma entrada. La causa raíz, detalla el texto, no fue un cambio de código: los proxies de Istio que median la comunicación entre servicios internos alcanzaron su límite de procesamiento durante un pico de tráfico récord, pero la política de autoescalado vigilaba la carga del servidor anfitrión y no la concurrencia del propio proxy, por lo que no se activó capacidad adicional a tiempo; la escasez se propagó después a los balanceadores HAProxy que atienden la autenticación, y un error en Visual Studio Code que generó una tormenta de reintentos alargó la recuperación, según el mismo relato. Es la segunda vez en el año que GitHub promete resolver sus problemas de capacidad con el mismo lenguaje: los tres frentes que Fedorov describe hoy —agregar capacidad, mejorar eficiencia y remover cuellos de botella arquitectónicos— son los mismos que la compañía había anunciado a comienzos de 2026 como parte de un compromiso de confiabilidad, bajo el cual ya había sumado más de 3 millones de núcleos de CPU y 120 petabytes de almacenamiento de alta velocidad antes de este apagón, según la misma entrada. Que la falla haya ocurrido de todas formas matiza la eficacia de esa inversión previa: los commits mensuales en la plataforma pasaron de 1.400 millones en abril a 2.900 millones en agosto, y GitHub admite que ese crecimiento explica la presión sobre el sistema pero no excusa el resultado. La dependencia de millones de equipos de desarrollo en la nube de una sola plataforma centralizada vuelve cada apagón de GitHub un evento con efecto de cascada sobre flujos de integración continua en todo el mundo, no solo sobre el sitio web. Como próximos pasos, GitHub dijo que aplicará límites de reintento, presupuestos de reintento y tiempos de espera variables consistentes entre servicios internos para evitar tormentas de reintentos como la que alargó el apagón de agosto, y que revisará las alertas de CPU y memoria de baja prioridad para detectar componentes que podrían fallar ante picos súbitos. El próximo hito, según Fedorov, es una arquitectura que escale la capacidad de lectura de forma lineal con el número de lectores, que la compañía empezará a desplegar de forma gradual en los monorepositorios más grandes, sin fecha de finalización anunciada. Costa Rica no publica cifras propias de uso de GitHub, pero la plataforma aloja el código de la mayoría de equipos de desarrollo locales, desde bootcamps hasta bancos y empresas de zonas francas tecnológicas, para quienes un apagón de casi ocho horas en Actions o en la API interrumpe directamente sus propios flujos de integración y despliegue.
La quinta candidata de lanzamiento, publicada el 21 de agosto, continúa el pulido del nuevo modo de compilación que promete paquetes más livianos sin el árbol de nodos virtuales que usa Vue desde su primera versión.
El equipo de Vue.js publicó, el 21 de agosto de 2026, la versión 3.6.0-rc.5, quinta candidata de lanzamiento de la serie 3.6 del framework, según el registro oficial de lanzamientos del proyecto en GitHub. Es la quinta candidata desde que el equipo abrió el ciclo de pruebas de la 3.6 el 18 de julio con la rc.1, la primera en incorporar Vapor Mode: un modo de compilación alternativo para los componentes de archivo único (SFC) de Vue que, según la nota de esa versión, busca reducir el tamaño base de los paquetes generados y mejorar el rendimiento al prescindir del árbol de nodos virtuales (virtual DOM) que el framework usa por defecto desde su creación. El registro de cambios de la rc.5, igual que el de las dos candidatas anteriores (rc.3 del 11 de agosto y rc.4 del 14 de agosto), se limita a correcciones puntuales sobre el trabajo de Vapor Mode, sin agregar funciones nuevas, según el mismo repositorio. Renunciar al árbol de nodos virtuales en el código compilado es una apuesta estructural, no cosmética: Vue comparte esa arquitectura con React desde hace más de una década, mientras que frameworks como Svelte la evitan por completo desde su diseño original compilando directamente a manipulaciones del DOM. Que el proyecto más establecido de los tres se mueva hacia un modelo sin virtual DOM, manteniendo el modo clásico como opción, reconoce que buena parte de la ventaja de rendimiento que Svelte reclama frente a Vue y React viene precisamente de esa decisión arquitectónica. Cinco candidatas en poco más de un mes, con una cadencia semanal, muestran una iteración activa, pero el equipo todavía no ha anunciado fecha para la versión estable de la 3.6, y bibliotecas del ecosistema que dependen de manipular directamente el árbol virtual de Vue podrían necesitar ajustes para funcionar bajo Vapor Mode. La información de esta nota proviene únicamente del registro oficial de lanzamientos de Vue.js en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Vue, pero el framework es una opción habitual entre agencias y startups locales que construyen interfaces web, a las que conviene tratar la serie 3.6.0-rc todavía como vista previa y esperar la versión estable —sin fecha confirmada— antes de adoptar Vapor Mode en producción.
El equipo de Prisma publicó, el 22 de agosto de 2026, la versión 8.0.0-rc.5 del ORM, según el registro oficial de lanzamientos del proyecto en GitHub. La actualización unifica las rutas de comando del CLI —la familia de comandos "prisma orm" pasa a usar directamente las rutas del CLI unificado en lugar de mantener un mapeo aparte—, corrige una pérdida de estabilidad en el motor de ejecución sobre PostgreSQL que provocaba conexiones caídas, y hace que las funciones de agregación respeten correctamente las cadenas de consultas encadenadas, según el mismo registro de cambios. La rc.5 llega cuatro días después de la rc.4, publicada el 18 de agosto, que cerró el período de transición de la configuración obsoleta: el CLI dejó de leer el archivo prisma-next.config.ts que había servido como puente durante el desarrollo de la versión 8. Que una candidata de lanzamiento número cinco todavía corrija una pérdida de conexiones en el motor de PostgreSQL —no una función menor, sino el comportamiento base de mantener una conexión abierta a la base de datos— matiza la cercanía de esta rama a una versión estable: cinco iteraciones sucesivas sugieren un proceso de estabilización activo, pero también que la versión 8 todavía no está lista para cargas de producción que dependan de conexiones persistentes. El proyecto no ha publicado, en el registro de cambios consultado para esta nota, una fecha estimada para la versión estable de la 8.0.0. La información de esta nota proviene únicamente del registro oficial de lanzamientos de Prisma en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Prisma, pero el ORM es una opción común entre startups locales que usan Node.js y TypeScript sobre PostgreSQL en zonas francas tecnológicas, a las que conviene esperar la versión estable antes de migrar en producción, dado que la propia rc.5 corrige una falla de estabilidad de conexión.
El equipo de Svelte publicó, el 21 de agosto de 2026, la versión 3.0.0-next.25 de SvelteKit, según el registro oficial de lanzamientos del proyecto en GitHub. La actualización agrega un ayudante llamado applyReroute, pensado para adaptadores que despliegan funciones serverless divididas por ruta; permite construir respuestas transmitidas (streamed) directamente desde generadores asíncronos de JavaScript; y corrige el registro de solicitudes remotas y el manejo de invalidación de navegación, según el mismo registro de cambios. El mismo día, el equipo publicó también versiones de los adaptadores oficiales de Vercel (7.0.0-next.8) y Netlify (7.0.0-next.10), ambas centradas en corregir cómo cada plataforma aplica las reglas de reescritura de ruta cuando el despliegue se divide en funciones serverless independientes, según el mismo repositorio. SvelteKit 3 sigue en fase de vista previa desde antes de agosto, con builds casi diarios: la next.24 llegó el 20 de agosto con soporte del método HTTP QUERY en archivos +server.js, y la next.25 de hoy continúa el mismo ritmo. Que el equipo coordine el mismo día cambios en el núcleo del framework y en dos adaptadores de plataforma distintos refleja cuánto del trabajo de esta serie se concentra en el despliegue sin servidor dividido por función, una arquitectura que reduce el tamaño de cada función individual pero exige que el enrutamiento y las reglas de reescritura se comporten igual en cada fragmento desplegado. La información de esta nota proviene únicamente del registro oficial de lanzamientos de SvelteKit en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de SvelteKit, pero el framework gana terreno entre desarrolladores locales que buscan alternativas más livianas a Next.js, a quienes conviene tratar la serie 3.0.0-next todavía como vista previa: sin fecha de versión estable anunciada, no es recomendable para producción.
— La candidata 3.0.0-next.25, publicada el 21 de agosto, agrega un ayudante para adaptadores con funciones serverless divididas y permite construir respuestas transmitidas desde generadores asíncronos.
cat /feed/devopscloudflareworkers.md
La versión 1.20260822.1, publicada el 22 de agosto, suma Pyodide 314.0.5 y actualiza SQLite a la versión 3.53.4, la undécima entrega consecutiva del motor de Cloudflare Workers desde el 12 de agosto.
> > workerd --version
> Cloudflare publicó, el 22 de agosto de 2026 a las 00:49 UTC, la versión 1.20260822.1 de workerd, el motor de ejecución de Cloudflare Workers, según el registro oficial de lanzamientos en GitHub. Es la undécima versión consecutiva que la compañía publica en otros tantos días, racha que arrancó el 12 de agosto y que esta sección sigue documentando como personaje de la semana. Los cambios de hoy: suma la versión 314.0.5 de Pyodide, el intérprete de Python compilado a WebAssembly que usan los Workers escritos en ese lenguaje; acepta valores WebAssembly.Module en el cargador dinámico de workers; actualiza el motor SQLite embebido a la versión 3.53.4; e implementa la serialización y deserialización mediante jsrpc para flujos (streams) de TypeScript, según el mismo registro de cambios.
> > workerd diff v1.20260821.1..v1.20260822.1
> La versión de ayer, 21 de agosto, se concentró en el control de reintentos de alarmas y en preservar conexiones WebSocket durante actualizaciones del entorno de ejecución; la de hoy vuelve a tocar límites de compatibilidad de lenguajes y motores internos, sin corregir fallas de seguridad. Once días consecutivos sin interrupción confirman que la cadencia diaria de workerd —sostenida por el propio flujo de integración continua de Cloudflare— no depende del contenido de cada entrega: la compañía publica igual si el cambio es una actualización de dependencia interna como Pyodide o SQLite que si es una corrección con impacto directo en aplicaciones con estado, como ocurrió ayer.
> > echo $COSTA_RICA
> La información de esta nota proviene únicamente del registro de lanzamientos oficial de Cloudflare Workerd en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de tráfico servido por Cloudflare Workers, pero equipos locales de zonas francas tecnológicas que ejecutan Workers escritos en Python sobre Pyodide pueden usar la versión 314.0.5 sin cambios de configuración, dado que la actualización llega dentro del mismo motor workerd.
Entre la promesa de GitHub de escalar su infraestructura tras un apagón de casi ocho horas y la quinta candidata de Vue con Vapor Mode, esta edición documenta cinco desarrollos recientes en el ecosistema de programación.
Esta edición documentó cinco desarrollos del 21 y el 22 de agosto de 2026: la entrada de blog en la que GitHub reconoce las causas del apagón del 17 de agosto y promete límites de reintento consistentes y una arquitectura de lectura escalable; la versión 3.6.0-rc.5 de Vue.js, que continúa el pulido de Vapor Mode, el modo de compilación sin árbol de nodos virtuales; la versión 8.0.0-rc.5 de Prisma, que unifica el CLI y corrige una pérdida de conexiones sobre PostgreSQL; la versión 3.0.0-next.25 de SvelteKit, con un ayudante nuevo para despliegues serverless divididos; y la versión 1.20260822.1 de Cloudflare workerd, la undécima entrega consecutiva de una racha que arrancó el 12 de agosto. El hilo que domina la jornada es la brecha entre la promesa y la ejecución: GitHub ya había anunciado a comienzos de año los mismos tres frentes de inversión en capacidad que repite hoy, y el apagón de agosto ocurrió de todas formas, con los commits mensuales de la plataforma casi duplicados desde abril. Cloudflare Workers y su motor workerd cierran esta semana como personaje de la semana en esta sección: once días consecutivos de lanzamientos, del 12 al 22 de agosto, hoy centrados en actualizar Pyodide y el motor SQLite embebido. Para equipos de desarrollo en Costa Rica, la lista de hoy queda mayormente en fase de observación: ninguno de los cinco desarrollos exige una acción inmediata en producción, salvo revisar los límites de reintento propios si el equipo depende fuertemente de la API de GitHub, y tratar tanto Vue 3.6, Prisma 8 como SvelteKit 3 como ramas de vista previa hasta que publiquen versión estable.