I have 100+ GitHub repos and pay $5/month for GitHub Pro. Worth it.
GitHub allows 100,000 repos per account, with a recommended maximum of 10 GB for each repo’s .git folder. Multiply those figures and you get 1 PB on paper, alongside my $5/month bill.
But large repos still make clones slower. I’d keep code and ordinary images together, and put videos and other large files that don’t need code versioning elsewhere. An agent should download those only when a task needs them.
When to use Git LFS
GitHub recommends keeping repos below 1 GB ideally, and strongly recommends below 5 GB.
For large assets that need versioning alongside code, Git LFS keeps a pointer in Git and stores the file separately.
Free and Pro include 10 GiB of LFS storage and 10 GiB of monthly download bandwidth, shared across all your repos. Ordinary images committed directly to Git don’t use this allowance.
Overages cost $0.07/GiB-month for storage and $0.0875/GiB downloaded, in USD. Each new version uses the full file size again; downloads count against the repo owner’s bandwidth.
And removing a file doesn’t reclaim its remote LFS storage. GitHub documents deleting and recreating the repo, or contacting Support to purge objects.
I’d reserve LFS for assets whose versions need to match the code.
R2 or S3 for the large files
For files I only need to store or distribute, I’d use a bucket.
USD list prices for S3 Standard in US East (N. Virginia) and R2 Standard:
| Charge | Amazon S3 Standard | Cloudflare R2 Standard |
|---|---|---|
| Storage per GB-month | $0.023, first 50 TB | $0.015 |
| Internet downloads per GB | $0.09, first paid tier | $0 |
| 1 million GET requests | $0.40 | $0.36, Class B |
| 1 million PUT requests | $5 | $4.50, Class A |
R2 includes 10 GB-month of storage, 1 million Class A operations and 10 million Class B operations monthly. Keeping 100 GB costs $1.35/month in storage after that allowance.
Free internet downloads make R2 my preference for website media and files agents fetch repeatedly. Buckets are private by default; agents can use credentials or expiring signed URLs. For public website media, enable access through a custom domain.
S3 suits work already running in AWS, where direct same-region transfers between S3 and AWS services are free. AWS also includes 100 GB of monthly internet transfer out, shared across services and regions.
I’d keep the object key, version, checksum and download command in the repo so agents can fetch the right files.
What about iCloud?
I already pay for 2 TB of iCloud+. That’s where I’d keep personal files for my own devices. For a cloud agent or a public website, I’d use a bucket.
Apple developer membership also includes up to 1 PB of free CloudKit storage per app for public app data. Web apps and servers can access it through CloudKit APIs, but that requires app integration. I’d consider it for an app already using CloudKit.
Monorepos need a reason
With room for 100,000 repos, I’d split independent apps and tools into smaller repos, each containing what it needs. That gives an agent fewer unrelated files to search and a focused set of build and test commands.
Shared code and changes across tightly coupled packages can still justify a monorepo.
Each project’s AGENTS.md can explain which assets belong in Git and how to fetch the rest.