Stop treating your package cache as a black box

Technical Briefing | 9/14/2026

You spend all morning fighting a dependency hell loop, and when you finally fix it, you move on without a second thought. But meanwhile, your local disk usage is slowly climbing because your package manager is hoarding every single deb or rpm file you have ever downloaded. It is a classic case of setting it and forgetting it, right up until the point where your root partition runs out of inodes during a kernel update. I have seen more than one production outage caused by a full disk partition that turned out to be nothing more than gigabytes of stale package cache sitting in /var/cache/apt/archives.

The ghost of installations past

The standard approach for most people is just to run clean or autoremove. That usually clears out the cruft, but it does not tell you why the disk hit the floor in the first place. You are essentially letting the system delete things blindly. If you actually want to see what is living in your cache folder without taking the nuclear option, you should start by auditing the directory directly. Most tutorials ignore the fact that these directories are simple trees, and you can pipe them to sort to find out exactly which library update was a few hundred megabytes.

du -sh /var/cache/apt/archives/* | sort -rh | head -n 10

• Use du to actually see if it is just a few massive debug symbols causing the bloat
• Check your /etc/apt/apt.conf.d/ local configs to see if someone set Keep-Package-Cache to true years ago
• Don’t run apt-get clean if you intend to move that machine to an offline network later

If you are running a fleet of servers, stop manually cleaning these. If you are not using a local apt-cacher-ng proxy, you are basically burning bandwidth every time you provision a new node. Next time you are debugging a weird disk pressure alert, skip the system metrics dashboard and go straight to the archive directory; it is almost always sitting there waiting for you to notice.