Tratopedia
EN
Ajustes

Tamaño del texto

Tema

Alto contraste

Versión

v1.184.0

La publicación con la que se generó esta página. Es la que almacena en caché el service worker.

Infraestructura web · Ingeniería de software · Seguridad informática · Informe de ingenieríaCambio de junio de 2026 · registro hasta septiembre de 2026

Cloudflare traslada cdnjs a su propia plataforma para desarrolladores

Nueve mil millones de peticiones al día, movidas sin reconstruir un solo archivo

El 23 de junio de 2026 cdnjs, la CDN gratuita que usa aproximadamente uno de cada nueve sitios web, pasó a funcionar exclusivamente sobre la plataforma para desarrolladores de Cloudflare; Cloudflare publicó el relato el 30 de julio. La migración es el titular y la marcha atrás es la lección: un intento anterior regeneró el catálogo antiguo, cada archivo salió con un hash de integridad distinto, y para quien lo hubiera fijado eso no es una diferencia sino una página en blanco. Así que el catálogo se copió byte a byte. Tres semanas después del cambio, la misma lección llegó por el otro lado — se descubrió que el nuevo bot de publicación perdía el último byte de cada archivo que extraía.

  • 23 jun 2026en exclusiva en la plataforma; se hizo público 37 días después
  • 9.18 bnpeticiones al día, promedio de los doce meses hasta julio de 2026 según los informes mensuales del propio cdnjs; solo julio fue 7.4 mil millones
  • 98.6%tasa de acierto de caché, según Cloudflare — quedan unos 126 millones de peticiones diarias que la rebasan (cálculo nuestro)
  • 1 byterecortado del final de cada archivo que extraía el nuevo bot de publicación, hasta el arreglo del 17 de julio de 2026
SolidezLo que se afirma
DocumentadoUn navegador al que se le da integrity="sha384-…" calcula el hash de lo que recibe y, si nada coincide, se niega a cargar el recurso y devuelve un error de red. No hay modo degradado. Por eso un archivo regenerado rompe el servicio en lugar de ser una diferencia cosmética.
DocumentadoSe elevaron dos límites de la plataforma antes del cambio, y el registro de cambios de Cloudflare fecha ambos. El 11 de febrero de 2026 el límite de subpeticiones en planes de pago pasó de 1,000 a un valor por defecto de 10,000 por invocación, configurable hasta 10 millones. El 3 de marzo de 2026 Workflows pasó de 1,024 pasos a 10,000, configurables hasta 25,000.
DocumentadoTres semanas después del cambio, un usuario informó de que las fuentes de Font Awesome 7.3.0 servidas por cdnjs no se podían decodificar. La ingeniera a cargo de la migración lo atribuyó al analizador tar que usa el nuevo bot de publicación, que quitaba el último byte de cada entrada de archivo; la mayoría de archivos acaban en un salto de línea y sobrevivieron, pero fuentes, WebAssembly, SVG, CSS minificado y JSON no. Font Awesome 7.1.0 a 7.3.0 se corrigieron y republicaron el 17 de julio.
DocumentadoEl repositorio de GitHub que había sido la fuente de verdad de cdnjs recibió su último commit automático el 30 de septiembre de 2025. El 3 de septiembre de 2026 se le añadió un aviso de que “ya no se actualiza porque se volvió demasiado grande” y de que cdnjs funciona ahora con un bucket de R2.
Documentado en los informes del propio proyectoTráfico y alcance. Los informes mensuales de cdnjs, elaborados con datos que aporta Cloudflare, sitúan las peticiones diarias entre 9.0 y 10.0 mil millones de junio de 2025 a abril de 2026, y luego en 8.6, 8.5 y 7.4 mil millones en mayo, junio y julio de 2026. W3Techs, que enlaza el propio texto de Cloudflare, mide cdnjs en el 11.3% de todos los sitios web en septiembre de 2026 — el 48.0% de los sitios cuya CDN de JavaScript puede identificar.
Confirmado por el operador, no verificable aquíLa fecha del cambio; 108,000 peticiones por segundo; más de 330 centros de datos; un 98.6% de acierto de caché; la nueva arquitectura. Y un intento anterior de migración que fue revertido: reprocesar paquetes antiguos daba archivos correctos pero no idénticos byte a byte, de modo que sus hashes de integridad cambiaban, y el catálogo se copió después de KV a R2 tal cual.
Afirmado, y matizado por los registros del propio proyectoCada archivo de cdnjs lleva un hash SRI — afirmado tres frases antes de admitir que Cloudflare sigue trabajando para asegurar que los hashes almacenados coincidan con la realidad. Una solicitud de cambios escrita durante la comparación previa al cambio añade que las dos tuberías de hash, la antigua y la nueva, son “de mejor esfuerzo” y omiten sin avisar los archivos que no pueden procesar.

