Un cambio de ruptura en las herramientas locales de Cloudflare Workers abre una edición que también sigue los lanzamientos casi diarios de workerd, tres versiones de ruptura en SvelteKit 3, la alerta de CISA sobre el RCE de TeamCity y el balance de la interrupción de diez horas en GitHub Actions.
La versión alpha 5.20260804.0, publicada el 10 de agosto junto con wrangler 4.120.1, obliga a declarar un arreglo workers y elimina el descubrimiento automático de módulos que Miniflare usaba hasta ahora.
El monorepo workers-sdk de Cloudflare publicó, el 10 de agosto de 2026 a las 17:04 UTC, la versión alpha 5.20260804.0 de Miniflare junto con wrangler 4.120.1 y el paquete nuevo @cloudflare/config 0.5.0, según las notas de lanzamiento oficiales en GitHub. El cambio central: el constructor new Miniflare() deja de aceptar opciones sueltas y ahora exige un arreglo workers con la forma de configuración que usa el resto de la plataforma Cloudflare, la misma que ya validan wrangler y el nuevo paquete @cloudflare/config. La reescritura también cambia la interfaz que reciben los complementos (plugins) —ahora reciben la configuración ya interpretada del worker en vez de fragmentos de opciones por complemento— y elimina el descubrimiento automático de módulos a partir de las banderas modules: true y modulesRules: los workers basados en módulos deben declarar ahora su grafo de módulos de forma explícita en el manifiesto de configuración. Cloudflare incluyó una utilidad, convertV4MiniflareOptions, para migrar configuraciones con la forma anterior, aunque las notas de lanzamiento advierten que no todas las configuraciones se pueden convertir de forma automática. El ajuste es de ruptura declarada —la propia entrada de cambios lo cataloga como "major"— y afecta a cualquier proyecto que use Miniflare de forma directa, ya sea a través de @cloudflare/vitest-pool-workers, del plugin de Vite para Workers o de un arnés de pruebas propio construido sobre su API. wrangler, que usa Miniflare internamente para el entorno de desarrollo local, ya se adaptó en la misma tanda de publicaciones: la 4.120.1 convierte las opciones que genera para desarrollo local a la nueva forma basada en configuración, un cambio que Cloudflare describe como invisible para la mayoría de quienes solo ejecutan wrangler dev. La compañía también retiró en esta versión el soporte para bindings D1 beta heredados (__D1_BETA__) creados antes de wrangler 3.3.0, la variante experimental de la base de datos D1 que antecedió a la versión estable. Cloudflare no precisó, en las notas consultadas para esta nota, una fecha de estabilización para la versión 5 de Miniflare fuera de su etiqueta alpha. La información de esta nota proviene únicamente del registro de lanzamientos oficial de Cloudflare Workers SDK en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Cloudflare Workers, pero la plataforma es una opción común para funciones de borde entre equipos de zonas francas tecnológicas que ya usan Cloudflare como red de entrega de contenido, a los que conviene revisar cualquier arnés de pruebas o configuración local construida sobre la API antigua de Miniflare antes de actualizar wrangler.
cat /feed/devopsworkerd.md
Las versiones 1.20260809.1, 1.20260810.1 y 1.20260811.1 de workerd, el motor de código abierto de Cloudflare Workers, mantienen el ritmo casi diario de publicaciones que esta sección ya documentó la semana pasada.
> > workerd --version
> Cloudflare publicó tres versiones de workerd entre el 9 y el 11 de agosto de 2026 —1.20260809.1, 1.20260810.1 y 1.20260811.1—, según el propio registro de lanzamientos del proyecto en GitHub. La más reciente, del 11 de agosto, suma un nuevo callback ActorObserver que se dispara cuando termina de construirse un Durable Object, la primitiva de estado persistente de Cloudflare Workers; implementa import.meta.dirname e import.meta.filename dentro de la resolución de módulos nativos, dos propiedades estándar de Node.js que antes no existían en ese contexto; fija la dependencia de Perfetto, la herramienta de trazado de rendimiento, en la versión 56.1 para evitar cambios de comportamiento entre versiones; y corrige la detección del entorno de ejecución de Node.js dentro de Emscripten, aplicando un parche (monkeypatch) sobre el objeto global process. Las versiones del 9 y el 10 de agosto no publicaron notas de cambios detalladas en el registro de GitHub más allá del conteo de commits —27 y 26 respectivamente—, una práctica habitual del proyecto en sus publicaciones diarias de rutina.
> > workerd --why
> El historial reciente del proyecto muestra al menos una versión con numeración de fecha cada día desde comienzos de agosto, el mismo patrón que esta sección describió el 10 de agosto al cubrir la estabilización de ctx.abort(). Ese ritmo mantiene el motor alineado con el resto de la plataforma Cloudflare —wrangler y Miniflare fijan sus versiones de workerd a publicaciones específicas, como confirma la propia nota de lanzamiento de wrangler 4.120.1 de esta edición—, pero también implica que cualquier equipo que corra workerd de forma directa, sin pasar por wrangler, revisa un registro de cambios distinto casi cada día laboral.
> > workerd --next
> Cloudflare no detalló, en las notas consultadas para esta nota, si las versiones del 9 y el 10 de agosto incluyeron cambios de comportamiento más allá de actualizaciones de dependencias. La información de esta nota proviene únicamente del registro de lanzamientos oficial de workerd en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de uso de Cloudflare Workers, pero los equipos locales que ya corren funciones de borde sobre la plataforma pueden revisar hoy mismo si su código usa Durable Objects antes de decidir si el nuevo callback ActorObserver les sirve para instrumentar arranques.
El proyecto SvelteKit publicó tres versiones de la rama de ruptura 3.0.0-next entre el 9 y el 11 de agosto de 2026 —next.17, next.18 y next.19—, según el registro de lanzamientos del proyecto en GitHub. La más reciente, next.19, del 11 de agosto, reúne seis cambios de ruptura: mueve la función defineParams al nuevo módulo @sveltejs/kit/params, en lugar de exportarla desde el paquete raíz; canaliza todos los errores de la aplicación a través del gancho (hook) handleError, incluidos los que antes se manejaban por otras vías; y reubica los tipos de navegación y de formularios en los módulos $app/navigation y $app/forms respectivamente. La víspera, next.18, separó los complementos de Vite que provee cada adaptador de despliegue en dos fases distintas —pre y post—, un cambio de ruptura para cualquier configuración que dependa del orden en que Vite aplica esos complementos; next.17, publicada el mismo 10 de agosto, hizo que las acciones de formulario entre páginas naveguen a la página de la acción tanto si el envío tiene éxito como si falla, y sumó un ayudante snapshot al módulo $app/navigation. La acumulación de tres versiones de ruptura en 48 horas es habitual en una rama next todavía sin fecha de estabilización, pero exige que cualquier proyecto que ya probó SvelteKit 3 revise su código contra cada version antes de actualizar, en particular las importaciones de defineParams y cualquier lógica personalizada de manejo de errores que hoy no pase por handleError. El patrón —reorganizar la superficie de la API en piezas más pequeñas y explícitas, en lugar de sumar funciones nuevas— es consistente con lo que el propio proyecto viene documentando desde que abrió la rama 3.0.0-next. El equipo de SvelteKit no publicó, en las notas consultadas para esta nota, una fecha estimada para la primera versión candidata a lanzamiento de SvelteKit 3. La información de esta nota proviene únicamente del registro de lanzamientos oficial 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 Svelte, pero el framework tiene una base de desarrolladores activa entre agencias de desarrollo web y equipos de producto locales, que deberían tratar la rama 3.0.0-next como una vista previa de trabajo en progreso y no como base para un proyecto en producción.
— Las versiones next.17 a next.19, publicadas entre el 9 y el 11 de agosto, mueven defineParams a un nuevo módulo, canalizan los errores por handleError y separan los complementos de Vite en dos fases.
La Agencia de Ciberseguridad e Infraestructura de Estados Unidos (CISA) sumó, el 5 de agosto de 2026, la vulnerabilidad CVE-2026-63077 de JetBrains TeamCity a su catálogo de fallas explotadas conocidas (KEV), según el aviso oficial publicado en cisa.gov. La falla, de deserialización de datos no confiables (CWE-502) en el protocolo de sondeo (polling) de agentes de TeamCity, permite a un atacante remoto sin autenticar ejecutar comandos del sistema operativo con los mismos privilegios que el proceso del servidor TeamCity On-Premises, según el análisis técnico de Rapid7. JetBrains había corregido la falla, con una puntuación CVSS de 9,8, el 28 de julio en las versiones 2025.11.7 y 2026.1.3 —el parche que esta sección cubrió ese mismo día—, pero CISA fijó el 8 de agosto como plazo para que las agencias civiles federales de Estados Unidos aplicaran la corrección, un margen de apenas tres días que la propia agencia reserva para fallas con evidencia de explotación activa. Un servidor TeamCity comprometido no es solo una máquina más: es la pieza que orquesta builds, pruebas y despliegues de otros proyectos, con acceso a credenciales, archivos de configuración y secretos de esos mismos proyectos, lo que convierte cada instancia expuesta en una puerta de entrada a la cadena de suministro de quien la usa —el mismo patrón que esta sección documentó a fines de julio con TeamCity, GitLab y N-able, y que GitHub intentó atajar esta semana al ampliar su detección de malware a ocho ecosistemas de paquetes. CISA no publicó, en el aviso consultado para esta nota, cuántas instancias de TeamCity On-Premises seguían expuestas a internet al momento de sumar la falla al catálogo. La cifra de instancias vulnerables varía según la fuente: mientras CISA no ofrece un conteo público, reportes de investigadores de seguridad citados por SecurityWeek en julio hablaban de explotación activa "poco después" de la divulgación original, sin precisar un número de servidores afectados. Costa Rica no publica cifras propias de instancias de TeamCity expuestas, pero la herramienta es común en equipos de plataforma de zonas francas tecnológicas que gestionan integración continua propia, a los que conviene confirmar hoy mismo si sus instancias ya corren 2025.11.7 o 2026.1.3, en particular si están accesibles desde fuera de una red privada.
El repaso posterior a la interrupción de casi once horas detalla que un despliegue rutinario activó un límite de capacidad interno y que algunos workflows nunca llegaron a ejecutarse, sin posibilidad de reproceso automático.
GitHub Actions sufrió, el 6 de agosto de 2026, una interrupción de diez horas y 42 minutos que no quedó resuelta hasta las 02:04 UTC del 7 de agosto, según el repaso técnico publicado por Incident Hub. En el momento más crítico, el 71% de las ejecuciones de workflows falló por errores de infraestructura y el 75% de las que sí corrieron se retrasó más de cinco minutos, de acuerdo con los datos recogidos en ese mismo repaso; la API REST de Actions también devolvió errores durante buena parte de la ventana. GitHub identificó como causa un despliegue de rutina a un servicio interno que procesa eventos y genera trabajos (jobs) de Actions, el cual expuso un límite de tasa (rate limit) interno —pensado para proteger la disponibilidad del servicio— que se activó de forma más amplia de lo previsto y retrasó más tráfico del esperado, según reportó WebProNews. El detalle que distingue esta caída de otras interrupciones de Actions es que algunos eventos que debían disparar workflows se perdieron por completo y no se pueden reproducir de forma automática: cualquier equipo que hizo push de código o abrió un pull request durante la ventana afectada, y asumió que la integración continua corrió, puede descubrir ahora que nunca llegó a ejecutarse. La lista de servicios afectados incluyó, además de los ejecutores (runners) alojados y propios, la revisión de código y el agente de programación de Copilot, las entregas de webhooks y las migraciones que usan GitHub Enterprise Importer, según el propio repaso. No todos los equipos de infraestructura coinciden en que el origen fue puramente técnico: la cobertura de WebProNews enmarca el incidente como evidencia de una tensión estructural más amplia en la infraestructura de desarrollo —la dependencia de millones de equipos en un solo proveedor centralizado de integración continua— más que como un percance aislado. GitHub no precisó, en las fuentes consultadas para esta nota, cuántos repositorios tuvieron al menos un evento de workflow perdido durante la ventana de casi once horas. Costa Rica no publica cifras propias de uso de GitHub Actions, pero la plataforma es la opción por defecto de integración continua para buena parte de los equipos de desarrollo de zonas francas tecnológicas del país que alojan su código en GitHub, a los que conviene revisar manualmente si algún push o pull request del 6 de agosto se quedó sin ejecutar su workflow, en lugar de asumir que un reintento automático ya lo cubrió.
Entre una reescritura de ruptura en las herramientas locales de Cloudflare Workers y la alerta de CISA sobre TeamCity, esta edición documenta cinco desarrollos recientes en el ecosistema de programación.
Esta edición documentó cinco desarrollos entre el 5 y el 11 de agosto de 2026: la reescritura de ruptura de Miniflare hacia una API basada en configuración, publicada junto con wrangler 4.120.1; tres versiones seguidas de workerd, el motor de código abierto de Cloudflare Workers, con un nuevo observador para Durable Objects; tres versiones de ruptura en la rama SvelteKit 3.0.0-next, que reorganizan el manejo de errores y las rutas de parámetros; la inclusión, por parte de CISA, del RCE sin autenticar de JetBrains TeamCity en su catálogo de fallas explotadas activamente; y el repaso técnico de la interrupción de casi once horas que sufrió GitHub Actions el 6 de agosto. El hilo que esta sección viene documentando desde fines de julio —la seguridad de la cadena de suministro de herramientas de desarrollo— sigue vivo con la alerta de CISA sobre TeamCity: la misma falla que JetBrains corrigió hace dos semanas hoy tiene evidencia de explotación activa suficiente para que la agencia estadounidense exija un parche en tres días a sus propias agencias. El resto de la edición documenta el ritmo ordinario de la ingeniería de plataforma —Cloudflare, SvelteKit— y un recordatorio de que la infraestructura que sostiene ese ritmo, como GitHub Actions, también puede fallar durante casi once horas seguidas. Para equipos de desarrollo en Costa Rica, la lista de esta semana suma tareas concretas: revisar cualquier arnés de pruebas construido sobre la API antigua de Miniflare antes de actualizar wrangler; confirmar si las instancias propias de TeamCity ya corren 2025.11.7 o 2026.1.3 y si están expuestas a internet; y revisar manualmente si algún push o pull request del 6 de agosto se quedó sin ejecutar su workflow en GitHub Actions.