@latest_post
Preparing Omarchy for container-heavy workloads
A fresh Omarchy installation can have hundreds of gigabytes free and still produce confusing storage reports after a few container-heavy sessions. du might report 250 GiB under /home while df says the filesystem uses nearly 400 GiB.
That does not necessarily mean Snapper has hidden another 150 GiB. Btrfs subvolumes, hibernation swap, Podman storage, snapshots, compression, and open deleted files all participate in different accounting systems.
The problem surfaced on my main workstation, where I create and destroy containers frequently as isolated sandboxes for AI coding agents. This guide records the storage boundaries, Snapper retention policy, and cleanup routines I want in place from the start of every fresh Omarchy installation.
Repeated emergency cleanup does not solve the underlying problem. A durable fix places each kind of data in a subvolume whose snapshot and cleanup policy matches how long that data should live.