Cómo se llegó hasta aquí quince años, un paso que no se puede fechar, y lo que vino después del texto

  1. 2011Nace y pasa a Cloudflare. Ryan Kirkman y Thomas Davis crean CDNJS a principios de año sobre Amazon CloudFront; el coste y la dificultad de ofrecer HTTPS les hacen marcharse, y en junio entra en servicio en Cloudflare, gratis.
  2. Finales de 2019Cloudflare asume el mantenimiento del repositorio después de que un bot comunitario dejara de funcionar. El repositorio ocupa entonces 182 GB sin su historial.
  3. abr 2020El origen se apaga. Un centro de datos principal que alberga el origen primario de cdnjs queda fuera de servicio unas cuatro horas; la caché de Cloudflare limita el daño a los archivos no cacheados. Cloudflare lo llamaría después la primera llamada de atención.
  4. sep 2020La entrega se muda; la publicación no. Los archivos se sirven desde Workers y KV, precomprimidos con Brotli y gzip. La tubería que vigila npm y GitHub se queda en Google Cloud.
  5. abr – jun 2021Un investigador entra en el bot de publicación. Un paquete de npm preparado a propósito permite a RyotaK ejecutar código en el servidor de actualización automática. Cloudflare revoca todas las credenciales en menos de una hora, publica un arreglo en un día y termina de rediseñar la tubería el 3 de junio; afirma que no se modificó ninguna biblioteca existente.
  6. Sin fechaEl intento que se revirtió. Se reprocesan paquetes antiguos y se escriben directamente en R2; los resultados no coinciden byte a byte con lo que servía KV, de modo que los hashes de integridad difieren y el cambio se deshace. Ninguna fuente le pone fecha.
  7. 30 sep 2025El espejo de GitHub se detiene. Llega el último commit automático al repositorio que había sido la fuente de verdad de cdnjs.
  8. 11 feb 2026Subpeticiones. El valor por defecto de los planes de pago sube de 1,000 a 10,000 por invocación, configurable hasta 10 millones.
  9. 3 mar 2026Pasos de Workflow. 1,024 pasa a 10,000 por defecto, configurable hasta 25,000.
  10. 11 – 17 jun 2026Una comparación en la sombra antes del cambio. El nuevo worker de metadatos se configura para contrastar sus respuestas con el origen antiguo sobre una muestra del tráfico real, con la regla de que más hashes que antes cuentan como cobertura ganada y menos como cobertura perdida.
  11. 23 jun 2026cdnjs funciona en exclusiva sobre la plataforma. R2 pasa a ser la única fuente de verdad del contenido; KV solo conserva los metadatos.
  12. 13 – 17 jul 2026El byte que faltaba. Se informa de fuentes de Font Awesome rotas, se rastrea el fallo hasta el analizador tar del nuevo bot, y se corrige y republica en cuatro días.
  13. 30 jul 2026Cloudflare publica el relato, 37 días después del cambio. InfoQ lo recoge el 14 de agosto.
  14. 25 – 29 ago 2026Espejos y sitio web. Los primeros operadores de espejos reciben acceso de solo lectura al catálogo de R2 el 25 de agosto; el 29 de agosto cdnjs.com pasa al Worker que ya servía la API.
  15. 3 sep 2026El repositorio de GitHub lo dice. Se añade un aviso: ya no se actualiza, es demasiado grande, funciona con R2.

Un paso no tiene fecha, y es el que importa

Todo lo demás está fechado al menos al mes. El intento revertido no tiene fecha alguna — ni mes ni año — así que no puede situarse honestamente en la secuencia. Figura como sin fecha en lugar de adivinarla. Tampoco consta cuándo se pausaron las actualizaciones automáticas en torno al cambio; solo que se reactivaron antes del 13 de julio.

