Qué pasó
Infraestructura web · Ingeniería de software · Seguridad informática · Informe de ingenieríaTratopedia · 16 ago 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 pasó a funcionar exclusivamente sobre la plataforma para desarrolladores de Cloudflare, y el 30 de julio Cloudflare publicó el relato. La migración es el titular; la marcha atrás es la lección. Un intento anterior reprocesó el catálogo antiguo y hubo que abandonarlo, porque los minificadores no son deterministas entre versiones y cada archivo regenerado salía con un hash de integridad distinto — lo que, para quien lo hubiera fijado, no es una diferencia sino una página en blanco.
- 23 Jun 2026en exclusiva en la plataforma; se hizo público 37 días después
- 108,000/speticiones por segundo, unos nueve mil millones al día
- 98.6%tasa de acierto de caché — quedan unos 126 millones de peticiones diarias que la rebasan
- 1.1 TBel espejo git para el que GitHub ya no podía generar descargas
| Solidez | Lo que se afirma |
|---|---|
| Documentado | Un navegador al que se le da integrity="sha384-…" calcula el hash de lo que recibe y, si no 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. |
| Confirmado por el operador, no verificable aquí | La fecha del cambio; 108,000 peticiones por segundo y nueve mil millones al día; más de 330 centros de datos; una tasa de acierto del 98.6%; uso en cerca del 12% de todos los sitios web y el 48.3% del mercado de CDN de JavaScript. Todo ello es Cloudflare informando sobre Cloudflare, sin metodología y sin atribución. |
| Confirmado, y poco habitualmente franco | Un intento de migración anterior fue revertido. Reprocesar los paquetes antiguos producía archivos correctos pero no idénticos byte a byte, de modo que sus hashes de integridad cambiaban. El catálogo se copió entonces de KV a R2 tal cual. |
| Afirmado, sin cuantificar | Retirar la antigua tubería “cerró todas las vulnerabilidades de cdnjs abiertas recientemente”. Sin recuento, sin identificadores, sin gravedades, sin fechas — en un texto que por lo demás es preciso hasta el dígito. |
| Afirmado, y desmentido en el mismo texto | Cada 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, por errores del sistema antiguo. Ambas frases están en el texto; llevar una sin la otra lo tergiversa. |
Cronología
Cómo se llegó hasta aquí quince años, y un paso que no se puede fechar
- 2011Nace como espejo comunitario. Ryan Kirkman y Thomas Davis crean cdnjs cuando npm apenas tiene un año y “basta con poner una etiqueta <script>” es como la web entrega JavaScript. Cloudflare empieza a alojarlo gratis meses después.
- 2019Cloudflare asume el mantenimiento del proyecto, no solo su alojamiento.
- 2020La entrega se muda; la publicación no. Los archivos empiezan a servirse desde Workers y KV con un origen físico detrás, y cada recurso se precomprime con Brotli y gzip. La tubería que vigila npm y GitHub se queda en Google Cloud, porque Workflows, Queues, Durable Objects, R2 y Containers aún no existen.
- 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. El texto no le pone fecha alguna, y por eso figura aquí y no en su lugar cronológico — y es lo más instructivo de todo el artículo.
- antes de jun 2026Se elevan dos techos de la plataforma en lugar de sortearlos. Las subpeticiones de Workers pasan de 1,000 a 10 millones por invocación en planes de pago; los pasos de Workflow, de 1,024 a 10,000, configurables hasta 25,000.
- 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.
- 30 jul 2026Se publica el relato, 37 días después del cambio.
Un paso no tiene fecha, y es el que importa
Todo lo demás está fechado al día. 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.
El argumento
Lo que sostiene Cloudflare comer de tu propia comida, y la frase a la que apunta todo
La palabra que emplea el 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. La frase final dice justo eso — “probablemente pueda ejecutar lo que sea que estés construyendo”. Conviene separar las dos mitades. La evidencia es real: se elevaron dos techos de la plataforma porque cdnjs chocó con ellos, y esas subidas rigen para todo cliente de pago, no solo para cdnjs. La inferencia es un argumento comercial, y el texto no finge lo contrario. Lo llamativo es que Cloudflare también dice sin rodeos que esto no era un problema de rendimiento. “No migramos porque cdnjs fuera lento. Migramos porque queremos seguir mejorándolo.” A la arquitectura antigua se le reconocen un 98% de acierto de caché, miles de millones de peticiones y ninguna caída. La queja era que cambiar algo obligaba a coordinar despliegues entre funciones de GCP, una máquina virtual y Cloudflare — y que cuando algo fallaba a medias, nada en el sistema se enteraba. Una versión podía escribirse en 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. No había alerta para eso, y el texto explica bien por qué no podía haberla: ningún componente conocía el estado de la tubería entera.
- 26funciones en la nube solo para consultar npm — una por letra del alfabeto, cada una con su despliegue y sus registros.
- 274entradas de
.gitignoremantenidas a mano que bloquean versiones rotas o con numeración extraña — la expresión del propio texto es “un cementerio documentado”. - 10,000×el aumento del techo de subpeticiones de Workers, de 1,000 a 10 millones — un cambio de plataforma, no de cdnjs.
Lo que añaden otros
El mecanismo que el texto da por sabido por qué un archivo regenerado es una página en blanco, no una diferencia
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.
- Fuente: MDN. Esta es toda la razón por la que hubo que deshacer el primer intento.
- Una página puede fijar un hash:
Determinismo
La salida de un minificador no es estable entre versiones
- Volver a ejecutar las mismas herramientas sobre la misma entrada 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.
Lo que sigue sin saberse
Cuántos hashes almacenados son hoy incorrectos
- Cloudflare dice que sigue trabajando para que los hashes almacenados coincidan con la realidad, “por errores del sistema antiguo”.
- No se da ninguna magnitud. Un hash almacenado incorrecto en un archivo que alguien fijó es una página rota en algún sitio.
- Es la incógnita de mayor consecuencia de esta página.
| Antes | Ahora | Qué cambió en realidad |
|---|---|---|
| Workers KV + un repositorio de GitHub | R2 como única fuente de verdad | Antes ninguno de los dos almacenes era autoritativo, y cuando divergían no había forma limpia de reconciliarlos. R2 además no tiene límite práctico de tamaño, así que los mapas de código y los paquetes de fuentes que no cabían en KV conviven ya con todo lo demás. |
| Una cadena de funciones activadas por eventos de bucket | Workflows, con Queues y un contador en un Durable Object | El 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. |
| Dos sistemas de registro sin clave común | Una plataforma, una traza | El fallo que esto pretende detectar no es una caída sino un éxito parcial: una versión que escribió en un almacén, no llegó al otro sin avisar y se sirvió sin problemas durante semanas. |
| Un origen físico detrás del borde | caché → R2 → DigitalOcean Spaces | DigitalOcean llevaba años patrocinando el sitio de cdnjs y ahora replica también el almacenamiento: arquitectónicamente una copia de recuperación, operativamente un respaldo en vivo. Un origen alojado por Cloudflare sigue en la cadena hasta que termine el volcado desde GitHub. |
Conclusión
Qué llevarse de todo esto una lección transferible y tres cosas que conviene sostener con holgura
Copia los bytes; no los reconstruyas
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ó.
Completa en el sentido del titular, inacabada en un aspecto declarado
cdnjs sí funciona sobre la plataforma. También sigue habiendo un origen alojado por Cloudflare en la cadena de entrega hasta que el volcado desde GitHub llegue a R2. Lo dice el propio texto, y un artículo que lo limara estaría contando el titular y no el artículo.
Sostén las cifras con holgura, y la afirmación de seguridad con la mayor de todas
Cada número operativo de aquí es Cloudflare informando sobre Cloudflare, sin metodología y sin atribución — esa es la condición normal de un texto de ingeniería, no un escándalo. Pero “cerró todas las vulnerabilidades de cdnjs abiertas recientemente” no lleva recuento, ni identificador, ni gravedad, en un texto por lo demás preciso hasta el dígito. Toma la subida de 10,000× en las subpeticiones como la prueba sólida; toma esa frase como lo más flojo del artículo.