A mirror grows because it keeps every version anyone ever requested, plus every container layer and snapshot your CI pushes. Measure growth per repository, set cleanup rules by repository type, protect anything a released build depends on, and alert well before the disk is full.
Where the space goes
Different repository types grow for different reasons.
| Repository type | Why it grows | Cleanup style |
|---|---|---|
| Proxy of a public registry | Every requested version stays cached | Evict by age since last download |
| Hosted internal packages | Every release and snapshot is stored | Keep releases, trim old snapshots |
| Container images | Each build adds layers and tags | Keep tagged releases, trim untagged and old builds |
Container images usually dominate. A busy CI pipeline can push a new image on every commit.
Measure before you delete
Record disk use per repository weekly for a month. A simple spreadsheet works. You want two numbers: current size and growth per week. Then you can say when the disk fills and decide whether to add storage or tighten rules.
df -h /srv/mirror
du -sh /srv/mirror/* | sort -h | tail -10
Your mirror software may offer better per repository figures in its admin screen. Use those when available.
Rules that are safe
- Proxy caches: remove items not downloaded for a long window, for example several months. They refetch from upstream if needed.
- Snapshots: keep the latest few per package, delete older ones.
- Container images: delete untagged images after a short period, and keep tagged release images indefinitely, or as long as you may need to redeploy or investigate.
- Releases: do not auto delete released internal versions. A deployed system may need them for rollback.
The risky part is deleting something a released build still pulls. Before enabling any rule, run it in a report or dry run mode if your software supports it, and read the list. A related checklist is registry cleanup dry run checklist.
Garbage collection needs care
In many registries, deleting an item only marks it, and space is freed by a separate cleanup task. That task may need writes to be paused or can briefly affect availability. Schedule it in a quiet window, announce it and test it first. Keep a recent backup of your internal artifacts before the first run.
Set alerts
Alert at a moderate fill level, such as seventy percent, and again at a higher one. A mirror that runs out of disk fails writes first, then builds, and the first symptom is often a confusing error in CI. An early alert turns an outage into a ticket.
Plan for upstream rate limits
After a big cleanup or a restore, your cache is cold and many packages refetch at once. Public registries may rate limit. Warm the cache with the base set of packages your builds need, and stagger the first full CI run.
Where Safeguard fits
Safeguard's SBOM and container image scan show what is in the images you keep, which helps decide which tagged images still deserve space. A free scan is at gold.safeguard.sh/scan.
Quick check
Will cleanup break old builds?
Only if those builds need cached public packages that vanish from upstream. Keep releases and test rules on a copy.
How much free space should we keep?
Enough for at least a few weeks of growth plus room for cleanup tasks, which may need temporary space.
Last reviewed: 19 October 2026.