Lo que sostiene Cloudflare usar lo que uno vende, y la frase a la que apunta todo

La palabra del propio texto es dogfooding, y su argumento es un silogismo: cdnjs es enorme, cdnjs funciona ahora sobre las mismas piezas que cualquiera puede alquilar, luego esas piezas aguantarán lo que sea que estés construyendo — “probablemente pueda ejecutar lo que sea que estés construyendo.” Conviene separar las dos mitades. La evidencia es real: se elevaron dos límites de la plataforma porque cdnjs chocó con ellos, el registro de cambios de Cloudflare los fecha en febrero y marzo de 2026, y rigen para todo cliente de pago. También es menor de lo que el texto da a entender. El texto, y InfoQ después, dicen que las subpeticiones “ahora llegan hasta 10 millones”; el registro de cambios dice que el valor por defecto de pago pasó a 10,000, con 10 millones como techo que el cliente debe configurar. Es una subida de diez veces por defecto, no de diez mil. La inferencia es un argumento comercial, y el texto no finge lo contrario. Dice sin rodeos que no era un problema de rendimiento — “No migramos porque cdnjs fuera lento” — y atribuye a la arquitectura antigua un 98% de acierto de caché y, en sus palabras, ninguna caída. La queja era que cambiar algo obligaba a coordinar despliegues entre funciones de Google Cloud, una máquina virtual y Cloudflare, y que un fallo parcial era invisible: una versión podía llegar a KV, no llegar al repositorio de GitHub sin avisar y servirse sin problemas durante semanas hasta que alguien advertía que los dos almacenes habían divergido.

  • 26funciones en la nube solo para consultar npm — una por letra del alfabeto, cada una con su despliegue y sus registros.
  • 274entradas de .gitignore mantenidas a mano que bloquean versiones rotas o con numeración extraña — la expresión del propio texto es “un cementerio documentado”.
  • 10×la subida del límite por defecto de subpeticiones de Workers, de 1,000 a 10,000 — con un techo configurable de 10 millones, que es de donde sale la cifra destacada del texto.

El mecanismo, visto desde los dos lados por qué un archivo regenerado es una página en blanco, y un byte perdido también

  • Integridad de subrecursos

    El navegador se niega, no degrada

    • Una página puede fijar un hash: <script integrity="sha384-…">.
    • El navegador calcula el hash de lo que llega y compara. Si no coincide devuelve un error de red y el script no se ejecuta nunca. Entre orígenes distintos la comprobación exige además CORS.
    • Fuente: MDN. Esta es toda la razón por la que hubo que deshacer el primer intento.
  • Determinismo

    Reconstruir da bytes correctos, no los mismos bytes

    • Los minificadores y compresores no son del todo deterministas entre versiones, así que volver a ejecutarlos años después da una salida correcta que no es idéntica.
    • Bytes distintos significan un hash distinto, y un hash distinto significa que se rompe toda página que fijó el anterior.
    • La lección general: un almacén direccionado por contenido no se puede reconstruir. Solo se puede copiar.
  • El byte que faltaba

    La misma lección, llegando por el otro lado

    • En el gestor de incidencias de los propios mantenedores, la ingeniera a cargo de la migración escribió que el analizador tar del nuevo bot “quita el último byte de cada entrada de archivo” — inofensivo si ese byte es un salto de línea, fatal en una fuente.
    • El arreglo supuso republicar Font Awesome 7.1.0 a 7.3.0 bajo sus direcciones de versión existentes.
    • Nuestra lectura: es justo lo que la marcha atrás dice que no debe pasarle a un archivo ya en circulación, hecho porque el archivo estaba mal. La marcha atrás y el byte son una sola lección vista desde los dos lados — los bytes que una CDN publica primero son con los que tiene que vivir.
  • Lo que sigue sin saberse

    Cuántos hashes almacenados son incorrectos, y cuántos no se generaron nunca

    • Cloudflare dice que sigue trabajando para que los hashes almacenados coincidan con la realidad, “por errores del sistema antiguo”.
    • Una solicitud de cambios de junio de 2026 añade que las dos tuberías omiten los archivos que no pueden procesar, y cuenta como cobertura ganada que la nueva devuelva más hashes.
    • Ninguno da una magnitud. Un hash almacenado incorrecto en un archivo que alguien fijó es una página rota en algún sitio.

