GitHub Releases (release assets)
- Free allowance
- No total quota. Docs verbatim: 'Up to 1000 release assets may be associated with a single release.
- Verdict
- ★ qualifiesusable as stated; the read path was probed
- Cost
- free tier
- Identity
- emailno card, no phone
- Binding limit
- per-object-cap2 GiB per file
- Evidence
- documented12 sources; a first-party page was read and the sentence quoted
- Freshness
- stale on 2026-11-21checked 2026-10-21 (inherited); stale on 2026-11-21
| Free tier | No total quota. Docs verbatim: 'Up to 1000 release assets may be associated with a single release. Each file included in a release must be under 2 GiB. There is no limit on the total size of a release, nor bandwidth usage.' Per-file ceiling is the Git LFS max for the plan: GitHub Free 2 GB, Pro 2 GB, Team 4 GB, Enterprise Cloud 5 GB. unit GiB; metered on unstated |
|---|---|
| Price | none stated |
| Limits |
2 GiB per file (2 GB on Free, 4 GB Team, 5 GB Enterprise). 1000 assets per release. This is the ONLY cap found in the entire CI/CD field that is not a quota. No expiry: releases persist until deleted. Upload is authenticated; download is fully anonymous. |
| Identity | email A free personal account needs an email address, verified by email, or a Google or Apple social login; uploading a release asset needs write permission on the repository, and downloading one needs no account. |
| Egress | Free and unmetered. Docs: 'We don't limit the total size of the binary files in the release or the bandwidth used to deliver them.' Served 302 -> release-assets.githubusercontent.com with no auth. |
| Per-object cap | 2 GiB per file (2147483648 bytes) |
| Retention | no expiry is stated for release assets, and the documentation states no limit on the total size of a release |
| Interface | rest, rclone, cli rest |
| Tooling | REST POST /repos/{owner}/{repo}/releases + upload asset endpoint (Accept: application/octet-stream); gh CLI 'gh release upload'; rclone has no release backend, but plain curl/Python is a complete client. Proxy/wrapper repos: iBug/cf-github-releases (21 stars, Cloudflare Workers download site), kdrag0n/github-releases-proxy (8 stars), watermint/toolbox has a github-release-asset-upload command (87 stars). |
| Composes with | UNBOUNDED: unlimited free repos (GitHub Free = unlimited public and unlimited private repos) x unlimited releases per repo x 1000 assets per release x <2 GiB per asset. 10 repos x 50 releases x 1000 assets x 2 GiB = 1 PiB nominal; the real constraint is API/upload time, not space. Also chain with Cloudflare in front (cf-github-releases) for a clean CDN domain. |
| Reliability | Very stable; assets are immutable per release. Deleting a release or repo destroys the assets. Uploading >1000 assets to one release requires multiple releases — plan release granularity, not asset count. |
| Evidence note | documented The page states the number in the record; the claim is documented, not measured. |
| Parsed numbers |
|
Evidence 12
| date | source | what it proved |
|---|---|---|
| 2026-10-22 | docs.github.com/en/repositories/releasing-projects-on-github | 2 GiB per release asset and 1,000 assets per release, no bandwidth limit. Re-read https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases: HTTP 200, 3494 bytes, sha256 422579c390d76156. Quoted: ease assets](/en/rest/releases). ## Storage and bandwidth quotas Up to 1000 release assets may be associated with a single release. Each file included in a release must be under 2 GiB. There is no limit on the total size of a release, nor bandwidth usage. |
| 2026-10-21 | docs.github.com/en/repositories/releasing-projects-on-github | 'There is no limit on the total size of a release, nor bandwidth usage' |
| 2026-10-21 | docs.github.com/en/repositories/working-with-files/managing- | 'We don't limit the total size of the binary files in the release or the bandwidth used to deliver them', and LFS max-file table (Free 2 GB / Team 4 GB) |
| 2026-10-21 | github.com/cli/cli/releases/download/v2.80.0/gh_2.80.0_linux | probe: curl -L -r 0-1023 -> 302 to release-assets.githubusercontent.com, then 206 with 1024 bytes, no auth |
| 2026-10-21 | source not published | probe: 6 parallel anonymous GETs of a release asset -> 302 302 302 302 302 302 (no throttling observed) |
| 2026-11-01 | docs.github.com/en/get-started/start-your-journey/creating-a | an account costs an email address with verification, and the page offers Google or Apple social login; nothing institutional is required |
| 2026-11-01 | docs.github.com/en/get-started/start-your-journey/creating-a | the free account and its social-login alternatives; the releases page states that only write permission manages releases |
| 2026-11-01 | docs.github.com/en/repositories/releasing-projects-on-github | the docs state no total-size or bandwidth limit and give no expiry for an asset |
| 2026-11-01 | docs.github.com/en/repositories/working-with-files/managing- | the total is unlimited while each file is bound by the plan's Git LFS maximum, which the LFS page tabulates |
| 2026-11-01 | docs.github.com/en/repositories/releasing-projects-on-github | the release quotas as served on 2026-11-01 |
| 2026-11-01 | docs.github.com/en/repositories/releasing-projects-on-github | all four headline numbers of the record in one sentence: 1000 assets, 2 GiB per file, no total-size limit, no bandwidth limit |
| 2026-11-01 | probe: https://github.com/cli/cli/releases/download/v2.80.0/gh_2.80.0_linux_amd64.tar.gz | an anonymous ranged GET of a release asset answers 302 to release-assets.githubusercontent.com then 206 with Content-Range bytes 0-1023/18079593, no credentials |
More fields 1
| verified | [{"url": "https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases","date": "2026-10-22","via": null,"http_status": 200,"bytes": 3494,"sha256": "422579c390d76156b65ddf5b5f771de58638f91b1c5fc3c624b7153572cc32c1","pattern_found": true,"what_changed": "no change: the page still states the claim","capture": null}] |
|---|
Unknown values 1
- retention notes: the field may be stated in a source that was not read