Amazon anunció el 26 de agosto la compra de DuckLabs, la empresa detrás de la base de datos analítica DuckDB, en una operación que dejó abierto un debate sobre neutralidad; Cloudflare workerd llegó a dieciocho días consecutivos de lanzamientos, personaje de la semana en esta sección; Shadowserver contó 8.393 servidores Gitea todavía vulnerables a una falla crítica con fecha límite de parcheo hoy según CISA; GitHub Copilot CLI abrió ya dos candidatas de su siguiente ciclo tras la versión 1.0.81; Next.js sumó dos entregas canary con cambios en Turbopack; y Wrangler actualizó su dependencia de workerd el mismo día de la racha número dieciocho.
AWS firmó el 26 de agosto un acuerdo definitivo para adquirir a los más de treinta ingenieros de DuckLabs en Ámsterdam, sin tocar la propiedad intelectual del proyecto de código abierto DuckDB, que sigue bajo la Fundación DuckDB con licencia MIT.
Amazon anunció, el 26 de agosto de 2026, que Amazon Web Services firmó un acuerdo definitivo para adquirir DuckLabs, la empresa de Ámsterdam fundada por Hannes Mühleisen y Mark Raasveldt, creadores de DuckDB, según el comunicado oficial publicado en aboutamazon.com. La operación, cuyo monto no se reveló y cuyo cierre se espera para inicios de septiembre, incorpora a AWS a los más de treinta ingenieros de la compañía, que se mantendrán en Ámsterdam bajo el liderazgo de Mühleisen y Raasveldt, según la misma fuente y la cobertura de GeekWire. DuckDB es una base de datos analítica que corre embebida en el propio proceso de la aplicación, sin necesidad de un clúster ni de un almacén de datos en la nube, y se volvió una herramienta de referencia para ingenieros de datos que procesan archivos grandes en su propia máquina. Amazon aclaró que no adquiere el proyecto de código abierto DuckDB ni sus proyectos relacionados DuckLake y Quack, que siguen bajo licencia MIT y bajo el gobierno de la Fundación DuckDB, una entidad independiente sin fines de lucro, según el mismo comunicado. La estructura de la operación —comprar a las personas que dirigen el proyecto sin comprar el código— generó un debate abierto en Hacker News sobre si la propiedad de AWS sobre los mantenedores principales de DuckDB amenaza la neutralidad del proyecto pese a que el código siga con licencia MIT bajo una fundación independiente, un debate que un análisis de InfoWorld describió como la pregunta de fondo detrás de lo que calificó de una "adquisición clásica de equipo" (acqui-hire) con influencia desproporcionada sobre cómo trabajan los desarrolladores. Jordan Tigani, director ejecutivo de MotherDuck —la empresa que ofrece DuckDB como servicio en la nube y que hasta ahora evitaba competir directamente con DuckLabs— calificó el movimiento de Amazon como "totalmente previsible" y dijo que "el peso de Amazon detrás de DuckDB le va a sumar impulso y va a fortalecer el ecosistema", aunque también reconoció, según la misma fuente, que la operación sigue el patrón conocido de grandes proveedores de nube que terminan comercializando proyectos de código abierto exitosos. La Fundación DuckDB respondió a la inquietud anunciando planes para sumar una junta asesora técnica que sirva de canal de comunicación entre todos los que apuestan por el proyecto, según GeekWire. Costa Rica no publica cifras propias de adopción de DuckDB, pero la base de datos gana terreno entre equipos locales de análisis de datos y ciencia de datos que procesan archivos grandes sin levantar infraestructura de nube completa, para quienes la operación de hoy no cambia la licencia ni el costo de uso del motor, pero sí vale la pena seguir de cerca si la hoja de ruta técnica del proyecto empieza a alinearse con los servicios propios de AWS una vez que el equipo fundador quede empleado allí.
El observatorio de seguridad Shadowserver reportó, en un escaneo fechado el 27 de agosto de 2026, que 8.393 servidores Gitea expuestos a internet siguen sin corregir la vulnerabilidad CVE-2026-60004, según la cobertura de BleepingComputer publicada el 28 de agosto. La falla, con puntuación CVSS de 9,8 sobre 10, es una inyección de código en la funcionalidad diffpatch de Gitea que permite a un atacante autenticado con acceso de escritura a un repositorio ejecutar comandos de shell arbitrarios con los privilegios de la cuenta de servicio de Gitea, al enviar parches maliciosos a través del punto de acceso de la API correspondiente, según el aviso original de Gitea, reportado por el investigador de seguridad de Salesforce Shai Rod. Gitea publicó la versión 1.27.1 el 27 de julio de 2026 para corregirla y difundió el aviso al día siguiente. La Agencia de Seguridad de Infraestructura y Ciberseguridad de Estados Unidos (CISA) sumó la falla a su catálogo de vulnerabilidades explotadas conocidas (KEV) el 25 de agosto, confirmando explotación activa en el mundo real, y fijó como fecha límite el 28 de agosto de 2026 para que las agencias civiles federales estadounidenses aplicaran el parche, según SecurityWeek. Los ataques observados incluyen el despliegue de software de minería de criptomonedas en servidores comprometidos, según Help Net Security. Que más de ocho mil instancias sigan expuestas un mes completo después de que existiera una versión corregida —y tres días después de que CISA confirmara explotación activa— es el propio dato que expone la brecha entre la disponibilidad de un parche y su aplicación real en el ecosistema de git autoalojado, una brecha que ni Gitea ni Shadowserver atribuyen a una causa única en las fuentes consultadas para esta nota. Costa Rica no publica cifras propias de instancias de Gitea autoalojadas, pero la herramienta es una alternativa común a GitHub y GitLab entre equipos de desarrollo locales y zonas francas tecnológicas que prefieren alojar su propio control de versiones, para quienes la recomendación inmediata es verificar la versión de su instancia y actualizar a la 1.27.1 o superior si todavía no lo hicieron, sin esperar una fecha límite regulatoria que en Costa Rica no aplica.
cat /feed/devopscloudflareworkers.md
La versión 1.20260829.1, publicada hoy, corrige varias fallas de seguridad de memoria con "dynamic_cast" y extiende a dieciocho la racha diaria de Cloudflare Workers, personaje de la semana en esta sección desde hace tres ediciones.
> > workerd --version
> Cloudflare publicó, el 29 de agosto de 2026 a las 00:58 UTC, la versión 1.20260829.1 de workerd, el motor de ejecución de Cloudflare Workers, según el registro oficial de lanzamientos en GitHub. Es la decimoctava versión consecutiva que la compañía publica en otros tantos días, racha que arrancó el 12 de agosto. La entrega usa "dynamic_cast" para evitar confusiones de tipo en componentes internos, corrige un uso de memoria después de liberarla (use-after-free) en búferes en tránsito y en el manejo de EventSource, retiene los WebSockets hibernables durante bombeos (pumps) activos, y cancela los bombeos de flujo internos antes de liberar su fuente, según el mismo registro de cambios, que suma doce solicitudes de cambio fusionadas, dos de ellas de colaboradores nuevos.
> > workerd diff v1.20260828.1..v1.20260829.1
> Dieciocho días sin una sola interrupción, del 12 al 29 de agosto, mantienen a Cloudflare Workers como el hilo más sostenido de esta categoría en lo que va del mes y como personaje de la semana en esta sección por tercera edición consecutiva. La de hoy es, a diferencia de otras jornadas de la racha, una entrega centrada en seguridad de memoria más que en funciones nuevas —cuatro de sus doce cambios corrigen directamente errores de manejo de memoria—, y coincide con una actualización de Wrangler, la interfaz de línea de comandos de Cloudflare Workers, que ese mismo día fijó su dependencia de workerd en la versión de 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 corren cargas sensibles sobre Workers deberían priorizar esta actualización por sus correcciones de seguridad de memoria antes que por sus funciones nuevas.
GitHub publicó, el 28 de agosto de 2026 a la 1:32 UTC, la versión 1.0.82-0 de Copilot CLI, la primera candidata del ciclo que se abrió menos de ocho horas después de que la 1.0.81 se convirtiera, el 27 de agosto, en la primera etiqueta de la serie sin sufijo de candidata —hito que esta sección documentó ayer. El detalle de los cambios de la 1.0.82-0 no estaba disponible al cierre de esta edición, según el registro oficial de lanzamientos del proyecto en GitHub. Casi dieciséis horas más tarde, a las 17:28 UTC del mismo 28 de agosto, GitHub publicó la versión 1.0.82-1, que corrige la forma en que la herramienta reporta errores de autenticación: ahora muestra el fallo específico —por ejemplo, credenciales inválidas con código 401— en lugar de mostrar únicamente la instrucción genérica de volver a iniciar sesión, según el mismo registro de cambios. Que el equipo abriera ya dos candidatas del siguiente ciclo el mismo día en que esta sección celebraba la primera versión estable de la serie confirma que el corte de la 1.0.81 fue una pausa editorial y no un cambio de cadencia: Copilot CLI sigue publicando con la misma frecuencia casi diaria que sostiene desde el 18 de agosto, solo que ahora la etiqueta estable queda fija mientras las candidatas numeradas absorben el trabajo en curso. La información de esta nota proviene únicamente del registro oficial de lanzamientos de GitHub Copilot CLI en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de GitHub Copilot CLI, pero la herramienta gana terreno entre equipos de desarrollo locales que automatizan tareas de programación asistida, para quienes la corrección de mensajes de autenticación de hoy simplifica el diagnóstico cuando una credencial vence o se revoca.
— Las versiones 1.0.82-0 y 1.0.82-1, publicadas el 28 de agosto, corrigen los mensajes de error de autenticación y confirman que el ciclo diario de candidatas continúa apenas un día después de la primera etiqueta estable de la serie.
El equipo de Next.js publicó, el 28 de agosto de 2026 a las 2:14 UTC, la versión 16.4.0-canary.10 en su rama canary, y a las 23:38 UTC del mismo día la versión 16.4.0-canary.11, según el registro oficial de lanzamientos del proyecto en GitHub. La canary.10 sube la biblioteca hashbrown que usa Turbopack a la versión 0.15, acorta los nombres de clase generados por los módulos CSS y agrega una opción de caché de componentes de React al asistente create-next-app. La canary.11 corrige el enrutamiento optimista con parámetros dinámicos codificados y los parámetros de rutas interceptadas después de reescrituras (rewrites) de Proxy, refactoriza el optimizador de imágenes en un módulo de transformación más liviano, y activa por defecto en Turbopack la ofuscación de nombres (mangling) para producir paquetes más pequeños en compilaciones de producción, según el mismo registro de cambios. La clave de estas dos entregas está en ese último cambio: activar por defecto el mangling en producción es un paso que Turbopack venía posponiendo mientras maduraba su paridad de funciones con Webpack, y su llegada silenciosa a la rama canary —sin anuncio propio, solo como una línea más del registro de cambios— sugiere que el equipo lo considera ya suficientemente probado como para no tratarlo como una función experimental aparte. Ninguna de las dos versiones toca la reactivación de la optimización de imágenes AVIF que esta sección documentó el 27 de agosto ni las fallas de seguridad críticas corregidas la semana pasada; la rama estable permanece congelada en la 16.3.3 desde entonces. Costa Rica no publica cifras propias de aplicaciones Next.js en producción, pero el framework es una de las bases más comunes entre agencias y startups locales que construyen sitios con React, para quienes los cambios de hoy —todos en la rama canary— interesan sobre todo si ya usan Turbopack como compilador de producción y quieren anticipar el efecto del mangling en el tamaño final de sus paquetes antes de que llegue a una versión estable.
El equipo de Cloudflare publicó, el 28 de agosto de 2026 a las 14:54 UTC, la versión 4.127.1 de Wrangler, la interfaz de línea de comandos de Cloudflare Workers, según el registro oficial de lanzamientos del proyecto workers-sdk en GitHub. La entrega sube la dependencia de workers-types de la versión ^5.20260826.1 a la ^5.20260828.1 y la de workerd de la 1.20260826.1 a la 1.20260828.1 —un día detrás de la racha diaria de dieciocho jornadas que esta sección documenta hoy como personaje de la semana—, patrón habitual del proyecto de fijar una versión de workerd con uno o dos días de rezago. El mismo día, Cloudflare publicó también @cloudflare/vitest-plugin 1.1.2, que corrige lentitudes y bloqueos al recrear repetidamente Durable Objects durante las pruebas, @cloudflare/local-explorer-ui 0.15.0, con inspección y prueba de correos electrónicos, y @cloudflare/config 0.9.0, que renombra el campo workerName a worker, según el mismo registro de cambios. Es la segunda versión de Wrangler en apenas un día hábil después de la 4.127.0 del 27 de agosto, que esta sección documentó ayer por el cambio en el formato de subida de sus vistas previas; la de hoy es, en cambio, una actualización de dependencias sin cambios de comportamiento propios, parte del ritmo habitual con el que el ecosistema de herramientas de Cloudflare Workers absorbe cada entrega diaria de workerd. La información de esta nota proviene únicamente del registro oficial de lanzamientos de Wrangler 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 ni de Wrangler, pero equipos locales de zonas francas tecnológicas que despliegan Workers no necesitan una acción inmediata con esta versión: es una actualización de mantenimiento de rutina.
Entre la compra del equipo de DuckDB por Amazon y los más de ocho mil servidores Gitea todavía vulnerables, esta edición documenta seis desarrollos recientes del ecosistema de programación.
Esta edición documentó seis desarrollos del 26 al 29 de agosto de 2026: la adquisición de DuckLabs, la empresa detrás de la base de datos DuckDB, por parte de Amazon Web Services, con un debate abierto en Hacker News sobre la neutralidad futura del proyecto; el hallazgo de Shadowserver de 8.393 servidores Gitea todavía vulnerables a la falla crítica CVE-2026-60004 un mes después de que existiera un parche; la versión 1.20260829.1 de Cloudflare workerd, decimoctava entrega consecutiva de una racha que arrancó el 12 de agosto; las versiones 1.0.82-0 y 1.0.82-1 de GitHub Copilot CLI, que abren ya el ciclo de candidatas posterior a la primera versión estable de la serie; dos entregas canary de Next.js con mejoras a Turbopack; y la versión 4.127.1 de Wrangler, que fija su dependencia de workerd al día anterior. El hilo que domina la jornada es la tensión entre consolidación y neutralidad en las herramientas que sostienen el trabajo diario de quien programa: Amazon compra al equipo fundador de una base de datos de código abierto sin comprar el código, y a la vez ocho mil trescientas instancias de un servidor de git autoalojado siguen expuestas a una falla crítica pese a que la corrección existe hace un mes, dos formas distintas de la misma pregunta sobre quién controla, en la práctica, las piezas que los equipos de desarrollo dan por sentadas. Cloudflare Workers y su motor workerd cierran el sábado como personaje de la semana en esta sección por tercera edición consecutiva: dieciocho días seguidos de lanzamientos, del 12 al 29 de agosto, con una entrega de hoy centrada en seguridad de memoria. Para equipos de desarrollo en Costa Rica, la acción concreta de esta edición es verificar la versión de cualquier instancia propia de Gitea y actualizarla a la 1.27.1 o superior si todavía no se hizo. El resto de la lista —DuckDB, Copilot CLI, workerd, Next.js y Wrangler— queda en fase de observación de rutina, sin cambios que exijan una acción inmediata en producción.