Alrededor de la migración el historial de seguridad, las cifras y lo que hizo el proyecto después

La tubería de publicación es la parte que merece protegerse, y hay precedente. El texto dice que retirar la tubería antigua eliminó un montón de cosas que proteger — funciones, una máquina virtual, buckets, claves de cuentas de servicio. En abril de 2021 el investigador RyotaK mostró por qué importa esa superficie: un paquete de npm con un enlace simbólico preparado hizo que el servidor de actualización automática ejecutara su código y filtrara sus credenciales. Cloudflare las revocó en menos de una hora, desconectó el servicio y terminó de rediseñar la tubería ese junio; afirma que no se alteró ninguna biblioteca existente. Aquello se corrigió hace cinco años y no es una de las vulnerabilidades sin nombre que menciona el texto de 2026. Las cifras aguantan como promedios anuales, y peor mes a mes. Las cifras de alcance del texto son de W3Techs, que el propio texto enlaza: el 11.3% de todos los sitios web en septiembre de 2026, frente al “aproximadamente 12%” del texto. Sus “9 mil millones al día” coinciden con los informes mensuales del propio cdnjs como promedio anual — 9.18 mil millones en los doce meses hasta julio de 2026 — pero julio fue 7.4 mil millones, el mes más bajo de los catorce leídos. Ninguna fuente da una razón, y aquí no se ofrece ninguna. Después del texto, la migración siguió. Los operadores de espejos, entre ellos un espejo que sirve a China continental y un servicio de monitorización de integridad, recibieron acceso de solo lectura al catálogo de R2 desde el 25 de agosto; el sitio cdnjs.com pasó al Worker de la API el 29 de agosto; y el repositorio de GitHub dice ahora claramente que ya no se actualiza.

  • 7.4 bnpeticiones al día en julio de 2026, frente a un promedio de doce meses de 9.18 mil millones — ninguna fuente explica por qué.
  • 11.3%de todos los sitios web usan cdnjs, según W3Techs, septiembre de 2026 — lo que sitúa una CDN de JavaScript en cerca del 23.5% de la web (cálculo nuestro).
AntesAhoraQué cambió en realidad
Workers KV + un repositorio de GitHubR2 como única fuente de verdadAntes ninguno de los dos almacenes era autoritativo, y cuando divergían no había forma limpia de reconciliarlos. La copia de GitHub, de hecho, había dejado de recibir archivos casi nueve meses antes del cambio. Los espejos se sincronizan ahora desde R2 por su interfaz S3, con credenciales de solo lectura que se conceden a petición.
Una cadena de funciones activadas por eventos de bucketWorkflows, con Queues y un contador en un Durable ObjectEl almacenamiento hacía las veces de cola de mensajes — sin cola de mensajes fallidos, sin visibilidad de la acumulación, sin reintento limpio. Workflows conserva el estado de cada paso, de modo que un tiempo de espera agotado reanuda en vez de reiniciar.
Un origen físico detrás del bordecaché → R2 → DigitalOcean SpacesDigitalOcean replica el almacenamiento: arquitectónicamente una copia de recuperación, operativamente un respaldo en vivo. A fecha del texto, un origen alojado por Cloudflare seguía en la cadena hasta que terminara el volcado desde GitHub; ninguna fuente posterior dice si ya ocurrió.
Un sitio web estático aparteEl mismo Worker que la APIEl 29 de agosto de 2026 cdnjs.com pasó a páginas generadas por el Worker que sirve la API — una pieza más trasladada a la misma plataforma, después del texto.

Qué llevarse de todo esto una lección transferible, y lo que conviene sostener con holgura

Copia los bytes; no los reconstruyas — y acierta a la primera

Esta es la parte que sirve para sistemas que nada tienen que ver con las CDN. Si alguien aguas abajo ha fijado un hash de tu salida, esa salida deja de ser algo que puedas regenerar — la cadena de herramientas habrá cambiado, los bytes serán distintos, y ser correcto no bastará. Cloudflare lo aprendió intentándolo y dando marcha atrás, y lo publicó. El byte perdido de julio es la misma regla vista desde el otro lado: un archivo publicado mal solo se arregla rompiendo la promesa de que nunca cambia.

