Docker images accumulate indefinitely after app updates — /var/lib/docker grows unbounded

### Summary UmbrelOS does not prune old Docker images after app updates. Each app update via the App Store pulls a new image by digest, leaves the old image as `<none>:<none>` in `/var/lib/docker/overlay2`, and never reclaims the space. Over months of normal usage this accumulates to tens or hundreds of gigabytes of dead layers attributed to the dashboard's "System" category — leading repeatedly to "no space left on device" and inability to start containers. ### Reproduction 1. Install UmbrelOS, install ~10–30 apps from the App Store. 2. Let apps update normally over several months. 3. SSH in and run: `sudo docker system df -v` `sudo du -h -d 1 /var/lib/docker/` 4. Observe many `<none>:<none>` images with `CONTAINERS = 0`, often multiple stale versions of the same app (e.g. four versions of `hermes-agent`, two of `ollama/ollama`, three of `postgres`, etc.). ### Impact (real example) A user with ~30 apps running on UmbrelOS 1.7.2 for ~6 months observed `/var/lib/docker/overlay2` consume **94 GB**, of which **66 GB was reclaimed in a single `docker image prune -a -f`** with zero impact on running containers. That is ~10 GB/month of silent, unbounded growth on a default install. ### Expected behavior After successfully starting a new app version, the previous image (no longer referenced by any container) should be removed automatically — either as part of the update flow or via a periodic cleanup job. This was apparently the original design: the legacy update script in Umbrel 0.5.x contained a step labeled "Saving current Umbrel Docker images to clean up later" (see #1526). The mechanism appears to have been dropped in the migration to UmbrelOS 1.x and never reinstated. ### Actual behavior No automatic cleanup runs. Disk usage grows linearly with update frequency. The "System" category in the dashboard keeps inflating with no way for non-CLI users to understand or remediate it. ### Related community threads (non-exhaustive) - https://community.umbrel.com/t/umbrel-system-disk-space-usage-grows-high-fix/24785 (Feb 2026 — community-authored manual fix, currently the de facto official answer) - https://community.umbrel.com/t/system-take-more-and-more-space/24373 (Dec 2025, unresolved) - https://community.umbrel.com/t/way-to-much-system-storage-usage/12244 (Apr 2023) - https://community.umbrel.com/t/1tb-ssd-is-full/2859 (Aug 2021) - https://community.umbrel.com/t/error-system-service-failed-disk-space-is-too-low-and-no-space-left-on-device/11223 (Jan 2023) The pattern is the same in every thread: user runs out of space, blames Bitcoin Node, eventually discovers `/var/lib/docker`, runs `docker system prune` manually, problem returns months later. This has been the user experience since at least 2021. ### Proposed solutions (any one would resolve this) 1. **Post-update hook**: after a successful app update, run `docker image prune -f` (dangling-only, safe) or `docker image prune -a -f --filter "until=24h"` to remove the just-replaced image. 2. **Scheduled systemd timer**: ship a weekly or monthly `umbrel-docker-cleanup.timer` running `docker image prune -a -f` and `docker system prune -f`. The legacy `umbrel-docker-cleanup.service` exists in older threads — restoring/repairing it would close the loop. 3. **Default `daemon.json` log rotation**: ship `/etc/docker/daemon.json` with sensible `log-opts` (`max-size: 50m`, `max-file: 3`) so JSON container logs don't compound the problem. Solution 1 alone is sufficient and the safest — it only removes the specific image that was just replaced and cannot affect Portainer/Dockge user containers built locally. ### Environment - UmbrelOS 1.7.2 - Umbrel Home