Running out of space - Docker image is large?

Hi, I run a small self-hosted forum on a 25GB cloud VM running Debian 13. I was attempting to update to 2026.6.0-latest using ./launcher rebuild app and the update cancelled because I didn’t have enough disk space. I followed the prompt to clean up Docker images, but that didn’t help. I have 3.9 GB remaining. My forum’s uploads amount to 138 MB, and I have backups amounting to 448 MB. My server is bare except for the Discourse install, I haven’t done anything else with it.

After digging with du, I found that /var/lib/containerd is 13 GB, and /var/docker is 5.1 GB. Is it normal for these to consume so much space? Is there anything I can do about it?

If it is normal, I guess I’ll just have to pay for more storage. Just wanted to confirm before I take on the extra expense. Thanks!

Hmm… have you tried ./launcher cleanup?

It’s worth running a cleanup. Please post details of what happened. Here’s one I once did:

root@ubuntu-2gb-nbg1-1:/var/discourse# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        19G   12G  6.5G  65% /

root@ubuntu-2gb-nbg1-1:/var/discourse# ./launcher cleanup
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B

WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N] y

Deleted Images:
deleted: sha256:33ce56b3484175342191a344fe1aa9f330431de7bf6f0f0e14f75c5bd851a5b0
deleted: sha256:5e04a0411f813e8f2c1a50d84a7d7bb1b17a855ce041730cf8e3b2fb90144b19
untagged: discourse/base:2.0.20200512-1735
untagged: discourse/base@sha256:7f6c5be23a8e4237cecafaca9d041de5964f8237345b7b183cebdee1f73ed024
deleted: sha256:991acdba0b1f18141192f8682bc5ec1c3365dff0d4fa1c6504e6ce0e3ae6dd76
deleted: sha256:e1c41c8dbd697ae0a61ca612c61f085f69f5bf74c4269cf5c68b4de0fec723fa
deleted: sha256:c2adabaecedbda0af72b153c6499a0555f3a769d52370469d8f6bd6328af9b13
untagged: discourse/base:2.0.20200724-1815
untagged: discourse/base@sha256:1d5eb2f8eae84203b28d3c643648d0dd7d213c2055865cfa5132e30db9e365d5

Total reclaimed space: 2.591GB

# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        19G  8.7G  9.3G  49% /

It’s worth taking a detailed view of disk usage and posting it here too! See for example

If you have any backups on the system, you should download them, test them, and delete all but the latest. If under extreme pressure, delete the latest too. (In my case, I make sure the copy I downloaded is also covered by my own personal offsite backup first. Always have at least two copies.)

Aside from du, which answers questions at the OS level, you can ask questions at the docker level. Please post your detailed findings!

# docker volume ls -qf dangling=true
# docker images -a

It is difficult to juggle disk usage on a 25G instance - I did it for a long time, using up time and making use of sysadmin experience. Eventually I switched providers, paid less and got 40G and that was much better.

See also previously
Discourse upgrade fails due to insufficient disk space on 25G droplet

This is very informative, thanks.

Before I try cleanup, does Discourse provide a way to verify backup integrity without doing a restore?

The result of du -hx / | sort -h | tail -49 (I found -h made it easier for me to parse the results):