Completa en el sentido del titular, todavía en marcha en la práctica

cdnjs sí funciona sobre la plataforma. Alrededor de ese hecho, el registro muestra una tubería de actualizaciones pausada y reactivada, un defecto hallado y corregido a las tres semanas, un sitio web trasladado dos meses después, espejos que pasaron a R2 y un origen que, según el texto, se retiraría al terminar un volcado. Nada de ello deshace el titular; todo ello es el aspecto real de una migración de este tamaño.

Sostén las cifras con holgura, y la afirmación de seguridad con la mayor de todas

“9 mil millones al día” es justo como promedio anual y generoso para el mes en que apareció el texto; la subida del límite es de diez veces por defecto y de diez mil solo para el cliente que lo pida. Esas son las partes sólidas. La frase que conviene sostener con más holgura es que retirar la tubería antigua “cerró todas las vulnerabilidades de cdnjs abiertas recientemente” — sin recuento, sin identificador, sin gravedad, en un texto por lo demás preciso hasta el dígito.

Lo que no pudo verificarse

Información sin confirmar — Cloudflare, en su propio relato: que retirar la tubería antigua “cerró todas las vulnerabilidades de cdnjs abiertas recientemente”. No se da recuento, identificador ni fecha, y no hay ningún aviso de seguridad publicado en los repositorios principales del proyecto.
Información sin confirmar — Cloudflare: que el repositorio de GitHub superó 1.1 TB de almacenamiento empaquetado y que el servicio de archivos de GitHub se negó a generar descargas. El propio registro del repositorio en GitHub da un tamaño de unos 70 GB, con una medida que no define; nada reconcilia las dos cifras.
Información sin confirmar — Cloudflare: que la arquitectura usada de 2020 a 2026 no tuvo caídas. No se encontró ningún registro de incidentes específico de cdnjs, ni en un sentido ni en otro.
Información sin confirmar — Cloudflare: que los modelos de lenguaje recurren a cdnjs porque sus datos de entrenamiento están llenos de él. Se ofrece como explicación, no se mide.

Mensaje principal y fuentes

  • Simona Badoiu, “Dogfooding at scale: migrating cdnjs to Cloudflare’s Developer Platform”, The Cloudflare Blog, 30 jul 2026
  • W3Techs, “Usage statistics and market share of CDNJS for websites”, septiembre de 2026
  • Registro de cambios de Cloudflare, “Workers are no longer limited to 1000 subrequests”, 11 feb 2026, y “Workflows step limit increased to 25,000 steps per instance”, 3 mar 2026
  • Matthew Prince, “CDNJS: Community Moderated Javascript Libraries + CloudFlare”, 16 jun 2011
  • Zack Bloom, “An Update on CDNJS”, 19 dic 2019
  • Tyler Caslin, “Migrating cdnjs to serverless with Workers KV”, 10 sep 2020
  • Jonathan Ganz, Thomas Calderon y Sven Sauleau, “Cloudflare’s Handling of an RCE Vulnerability in cdnjs”, 24 jul 2021 — todos en The Cloudflare Blog
  • RyotaK, “Remote code execution in cdnjs of Cloudflare”, 16 jul 2021
  • MDN Web Docs, “Subresource Integrity”, Mozilla
  • Leela Kumili, “Cloudflare Migrates JavaScript CDN Serving 9B Requests a Day to Its Developer Platform”, InfoQ, 14 ago 2026
  • cdnjs en GitHub: informes mensuales de uso (cf-stats), de junio de 2025 a julio de 2026
  • solicitudes de cambios 6 y 7 de metadata-worker, junio de 2026
  • incidencias 14305, 14307 y 14309 de cdnjs, julio–agosto de 2026
  • solicitud de cambios 279 de api-server, 29 ago 2026
  • el README del repositorio cdnjs/cdnjs y su registro de repositorio en GitHub, septiembre de 2026. Todas las fuentes leídas en su totalidad, 28 sep 2026.

Versiones

Este documento se reescribe cuando lo que dice tiene que cambiar. Cada versión sigue publicada en su propia dirección.

  1. v0002 actual
  2. v0001 reemplazada

La versión actual también está en latest/.