jsDelivr

jsdelivr.com · Egress and tunnels, Storage · 3 records · JSON

jsDelivr (npm + GitHub proxy CDN) Storage★ qualifiesemail?card?Rper-object-cap
jsDelivr as the free CDN layer over GitHub repos Storagecaveatemail?card?Rper-object-cap
jsDelivr Egress and tunnelsfails: quotaanonymousno cardRper-object-cap

jsDelivr (npm + GitHub proxy CDN) Storage

★ qualifiesemail?card?Rper-object-cap

www.jsdelivr.com · registry · storage/jsdelivr · JSON · compare

Free tier	No storage quota of its own — it is a serving and permanence layer over npm and GitHub, so the quota is whatever the origin package holds. Hard limits: packages >150 MB and (for GitHub) single files >20 MB are refused by default, raisable on request. unit MB; metered on stored-bytes
Price	none stated
Per-object cap	single files >20 MB (20000000 bytes)
Retention	\| Retention is stronger than the origin: 'Previously served immutable files may be retained in permanent storage even after upstream deletion
Egress	Fully free and explicitly unmetered.
Identity	email (placeholder) not published
Limits	per-object-cap single files >20 MB source 150 MB per npm package, 20 MB per single GitHub file (both default, raisable via GitHub issue). Rate limiting applies to purge, not to reads.
Binding	per-object-cap the per-object cap sets the shard size and therefore the object count; it bounds the total more tightly than any headline quota
Interface	rest rest
Tooling	Plain GET on cdn.jsdelivr.net/npm/<pkg>@<ver>/<path> and /gh/<owner>/<repo>@<ref>/<path>. No client needed. Cache-purge API exists (email-gated).
Composes with	Chains onto npm (see npm candidate) or onto GitHub repos: publish the blob as an npm tarball, then serve it from jsDelivr at a URL with 1-year immutable cache and no bandwidth charge. This upgrades any npm/GitHub bulk store from 'downloadable' to 'CDN-served with free egress', which is exactly the client's 1 TiB/day serving workload.
Reliability	Retention is stronger than the origin: 'Previously served immutable files may be retained in permanent storage even after upstream deletion. We do not accept removal requests simply because a package or version was unpublished, deleted upstream, or is no longer needed.' Once a URL has been fetched it keeps working after you delete the npm package — that is a genuine cold-archive property. Counter-risk: a 150 MB package cap means a naive >150 MB npm tarball 403s ('Package size exceeded the configured limit of 150 MB') even though npm itself accepted it.
Notes	No storage quota of its own — it is a serving and permanence layer over npm and GitHub, so the quota is whatever the origin package holds. Hard limits: packages >150 MB and (for GitHub) single files >20 MB are refused by default, raisable on request.
Evidence rung	reported One page read moves it to documented.
Checked	2026-10-21 (inherited); stale on 2026-11-04
Parsed numbers	`$.limits[0].value` limit:per-object-cap 20.0 MB

Evidence (5)

date	source	what it proved
2026-10-21	www.jsdelivr.com/about	'no bandwidth limits or premium features and its completely free to use by anybody'
2026-10-21	github.com/jsdelivr/jsdelivr/blob/master/Terms%20of%20Use.md	'no limits on bandwidth or number of requests'; 'Previously served immutable files may be retained in permanent storage even after upstream deletion'
2026-10-21	github.com/jsdelivr/jsdelivr	(README) — 'Packages larger than 150 MB or single files larger than 20 MB (in the case of GitHub) are not supported by default'
2026-10-21	cdn.jsdelivr.net/npm/left-pad@1.3.0/package.json	probe: GET -> 200, Access-Control-Allow-Origin: *, Cache-Control: public, max-age=31536000, s-maxage=31536000, immutable, Server: cloudflare
2026-10-21	cdn.jsdelivr.net/npm/onnxruntime-node@1.20.1/bin/napi-v3/win	probe: GET -> 403, body 'Package size exceeded the configured limit of 150 MB.' (confirms the cap is real and enforced at fetch time)

Unknown or withheld values (5)

$.free_tier.notes process
$.identity_cost.detail defaulted
$.identity_cost.kind identity-defaulted
$.per_object_cap.notes not-extracted
$.retention.notes not-extracted

jsDelivr as the free CDN layer over GitHub repos Storage

caveatemail?card?Rper-object-cap

www.jsdelivr.com · paas · storage/jsdelivr-as-the-free-cdn-layer-over-github-repos · JSON · compare

