GitHub Container Registry (GHCR) is free for public images, and for private images the storage and data-transfer billing has stayed in a soft state - most users see a zero bill, but that is a policy GitHub can change with notice, not a contractual free tier. The honest answer to the pricing question is: free today for most real usage, with two specific places a large private workload could start to cost money.
The docs say “currently free” and the forums say “we don’t get billed.” Both are true and both come with an asterisk worth reading before you build a 10TB mirror.
Table of contents
- Public images are simply free
- Private images: storage and transfer
- The pulls-through-Actions exemption
- How to avoid a surprise
- Where RunxBuild fits
- FAQ
Public images are simply free
If your container images are public, GHCR storage and bandwidth are free, with no pull rate limits of the kind Docker Hub imposes. This is the straightforward case and it covers most open-source projects and public base images.
For a public project, there is no pricing conversation. Push the image, pull it from anywhere, done. The pricing complexity only appears once images are private, which is where organisations and commercial projects live.
Private images: storage and transfer
For private images, GHCR is metered on two axes under GitHub Packages billing: storage of the image layers, and data transfer out when those images are pulled. Each GitHub plan includes an allowance, and usage beyond it is billed per GB.
The nuance in 2026 is that container storage and bandwidth specifically have remained in a soft billing state - GitHub has publicly said it will give at least 30 days notice before charging for GHCR egress. So the Packages billing page can show a scary potential number while the actual invoice reads zero.
Treat that as a window, not a guarantee. Plan as though it will eventually be metered like the rest of Packages.
The pulls-through-Actions exemption
There is a consistent carve-out worth knowing: image pulls that happen inside GitHub Actions do not count against your data-transfer allowance, even on self-hosted runners. Traffic labelled as Actions stays in the free bracket.
The cost risk is direct pulls from outside - a Kubernetes cluster in another cloud pulling images straight from GHCR at high volume. If your heavy CI lifting runs in Actions, that traffic is effectively free; if your production cluster pulls thousands of images a day across the public internet, that is the pattern to watch.
How to avoid a surprise
Three habits keep GHCR cheap and predictable. Clean up old image versions and untagged layers so storage does not creep. Keep CI pulls inside Actions where they are exempt. And if a production cluster pulls heavily, consider a registry mirror or a cache in the same network so you are not re-downloading the same layers over the public internet repeatedly.
Watch the GitHub Changelog for the promised notice period, and keep a plan B registry in mind for a very large private workload. For most teams none of this bites - but knowing where it would is the point.
Where RunxBuild fits
If the reason you are pricing a registry is to deploy the images somewhere, RunxBuild deploys services directly from a GitHub repository and builds the image for you, with build logs and a live route - so for the common case you may not be managing a registry and its egress at all.
When you do run your own images, the thing that actually costs money in production is usually not the registry, it is the running compute and the bandwidth out of the app. The RunxBuild hosting calculator lets you model those line items together before you commit, which is where the real monthly number comes from.
How this fits the rest of the stack
The cost of a project is the sum of its line items, not the headline number, and the RunxBuild hosting calculator is the right place to add them up: the service, the database, the storage, the bandwidth, each a separate figure. Model it before committing, not after the first invoice. The RunxBuild dashboard is where the running project shows its real usage in one place.
Useful related references:
- Container registry security
- Deploy from GitHub with Render
- Docker services
- GitHub getting started
- Services introduction
FAQ
Is GitHub Container Registry free?
For public images, yes, with no pull rate limits. For private images, storage and data transfer are billed under GitHub Packages, but container-specific billing has remained in a soft state where most users see a zero invoice - with GitHub committing to at least 30 days notice before charging for GHCR egress.
Do GHCR pulls count against my data transfer?
Pulls made inside GitHub Actions, including self-hosted runners, are exempt. Direct pulls from outside GitHub - for example a Kubernetes cluster in another cloud - are the ones that would count against a private image’s transfer allowance if and when egress is billed.
How do I reduce GitHub Container Registry costs?
Delete old and untagged image versions to control storage, keep CI pulls inside Actions where they are exempt, and cache or mirror images near a high-volume production cluster so you are not repeatedly pulling the same layers over the public internet.
Will GHCR start charging in the future?
It can. GitHub has kept container storage and egress in a soft billing state but has said it will give at least 30 days notice before charging for GHCR egress, so the prudent assumption is that a very large private workload will eventually be metered like the rest of GitHub Packages.
Do I even need a container registry?
Not always. If a platform builds and deploys directly from your source repository, it can produce and run the image for you without you maintaining a registry, which removes both the storage and the egress question for the common deploy case.