Hi,
I’m running HA 2025.2.2 on docker.
Installation was done regarding official documentation.
Problem: Disk usage of /var/lib/docker/overlay2 is continuously increasing.
After removing the homeassistant-container and redeploying it, disk-usage is reset and again constinuously increasng, about 150 MB/24h.
Why/what is blowing up the ha-container?
home-assistant.log is located in the separate persistent volume, as well as home-assistant_v2.db => so these files don’t blow up the container.
Are there any other remarkable logs?
You can try disabling all login or setting it to fatal. I think that can be used to disable all integrations’ logging at once.
HA has no data growth other than log.
An exception would be if you set HA to store some data like camera snapshots.
Can you look at the data to determine type, file and location? This is easier than guessing.
How can I determine which data-types/-locations are growing within the container?
I expect it is a mapped folder that exists in the host system. You should be able to use file explorer or command line to check
If you don’t understand above, post docker run command or compose file
This is the relevant part of the docker compose:
homeassistant:
container_name: homeassistant
image: "homeassistant/home-assistant"
volumes:
- /home/pi/docker/homeassistant:/config
- /etc/localtime:/etc/localtime:ro
restart: unless-stopped
privileged: true
network_mode: host
The log-file as well as the sqlite-DB is located within /config, and thus on the docker-host, not in the container.
Why is the container blowing-up by ~150MB/24h day-by-day? With deleting the container and redeploying it, this storage-waste is cleared.
Because of the persistent /config-volume, I don’t have any data-loss, but I don’t want to have to periodically redeploy the container.
I run the ha-container for about 1y unter Raspberry OS with limited storage. There, I never had the problem. Then, I switched to x64-hardware with Proxmox, there is running Debian OS as VM with Docker with the same docker-compose set-up HA-container as on RPi. With the new setup, I have the storage-problem!?
Hello, I could be wrong, but the instructions I believe at some time in the past moved using the image homeassistant/home-assistant to ghcr.io/home-assistant/home-assistant:stable
If you don’t specify the tag I believe it uses latest which may or may not be different?
Looks like dockerhub is up to date but yes, should use ghcr
Your running virtual in virtual? Can’t proxmox run container directly without VM. Either run HA in container or HAOS/core in VM but not both.
The file growth is old docker images
Use prune
Not sure how I missed that important bit
EDIT
No. The growth is not images is its continuous.
Are you certain the container is using the /config folder?
While HA is running ssh in and look at files to see what they are
and what about using the stable tag - otherwise it would default to the latest? Not sure how often that is updated but if you have something pulls the image regularly to check it may keep downloading newer versions even if you don’t use them?
For proxmox, it’s the recommended way to run docker-containers within a VM.
I tried HAOS as VM within proxmox: this works well for me including one-time data-transfer from ha-container to ha-VM.
But I don’t see any advantage with the HAOS-VM, because I don’t need HA-Addons. I deployed all necessary services like mosquitto, z2m, etc. as docker-containers instead of HA-Addons.
Thus I switched back to the HA-container-way.
Thanks, I’ll add the stable-tag.
But my disk-usage does not increase due to uncontrolled image-downloads because I always manually switch to a newer image-version and clean-up the local image-repository afterwards.
Is the VM running just the home assistant docker or you running other docker containers in the same VM?
I had a quick check and there is a section on here;
Why is Docker filling up /var/lib/docker/overlay2? - Stack Overflow
that states that for container specific changes are stored there that aren’t sent to volumes, not sure what you get from running docker diff homeassistant
I’m not a docker-expert, but I found out:
homeassistant/home-assistant:stable is equivalent to docker.io/homeassistant/home-assistant:stable
I pulled homeassistant/home-assistant:stable and afterwards, I pulled ghcr.io/home-assistant/home-assistant:stable. There was no download necessary for the second images => thus: both images must be identical.
Thank you @alander , this was exactly the unknown command I was looking for. My container has ~4000 changes/modified files, 3000 of these changes are added files and ~2800 of these added files are /usr/local/lib/python3.13/site-packages//pycache/.pyc files.
I think this is not an intended behaviour.
Anybody any ideas?
I believe the pycache/.pyc are normal (I’ve got the same) from what I understand from the python files they are compiled at runtime if they don’t exist or have changed. Are there other files that would be writing and updating regularly?
Docker basically recommends the opposite. Not important really. There is a lot of back and forth about containers,VMs and mixing them and not related to your problem and mostly opinion
Agree. I just don’t like VMs really but mostly don’t like docker in VM. (Biased opinion)
Source is different. One comes from dockerhub and the other from GitHub. They are same today but could be different at any future point. This is good info
I would rebuild.
This issue does not exist with HA docker container so problem must be in your VM or docker container somehow.
Restoring takes seconds and rebuild is quick and forces you to reverify everything. Worst case you end up in same spot and best case you fix or find issue
I recommend build new default container and verify no growth. After verify, you can stop both containers >> copy/paste config to new(use rsync) >> restart new container
Just make sure both use same version
As mentioned before, I migrated the docker-ha-container from RPi to x64-Proxmox-Debian-VM. With this migration, the Glances integration as well as the 3 voice-assistant-integrations became disfunctional, because I didn’t migrate the corresponding docker-containers.
I disabled these integrations => thus, it seams as if the disk-usage-increasing did decrease from 150 MB/24h to 40 MB/24h.