Free tier	Not storage, it is the egress answer for the serving workload: "there are no limits on bandwidth or number of requests" (the provider), with soft limits of 10,000 actively accessed files and 100,000 files per repository. unit objects; metered on stored-bytes
Price	none stated
Per-object cap	per file \| 20 MB (20000000 bytes)
Retention	\| Immutable: 'Previously served immutable files may be retained in permanent storage even after upstream deletion' — deletion upstream does not remove it from jsDelivr
Egress	Unmetered, and immutable-cached at the edge: probed 'Cache-Control: public, max-age=31536000, s-maxage=31536000, immutable' plus Access-Control-Allow-Origin: *. This cleanly covers the 500 GB-1 TiB/day serving workload from a single repo without touching GitHub's own edge.
Identity	email (placeholder) not published
Limits	per-object-cap per file \| 20 MB source Git repo files only — release assets are NOT served (probed: /gh/cli/cli@v2.102.1/dist/README.md -> 404). ~20 MB effective per-file ceiling for the GitHub proxy (the git-unlimited-storage README states 'jsDelivr per file \| 20 MB'); hard per-file/per-package caps are undocumented and enforced at request time. Does not serve the >2 GiB release assets, so the serving path for big objects stays on GitHub's own Fastly edge.
Binding	per-object-cap the per-object cap sets the shard size and therefore the object count; it bounds the total more tightly than any headline quota
Interface	rest rest
Tooling	URL pattern https://cdn.jsdelivr.net/gh/USER/REPO@TAG/path — no client needed, no auth, no config. Purge API exists for cache busting.
Composes with	Serving layer only: pair it with Releases (storage) or a git repo (small files). One repo backs 1 TiB/day because the edge absorbs repeats with a 1-year immutable TTL.
Reliability	Immutable: 'Previously served immutable files may be retained in permanent storage even after upstream deletion' — deletion upstream does not remove it from jsDelivr. Extension blocklist exists; binaries with unusual extensions can be refused.
Notes	Not storage, it is the egress answer for the serving workload: "there are no limits on bandwidth or number of requests" (the provider), with soft limits of 10,000 actively accessed files and 100,000 files per repository.
Evidence rung	reported One page read moves it to documented.
Checked	2026-10-21 (inherited); stale on 2026-11-04
Parsed numbers	`$.limits[0].value` limit:per-object-cap 20.0 MB

Evidence (3)

date	source	what it proved
2026-10-21	www.jsdelivr.com/terms/acceptable-use-policy	'there are no limits on bandwidth or number of requests'; soft limit '100 000' files per repository
2026-10-21	withheld	probe: GET cdn.jsdelivr.net/gh/jquery/jquery@3.7.1/dist/jquery.min.js -> 200, Cache-Control: public, max-age=31536000, s-maxage=31536000, immutable, Access-Control-Allow-Origin: *
2026-10-21	withheld	probe: GET cdn.jsdelivr.net/gh/cli/cli@v2.102.1/dist/README.md -> 404 (release assets not mirrored)

Unknown or withheld values (7)

$.evidence[1].url private-url
$.evidence[2].url private-url
$.free_tier.notes process
$.identity_cost.detail defaulted
$.identity_cost.kind identity-defaulted
$.per_object_cap.notes not-extracted
$.retention.notes not-extracted

jsDelivr Egress and tunnels

fails: quotaanonymousno cardRper-object-cap

www.jsdelivr.com/ · CDN for package content · egress/jsdelivr · JSON · compare

Free tier	free CDN for npm and GitHub content only unit none; metered on downloaded-bytes
Price	none stated
Per-object cap	package-file sizes; the per-file class limit could not be read
Retention	not applicable
Egress	no bandwidth cap found on a first-party page
Identity	anonymous no account to read from the CDN
Limits	per-object-cap serves npm and GitHub content only, at package-file sizes source
Binding	per-object-cap
Interface	rest https://cdn.jsdelivr.net/npm/PKG@VER/FILE
Tooling	curl
Composes with	not a general egress path: the bytes must already be in a package registry, so it composes with npm and not with the client's corpus.
Reliability	the policy page at /policy returned 404 on 2026-10-22; /terms and /about resolve
Notes	The 'no bandwidth cap' claim in circulation is third-party and the page that would settle it is 404.
Evidence rung	reported
Checked	2026-10-23 (live); stale on 2026-11-06

Evidence (1)

date	source	what it proved
2026-10-22	probe:https://www.jsdelivr.com/policy	404 on 2026-10-22, so the per-file limit and the no-cap claim could not be read first-hand

More fields (3)

{
 "stale_after_days": 180,
 "bytes_transit": "yes",
 "transit_note": "the CDN serves package files from its edge"
}