GitHub Pages limits in 2026 are a recommended 1 GB site size, a soft 100 GB bandwidth cap per month, and a soft 10 builds per hour. These numbers come straight from GitHub’s official Pages documentation, and they matter because crossing them doesn’t mean a bill, it means throttling.
GitHub Pages limits at a glance
Here’s the full reference table before you dig into each section. All figures are pulled directly from GitHub’s documentation, not estimates.
| Limit | Value | Hard or soft |
|---|---|---|
| Published site size | 1 GB (recommended) | Soft |
| Source repository size | 1 GB (recommended) | Soft |
| Bandwidth | 100 GB per month | Soft |
| Builds | 10 per hour (Jekyll pipeline) | Soft |
| Deployment timeout | 10 minutes | Hard |
| Sites per account | 1 user/org site + unlimited project sites | Structural |
| Custom domain | Free on every plan | N/A |
“Soft” means GitHub doesn’t cut your site off automatically the second you cross it. It’s a threshold GitHub monitors, not a hard wall. Keep that distinction in mind as you read the rest of this guide.
Bandwidth limit: 100 GB per month
The number most people search for first is the GitHub Pages bandwidth limit, and the answer is a soft cap of 100 GB per month. That covers every visitor request to your site’s HTML, CSS, JS, images, and any other assets served from the Pages domain.
100 GB sounds generous for a documentation site or a personal portfolio, and for most of those it is. A page with modest images serving a few thousand visitors a month stays well under the ceiling. The risk shows up when a post goes viral, a launch gets picked up on social media, or you’re embedding large media files directly on the page.
There’s no dashboard meter showing you real-time bandwidth consumption on GitHub Pages, which makes it hard to know exactly where you stand until you’re already close to the edge.
Storage limit: 1 GB site and repository size
GitHub recommends keeping both your source repository and your published site under 1 GB. These are two separate numbers that often move together, since your published site is typically built from files in that same repository.
There’s no officially documented per-file size limit specific to Pages, but GitHub’s general repository limits still apply, and individual files over 100 MB will hit friction in Git itself before Pages even becomes the bottleneck. In practice, the fastest way to blow past 1 GB is unoptimized media: uncompressed screenshots, embedded video files, or large PDF downloads sitting in your repo.
If your project is a lightweight portfolio, a docs site, or a handful of static HTML pages, 1 GB is rarely a concern. If you’re hosting a media-heavy site or a large asset library, this is usually the first limit you’ll actually hit, well before bandwidth becomes an issue.
Build limits: 10 builds per hour and a 10-minute timeout
If you push frequently, the GitHub Pages build minutes question comes up fast. The default Jekyll-based build pipeline enforces a soft limit of 10 builds per hour. Push an eleventh commit within that hour and your build may queue or get delayed rather than failing outright.
This limit does not apply if you deploy through a custom GitHub Actions workflow instead of the default Pages build process, which is one reason many teams running Astro, Hugo, or Eleventy sites switch to Actions-based deploys.
Separately, any single deployment times out after 10 minutes, regardless of which pipeline triggered it. A build that hangs on a slow dependency install or a large asset processing step needs to finish inside that window or it fails.
Custom domains: free, but watch for DNS gotchas
A GitHub Pages custom domain is free on every plan, including public repositories on the free tier. You point a CNAME record at your username.github.io address for a subdomain, or configure A records for an apex domain, and GitHub provisions SSL automatically once verification completes.
The gotcha isn’t cost, it’s configuration. Apex domains (example.com without www) require A records pointing at GitHub’s IP addresses, which are less resilient than a CNAME and need manual updates if GitHub ever changes them. SSL provisioning can also take longer than expected right after adding a domain, and switching from HTTP to HTTPS enforcement sometimes needs a manual toggle in repository settings. None of this is a dealbreaker, but it’s more manual than a platform that auto-detects and provisions everything for you. If you want the fuller walkthrough on DNS records and SSL, our guide to adding a custom domain to a static site covers CNAME, ALIAS, and A record setup in detail.
Usage policy restrictions you should know
Beyond the technical numbers, GitHub’s Pages usage policy sets boundaries on what the service is for. It’s worth reading because these aren’t limits you can optimize around, they’re rules.
- No commercial ventures. GitHub explicitly states Pages shouldn’t be used for e-commerce operations or SaaS products.
- No sensitive transactions. Don’t process passwords, credit card numbers, or similarly sensitive data through a Pages site.
- Standard GitHub Terms of Service apply. Prohibited content includes things like get-rich-quick schemes and sexually obscene or violent material.
- Rate limiting can apply independently of the soft caps above. If you trip GitHub’s broader rate limits, you’ll see HTTP 429 responses with details in the response.
For a personal site, a portfolio, or open-source documentation, none of this is a practical constraint. It becomes relevant the moment your static site is actually a storefront or a product, not a page about one.
What actually happens when you exceed a limit
The honest answer: nothing dramatic, usually. GitHub Pages limits are soft by design, and the platform is built to be forgiving of occasional spikes rather than punitive.
In practice, exceeding bandwidth or build frequency tends to look like this: your site keeps working, but GitHub may throttle delivery during heavy load, and you might receive an email flagging the usage. There’s no usage-based billing to worry about, no surprise invoice. GitHub Pages doesn’t have a paid tier that scales with traffic the way cloud bandwidth does elsewhere.
The 10-minute deployment timeout is the one hard stop in this list. If a build doesn’t finish in that window, it fails and you’ll need to fix whatever is slowing it down (large dependency installs are the usual culprit) and push again.
Consistent, sustained overages across bandwidth or storage are more likely to draw attention from GitHub than a single busy week. If your project has genuinely outgrown a documentation-site scale of traffic, that’s a signal worth acting on rather than waiting for an email.
How to stay under the limits
Most GitHub Pages sites never come close to these ceilings, and a few habits keep it that way even as a project grows.
Compress and resize images before committing them. This is the single biggest lever for both the 1 GB storage cap and bandwidth usage, since unoptimized screenshots and photos are the most common source of bloat on static sites.
Host large media externally. Videos, large PDFs, and big downloadable assets are better served from a CDN or object storage (Cloudflare R2, Backblaze B2, or similar) with a link from your Pages site, rather than committed to the repo directly.
Put a CDN in front of high-traffic pages. Cloudflare’s free tier can cache your Pages site at the edge, absorbing traffic spikes before they count against your GitHub bandwidth.
Switch to a GitHub Actions deploy if you’re hitting the 10-builds-per-hour cap during active development. It removes that specific constraint entirely.
Audit repo size periodically. Old commits with large binary files still count toward repository size even after you’ve replaced them, since Git history retains everything unless you actively rewrite it.
When GitHub Pages stops being the right tool
GitHub Pages is genuinely a solid, free option for a lot of use cases: open-source documentation, personal portfolios, small project sites. If you’re comfortably under 1 GB and 100 GB of bandwidth, and you’re fine with a Git-only workflow, there’s no strong reason to leave.
Where it starts to feel restrictive is the workflow itself, not just the numbers. Every change means a commit and a push, there’s no drag-and-drop option, and non-technical collaborators hit a wall fast. If that friction (rather than the storage or bandwidth ceiling) is what’s bothering you, our GitHub Pages alternatives guide compares seven platforms that solve different pieces of that problem. And if you’re weighing this free tier against the other big one, our Vercel pricing and free tier limits guide runs the same exercise for Vercel. For the full landscape beyond Git-based hosts, our best free website hosting sites comparison puts these free tiers next to builders and traditional hosts.
For non-technical creators specifically, Supadrop takes a different approach: no Git, no build pipeline, no repository at all. You drag your files onto the dashboard and the site is live, with no build-minute caps to think about. It’s not a replacement for GitHub Pages’ open-source use case, but if you’re a freelancer, a small business owner, or someone exporting a site from an AI builder and just want it live without learning Git, it removes that specific piece of friction.
GitHub Pages’ limits (1 GB storage, 100 GB bandwidth, 10 builds/hour) are generous enough for most personal and documentation sites, and soft enough that crossing them briefly won’t take your site down or cost you money. The real question isn’t whether you’ll hit a wall on the numbers, it’s whether the Git-only workflow still fits how you want to publish.
Frequently asked questions
What is the GitHub Pages bandwidth limit?
GitHub Pages has a soft bandwidth limit of 100 GB per month, according to GitHub’s official documentation. It is a soft limit, meaning GitHub does not cut off your site the moment you cross it.
High-traffic sites may see throttling during peak load, or an email from GitHub asking them to reduce usage. There’s no usage-based billing attached to this limit, so exceeding it doesn’t mean a surprise invoice.
What is the GitHub Pages storage limit?
GitHub recommends keeping both source repositories and published sites under 1 GB. There is no officially documented per-file size limit specific to Pages, but very large individual files (video, uncompressed images) are the most common way sites approach that 1 GB ceiling.
Old commits with large binary files can also inflate repository size even after you’ve replaced them, since Git history retains everything by default.
How many times can you build a GitHub Pages site per hour?
GitHub Pages has a soft limit of 10 builds per hour when using the standard Jekyll-based build process. This limit does not apply if you deploy with a custom GitHub Actions workflow instead of the default pipeline, which is common for sites built with Astro, Hugo, or Eleventy.
Separately, any single deployment times out after 10 minutes regardless of which pipeline triggered it.
Is a custom domain free on GitHub Pages?
Yes, GitHub Pages custom domains are free on every plan, including free public repositories. You configure a CNAME or A record with your DNS provider, and GitHub issues a free SSL certificate automatically once verification completes.
The most common gotcha isn’t cost, it’s configuration: apex domains need A records rather than CNAMEs, and SSL provisioning or HTTPS enforcement can take longer than expected right after setup. Our custom domain guide covers the DNS record types in more detail.
What happens if you exceed GitHub Pages usage limits?
GitHub Pages limits are soft, not hard cutoffs. If you exceed bandwidth, storage, or build frequency, GitHub typically throttles delivery or sends an email asking you to bring usage back within range, rather than taking your site offline immediately or billing you.
The one hard stop is the 10-minute deployment timeout: a build that doesn’t finish in that window fails and needs to be fixed and re-pushed. Repeated or severe policy violations can lead to GitHub disabling a Pages site entirely.
Can I use GitHub Pages for a commercial or e-commerce site?
GitHub’s usage policy states that Pages shouldn’t be used for commercial ventures like e-commerce operations or SaaS products. It’s intended for personal, project, and organization sites such as documentation, portfolios, and blogs.
Sites should also avoid handling sensitive transactions like passwords or credit card numbers. If your project genuinely needs commercial hosting, platforms like Supadrop or other alternatives covered in our GitHub Pages alternatives guide are built for that use case.