cdnjs/cdnjs: the robot-only asset repo behind the cdnjs CDN

What cdnjs/cdnjs actually is, and who it is not for

The name causes most of the confusion. People searching for cdnjs usually want the CDN: a URL they can drop into a script tag. The cdnjs/cdnjs repository is something else. Its README calls it "the robot-only repository for cdnjs, where all the library assets that are hosted on cdnjs are stored." The JSON files that control which libraries are hosted live in a separate repository, cdnjs/packages, described in the same README as the "human" one.

So the audience for this repository is narrow. Mirror operators who pulled assets from it. Anyone auditing where the bytes on cdnjs.com come from. Not application developers, and not library authors. The README states plainly that pull requests are no longer accepted here and points contributors to cdnjs/packages or the other cdnjs repositories: static-website for the site, api-server for the API, brand for branding, cf-stats for monthly CDN stats.

The repository layout matches that role. The top level holds .github/, .gitignore, CONTRIBUTING.md, LICENSE, README.md, an ajax/ directory, and a last-sync file. That last-sync entry is the tell: this was a mirroring target, not a source of truth for humans to edit.

Asset storage vs package metadata: the two-repository split

cdnjs separates two things that npm-style registries keep together. The assets themselves (the built JavaScript, CSS and font files served from the CDN) sit in this repository. The metadata that decides which libraries exist, which versions are published, and which files are exposed sits in cdnjs/packages as JSON.

That split explains the labels in the README. Robot-only means automated processes write here; human means people open pull requests there. It also explains why a library author cannot fix a bad version by editing a file in this repository. The change belongs in the packages repository.

The README documents a second consequence: size. It states that this repository "is no longer updated as it became too large," and that as part of the migration to Cloudflare's Developer Platform, "cdnjs is now powered by a Cloudflare R2 bucket." The asset store moved out of Git and into object storage. The repository remains as a historical record and, for a while, as a sync target that no longer receives new content.

No install step: where cdnjs says to get the assets

There is no install step for this repository, and none is needed for the CDN either. The README gives no npm package, no CLI and no build command. It points instead at https://cdnjs.com for the site, cdnjs/api-server for the API, and cdnjs/packages for the library metadata. Assets are consumed by URL, so nothing is added to a project's dependency list.

The practical consequence is that the version you get is the version you write into the URL. The README does not document a versioning scheme, a latest-version alias, or an integrity-hash mechanism, so anything beyond a pinned path has to be confirmed against the cdnjs.com catalog or the API server repository. If you need to know which versions exist for a given library, this repository is not the place the README sends you.

The mirror problem: what breaks when a sync source freezes

Mirrors are the one group with a real operational stake in this repository. The README addresses them directly: "If you operate a mirror of cdnjs and were reliant on this repository for syncing, please open an issue to request read-only S3 credentials for the cdnjs R2 bucket." A mirror-request issue template is linked with the label Mirror Request.

Read that carefully. The repository still exists and still has a recent last push, but the README states it is no longer updated and that the CDN is powered by R2. A mirror that keeps pulling from Git will keep receiving whatever the repository last held, and will silently fall behind on new library versions rather than fail loudly. There is no documented rollback path, no deprecation window, and the README does not say how long the old repository will remain readable. It also does not document the R2 bucket layout, so a mirror operator cannot plan the migration purely from this README; the request issue is the documented first step.

This is the clearest case where the repository is the wrong tool. If your deployment pipeline treats cdnjs/cdnjs as a pinned dependency or a vendored asset directory, the freeze turns that pipeline into a snapshot.

cdnjs vs jsDelivr and unpkg: different answers to the same question

The three names come up together because they solve the same problem: serving front-end files from a CDN. The approaches differ in where the files come from.

unpkg serves packages straight out of npm, so what you get is whatever the maintainer published to the npm registry, addressed by package name and path. jsDelivr also serves npm content and adds GitHub sourcing, which means it can serve files from a repository tag or commit. cdnjs takes a third route: libraries are curated into the cdnjs catalog, with metadata in cdnjs/packages and assets in this repository, and the served copies are the ones cdnjs accepted rather than whatever npm holds. That curation is the difference. It gives a consistent catalog and a stable URL scheme, and it means a library that is not in the catalog is simply not available, no matter what is on npm.

A second difference is now operational. The README states that cdnjs assets are served from a Cloudflare R2 bucket, while the npm-based CDNs read from their own registries and repositories. For most users that distinction is invisible. For mirror operators it is the whole story, because the sync source changed from a Git repository to an object store.

Licence: MIT for the repository, per-library for the assets

The README draws a line that is easy to miss. The cdnjs repository itself is published under the MIT license, and the LICENSE file sits at the top level. The assets are a different matter: "Each library is released under its own license." The MIT badge in the README covers the repository, not jQuery, not Font Awesome, not anything else in the catalog.

In practice this means the licence you must satisfy is the one attached to the library you load, and cdnjs is a distribution channel rather than a relicense. A permissive library stays permissive; a copyleft library keeps its terms. The README does not describe how licences are recorded per library, so if you need that detail, the cdnjs/packages metadata is where it would have to live. None of this is legal advice; it is a description of what the README states.

Maintenance and upgrade cost after the R2 migration

The last push to this repository was on 2026-09-03, so it is not abandoned in the sense of a dormant project. It is frozen by design. The README states the reason: the repository became too large, and the assets moved to a Cloudflare R2 bucket as part of the migration to Cloudflare's Developer Platform.

Upgrade cost therefore depends on which side of the split you are on. If you consume the CDN by URL, there is nothing to upgrade; the URLs keep working and the catalog keeps moving through cdnjs/packages. If you mirror from Git, your cost is a migration to S3-compatible access, starting with the mirror-request issue. If you contribute libraries, your cost is zero here because this repository accepts no pull requests, and your work belongs in cdnjs/packages.

The honest assessment: this repository is a historical artifact with a live README. Its value now is documentation of where cdnjs moved and what mirror operators must do about it. Treating it as an active asset store will produce a stale mirror, and the README gives no indication that this will change.

Editorial conclusion

Adopt the cdnjs CDN itself if you want free, MIT-licensed hosting of front-end libraries and are willing to link to cdnjs.com URLs. Do not adopt this repository as a dependency, a build input, or a sync source: the README states it is no longer updated and that pull requests are no longer accepted, and the assets now live in a Cloudflare R2 bucket. If you run a mirror, verify your sync path first by opening the mirror-request issue described in the README and requesting read-only S3 credentials; if you contribute a library, verify instead that you are working in cdnjs/packages.

Frequently asked questions

Official sources

1. cdnjs/cdnjs on GitHub
2. Issues
3. License: MIT
4. Project website
5. README