Docker filling up 100GB disk during docker compose pull

Hello
I’m having an issue installing Supabase locally via Docker.
I’ve followed the official documentation, but when I run:

docker compose pull

the db service takes a very long time to download, and then Docker eventually reports that my disk is full.

However, I’m installing Supabase on an empty 100 GB disk.
While monitoring disk usage in real time, I can see it fills up completely within just a few minutes (from 0 GB to 100 GB used).

What’s strange is that I’ve installed Supabase before on this same setup and never had this problem.

For context, I’m running this inside an LXC container on Debian 13.

silentworks•10/15/25, 12:21 PM

Supabase images definitely don't use that much space. You should check if there is something else going wrong with your docker setup.

XOP•10/15/25, 12:29 PM

I don’t think it’s a general Docker misconfiguration — other images pull and run just fine.
The issue only occurs when pulling supabase/postgres:15.8.1.085.

For Docker, I followed the official installation guide, and for Supabase I’m using the default docker-compose.yml file from the repository.

Link for install docker :
https://docs.docker.com/engine/install/debian/

silentworks•10/15/25, 12:31 PM

I don't have 15.8.1.085 image at the moment but I have a few other images for my different projects and none of them take up that amount of space not even when combined

silentworks•10/15/25, 12:36 PM

Even the oldest image I have of Postgres 15 is only 4GB in size

XOP•10/15/25, 12:45 PM

Yeah, I know — I’ve installed it before and it worked fine.
That’s why this is so weird: I’m using the exact same default configuration, and the machine is brand new.

During docker compose pull, I can see it downloading a ton of “fs layer” entries (like in the screenshot), way more than usual.

It really looks like something is looping or expanding too much during the image pull.

XOP•10/15/25, 12:45 PM

silentworks•10/15/25, 12:46 PM

Change the image version for supabase/postgressupabase/postgres and see if it does the same thing. Also just to confirm it's definitelty the supabase/postgressupabase/postgres this is happening with and not any of the other images? I want to try and test that image version here.

XOP•10/15/25, 12:51 PM

Ok I'll test with another version thank you

XOP•10/15/25, 1:28 PM

I’ve just tested with different versions of the supabase/postgres image, but it’s still the same issue.

I tried both 15.14.1.022 and 17.6.1.022, and in both cases I can literally see my disk filling up incredibly fast while pulling the image — it goes from almost empty to full within minutes.

It always stops and hangs like this.

XOP•10/15/25, 1:28 PM

that crazy

inder•10/15/25, 1:35 PM

Is this 100GB drive OS drive or an external drive attached? If its an external drive you'll have to configure docker to download images on this drive

XOP•10/15/25, 1:37 PM

It’s actually the main OS drive — not an external one.
Docker is using its default storage location at /var/lib/docker.

The container has 100 GB of space allocated, and everything else works fine with other images.

The disk usage spike only happens when pulling the supabase/postgres image.

inder•10/15/25, 1:38 PM

Have you tried downloading only this image simply with docker pulldocker pull command?

XOP•10/15/25, 1:39 PM

What’s strange is that I successfully installed Supabase with the exact same configuration about a year ago, and it worked perfectly fine back then.

XOP•10/15/25, 1:39 PM

yes

XOP•10/15/25, 1:40 PM

same

inder•10/15/25, 1:50 PM

How much disk usage you see with this command

sudo du -hs /var/lib/docker

sudo du -hs /var/lib/docker

XOP•10/15/25, 1:55 PM

5,1 gb*

inder•10/15/25, 1:58 PM

5.1 gb?

XOP•10/15/25, 1:58 PM

yes

inder•10/15/25, 1:58 PM

I remember reading somewhere that this can also happen because of inode exhaustion

inder•10/15/25, 1:58 PM

too many log files or empty directories

inder•10/15/25, 2:04 PM

Try this command.

df -i

df -i

XOP•10/15/25, 2:06 PM

I didn’t think about that.
I’m restarting the installation to check.
Before starting, inode usage is only at 1%, so we’ll see if it spikes during the pull.

XOP•10/15/25, 2:13 PM

I’m letting the installation run again now to check,
but I don’t really see how this would explain the full 100 GB usage — where does all that space actually go?

What’s interesting is that as soon as I stop the installation, the disk usage instantly drops back down to around 5.1 GB on average.

inder•10/15/25, 2:14 PM

I'm not sure about how its spiking the disk usage, but the no space left could be because of inode exhaustion

XOP•10/15/25, 2:16 PM

So it’s definitely not inode exhaustion — I just checked, and inodes are only at 15% used,
but the disk still reports as full during the installation.

inder•10/15/25, 2:16 PM

You might also try on a server to rule out any issues with your setup as I run self hosted instances every other day either for testing or in prod and never faced this issue.

inder•10/15/25, 2:17 PM

I usually run r6gd.medium ec2 instance for testing. It has 59 gb ssd

XOP•10/15/25, 2:24 PM

I’ll test it on another server and get back to you afterwards , thanks!

XX I’ll test it on another server and get back to you afterwards , thanks!

inder•10/15/25, 2:53 PM

I know you mentioned above that you've tried to run pull command but I think you ran it with other images downloaded on your machine.

Try taking down all the containers if any running. Then clear everything docker system prune -adocker system prune -a.

This will delete everything

And now download only the db image using docker pulldocker pull

Iinder I know you mentioned above that you've tried to run pull command but I think you...

silentworks•10/15/25, 2:55 PM

However, I’m installing Supabase on an empty 100 GB disk.
While monitoring disk usage in real time, I can see it fills up completely within just a few minutes (from 0 GB to 100 GB used).

OP did say this in the original message.

Iinder I know you mentioned above that you've tried to run pull command but I think you...

XOP•10/15/25, 2:58 PM

Yes already tested and it still did the same

Ssilentworks > However, I’m installing Supabase on an empty 100 GB disk. > While monitoring d...

inder•10/15/25, 2:59 PM

But i believe this was the entire stack. And op mentioned that only db image was causing this issue so i thought of pulling only this img

XX Yes already tested and it still did the same

inder•10/15/25, 3:00 PM

Let me know how it goes on another server

XOP•10/15/25, 3:11 PM

So I created a new VM on my PC with Debian 12, and it works perfectly.
It’s really strange that it doesn’t work on my server — I’ll try reinstalling it with Debian 12 as well, since that’s the only thing that’s different compared to my last setup on the same machine.

inder•10/15/25, 3:14 PM

yeah its also the first time someone has mentioned this happening

XOP•10/15/25, 3:21 PM

It’s the same thing again, I still don’t get it.
I’m going to create another LXD container on a different server — maybe something’s wrong with the host configuration somewhere.

XOP•10/16/25, 2:53 PM

Hey! Just for your information — I finally found the cause of the problem.
It turned out that Docker inside my LXC container didn’t have the required permissions.
I fixed it by enabling the following settings on the container:

lxc config set <container> security.nesting true
lxc config set <container> security.syscalls.intercept.mknod true
lxc config set <container> security.syscalls.intercept.setxattr true
lxc config set <container> security.privileged true

thx for your times @silentworks and @inder

XX Hey! Just for your information — I finally found the cause of the problem. It tu...

silentworks•10/16/25, 2:54 PM

Happy to hear you got it resolved and also thanks for posting the solution here.

Docker filling up 100GB disk during docker compose pull

Similar Threads

Similar Threads

Similar Threads