833M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/42/fs/var/www/discourse/vendor/bundle/ruby
833M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/42/fs/var/www/discourse/vendor/bundle/ruby/3.4.0
837M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/283/fs/var
837M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/283/fs/var/www
837M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/283/fs/var/www/discourse
837M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/283/fs/var/www/discourse/vendor
837M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/283/fs/var/www/discourse/vendor/bundle
837M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/283/fs/var/www/discourse/vendor/bundle/ruby
837M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/283/fs/var/www/discourse/vendor/bundle/ruby/3.4.0
839M	/var/discourse/shared
839M	/var/discourse/shared/standalone
840M	/var/discourse
863M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/42
863M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/42/fs
868M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/283
868M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/283/fs
874M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/284
874M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/284/fs
874M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/43
874M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/43/fs
908M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/263/fs/usr
925M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/22/fs/usr
944M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/263
944M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/263/fs
961M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/22
961M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/22/fs
1.3G	/usr
1.4G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/251
1.4G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/251/fs
1.4G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/251/fs/var
1.4G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/251/fs/var/www
1.4G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/251/fs/var/www/discourse
1.5G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/227/fs/var
1.5G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/227/fs/var/www
1.5G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/227/fs/var/www/discourse
1.6G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/227
1.6G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/227/fs
2.5G	/var/log
2.5G	/var/log/journal
2.5G	/var/log/journal/1d9299c9656046d6bd0e18d4a09c183c
2.7G	/var/lib/containerd/io.containerd.content.v1.content
2.7G	/var/lib/containerd/io.containerd.content.v1.content/blobs
2.7G	/var/lib/containerd/io.containerd.content.v1.content/blobs/sha256
9.8G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs
9.8G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots
13G	/var/lib
13G	/var/lib/containerd
17G	/var
20G	/

The output of docker volume ls -qf dangling=true was empty. Actually, docker volume ls is empty.

docker images -a:

IMAGE                              ID             DISK USAGE   CONTENT SIZE   EXTRA
discourse/base:2.0.20260209-1300   50d2dae489a9       4.77GB         1.12GB        
discourse/base:2.0.20260521-0047   27373b823bbe       4.89GB         1.17GB        
local_discourse/app:latest         01527763be8d        6.9GB         1.63GB    U   

I know too little about Docker to diagnose this output, but /var/log/ seems a bit large if it’s just logs, and it’s interesting to have 3 images when I have just 1 forum running (maybe that is totally expected though).

Appreciate the point about more storage space. I will probably expand, but this is a good learning experience before I do.

You can save a bit by reconfiguring the journalling:

I’ve never really understood the docker container management. Sometimes cleanup helps. I ran these commands just now:

# cd /var/discourse/
# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        38G   24G   13G  67% /
# docker images -a
                                                                                             i Info →   U  In Use
IMAGE                              ID             DISK USAGE   CONTENT SIZE   EXTRA
discourse/base:2.0.20260209-1300   18ccefc73392        3.1GB             0B        
local_discourse/app:latest         810ac5579584       4.57GB             0B    U   
<untagged>                         d303cfc49c99       4.37GB             0B        
<untagged>                         a9d03385c205       4.34GB             0B        
# ./launcher cleanup
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B
WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N] y
Deleted Images:
deleted: sha256:d303cfc49c992b7fa0b0da65e38f3de79312c6e42eb99e5fd7b27bf4e237ab1d
deleted: sha256:829057c668fd2bd0f7b863c2589e5c3c27364285b39d6df31d38eb208e6410df
untagged: discourse/base:2.0.20260209-1300
untagged: discourse/base@sha256:50d2dae489a9c9916c3d50d880f7f1282fcbe179339b60a8947ab135c1f1f9bf
deleted: sha256:a9d03385c205f740e5f02db0c665a83688f7194d5386bd2d01772b8b5cd5dc65
deleted: sha256:70ec1b4b6cab7365b5f56b8187ef7631e6906fe13b5d3a2b1e39d3457d14514c

Total reclaimed space: 2.517GB
# docker images -a
                                                                                             i Info →   U  In Use
IMAGE                        ID             DISK USAGE   CONTENT SIZE   EXTRA
local_discourse/app:latest   810ac5579584       4.57GB             0B    U   
<untagged>                   18ccefc73392        3.1GB             0B        
# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        38G   21G   15G  59% /

To test a backup fully, you’d need to restore it (somewhere) - mostly I just check the size, and use
gunzip -tv filename
to test that it is intact. I might use
tar tvzf filename | less
to check the contents: a compressed database backup and in my case a number of uploads.

The output of ./launcher cleanup:

WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B
WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N] y
Deleted Images:
untagged: discourse/base:2.0.20260209-1300
deleted: sha256:50d2dae489a9c9916c3d50d880f7f1282fcbe179339b60a8947ab135c1f1f9bf
deleted: sha256:1bb6f08ca8363e7e002eaf8bafc76b7742d8baa429f816cde77d3d38d234c98a
deleted: sha256:07596c600885cf3f0647c4b41959c5631328ee37af14913b9f2b1b1771ad4f45
untagged: discourse/base:2.0.20260521-0047
deleted: sha256:27373b823bbeca526dd006cefe1c58e7eeca1e5670ab6e619fcd2138f7d50420
deleted: sha256:ab90467600edc09bae8ac2f43420b7c771f87d357aa15646cd40025ec0774fda
deleted: sha256:053438a5cf1727f724f96a4d7af0b135929f633afd8ee05edcddeaf99232b636

Total reclaimed space: 1.17GB

This is odd, though: my Discourse forum just went from reporting 3.9 GB free to 8.5 GB free. If I run du -hx / | sort -h | tail -49 again, you can compare with my previous results, and /var/lib has shrunk by 8 GB:

628M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/227/fs/var/www/discourse/vendor/bundle/ruby
628M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/227/fs/var/www/discourse/vendor/bundle/ruby/3.4.0
629M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/227/fs/var/www/discourse/vendor
733M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/42/fs/var/www/discourse/vendor/bundle/ruby/3.4.0/gems
792M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/43/fs/var/www/discourse/node_modules/.pnpm
793M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/43/fs/var/www/discourse/node_modules
794M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/43/fs/var
794M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/43/fs/var/www
794M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/43/fs/var/www/discourse
833M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/42/fs/var
833M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/42/fs/var/www
833M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/42/fs/var/www/discourse
833M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/42/fs/var/www/discourse/vendor
833M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/42/fs/var/www/discourse/vendor/bundle
833M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/42/fs/var/www/discourse/vendor/bundle/ruby
833M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/42/fs/var/www/discourse/vendor/bundle/ruby/3.4.0
839M	/var/discourse/shared
839M	/var/discourse/shared/standalone
841M	/var/discourse
863M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/42
863M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/42/fs
874M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/43
874M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/43/fs
925M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/22/fs/usr
961M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/22
961M	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/22/fs
1.3G	/usr
1.4G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/251
1.4G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/251/fs
1.4G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/251/fs/var
1.4G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/251/fs/var/www
1.4G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/251/fs/var/www/discourse
1.5G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/227/fs/var
1.5G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/227/fs/var/www
1.5G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/227/fs/var/www/discourse
1.6G	/var/lib/containerd/io.containerd.content.v1.content
1.6G	/var/lib/containerd/io.containerd.content.v1.content/blobs
1.6G	/var/lib/containerd/io.containerd.content.v1.content/blobs/sha256
1.6G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/227
1.6G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/227/fs
2.5G	/var/log
2.5G	/var/log/journal
2.5G	/var/log/journal/1d9299c9656046d6bd0e18d4a09c183c
6.4G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs
6.4G	/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots
7.9G	/var/lib/containerd
8.0G	/var/lib
12G	/var
15G	/

And docker images -a is noticeably different:

IMAGE                        ID             DISK USAGE   CONTENT SIZE   EXTRA
local_discourse/app:latest   01527763be8d        6.9GB         1.63GB    U   

It seems like ./launcher cleanup is understating the amount of reclaimed space?

I should have enough space to perform an update now. It seems like running cleanup after updating is a good habit to be in.

Thanks for the help!

You’ve just cleaned up two bases images leaving the local built image.

Are the base images just remnants of the original installation process? Or do they get downloaded during a rebuild app as well?

Yes. The latest image is downloaded if missing and you will build your local image from there.

I can’t think of a reason why you might want to keep more than one base image …

Still a big saving possible here.