Bytesweep Docker neemt ruimte in op mijn Mac
Docker Desktop bewaart alles in één bestand. Het groeit bij elke build, en images verwijderen maakt het niet kleiner. Hier staat waarom, en wat de ruimte werkelijk terugpakt.
14 dagen gratis proberen, geen kaart nodig. Daarna eenmalig $ 15 voor 3 computers, macOS en Linux.
Waar de ruimte zit
Op macOS draait Docker Desktop een Linux-VM, en het hele bestandssysteem van die VM is één sparse bestand op je Mac:
~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.rawControleer de echte grootte op schijf — niet de logische, die altijd het maximum is dat je Docker hebt toegestaan:
du -h -d0 ~/Library/Containers/com.docker.docker/Data/vms/0/data/Waarom images verwijderen het niet verkleint
Een image verwijderen maakt blokken vrij binnen het bestandssysteem van de VM, maar het bestand op je Mac houdt zijn grootte — het heeft dat al van macOS opgeëist. Recente versies van Docker Desktop sturen TRIM vanuit de VM, waardoor macOS de vrijgekomen blokken kan terugpakken, maar dat gebeurt op Dockers schema en niet op het moment dat je prunet. Tot dan meldt docker system df gigabytes aan vrijgemaakte ruimte terwijl de Finder helemaal geen verandering laat zien.
De ruimte terugkrijgen
Op volgorde: het minst ingrijpende eerst.
1. Kijk wat Docker denkt te gebruiken
Begin hier altijd. Het splitst images, containers, volumes en build-cache, en vertelt hoeveel van elk terug te pakken is.
docker system df -v2. De build-cache legen
Op een machine die regelmatig images bouwt is dit meestal de grootste post en de veiligste om weg te halen — het maakt alleen de volgende build trager.
docker builder prune -a3. Opruimen wat werkelijk ongebruikt is
Gestopte containers, verweesde images en ongebruikte netwerken:
docker system pruneVoeg -a toe om ook elke image te verwijderen die geen draaiende container gebruikt — dat betekent ze later opnieuw ophalen. Voeg het volgende --volumes alleen toe als je zeker bent: in volumes bewaren databases hun gegevens, en dat is het ene commando op deze pagina dat iets vernietigt wat je niet opnieuw kunt downloaden.
4. Som de volumes op voordat je ze aanraakt
Kijk wat er werkelijk zou verdwijnen:
docker volume ls
docker volume ls -f dangling=trueDocker is zelden het enige
Je kunt elk commando op deze pagina uitvoeren, en op dezelfde Mac zijn Xcodes DerivedData en een paar vergeten modelgewichten meestal net zo groot. Bytesweep meet Dockers echte grootte op schijf naast dat alles in één doorloop van tien seconden, zodat je de schijf één keer oplost in plaats van hem programma voor programma achterna te zitten.
5. macOS het bestand laten terugpakken
Na de prune heeft Docker Desktop een bedoelde manier om de vrijgekomen blokken terug te geven: Instellingen → Bronnen → Geavanceerd → Schijfgebruik, of Docker Desktop afsluiten en opnieuw openen, wat bij het starten TRIM in gang zet. Geef het een minuut en controleer de bestandsgrootte opnieuw voordat je besluit dat het niet werkte.
6. De schijflimiet verlagen
Bij Instellingen → Bronnenis de limiet van de virtuele schijf hoe groot Docker.raw mag worden. Verlagen maakt op zichzelf niets vrij, maar zet een plafond op het probleem. Dat je hem „voor de zekerheid” hebt verhoogd is de reden dat het bestand 64 GB werd.
7. Het laatste redmiddel
Instellingen → Probleemoplossing → Clean / Purge data zet de schijf van de VM volledig terug en brengt het bestand bijna op nul. Het verwijdert elke image, container en volume die je hebt. Gebruik het als niets anders hielp en je weet wat er in je volumes staat.
Verwijder Docker.raw niet in de Finder. Het is geen cachebestand — het zijn de gegevens van de hele Docker-installatie, en het weghalen terwijl Docker draait kan de VM in een toestand achterlaten die toch een reset nodig heeft.
Ook het bekijken waard
Docker is zelden alleen
Op de Mac waar Docker 50 GB bereikte, zitten Xcodes DerivedData en lokale AI-modellen er meestal vlak achter. Als je ruimte terugpakt, loont het de hele schijf één keer te meten in plaats van één ding tegelijk te repareren. De volledige lijst →
Op Linux is er geen imagebestand
Op Linux schrijft Docker rechtstreeks in /var/lib/docker, dus een prune maakt de ruimte meteen vrij en niets van het TRIM-probleem hierboven is van toepassing. Linux-schijf opruimen →
Docker naast al het andere zien
Bytesweep meet Dockers echte grootte op schijf, toont die naast Xcode, simulatoren, node_modules en modelgewichten, en markeert wat veilig weg kan — zonder je volumes aan te raken.
Vragen
Is het veilig om Docker.raw te verwijderen?
Niet vanuit de Finder, en niet terwijl Docker draait. Dat ene bestand is elke image, container en volume die je hebt. Wil je echt schoon beginnen, gebruik dan Probleemoplossing → Clean / Purge data in Docker Desktop, wat hetzelfde doet op een manier waarvan Docker weet.
Waarom zegt docker system prune dat het 20 GB vrijmaakte terwijl er niets verandert?
Omdat het 20 GB vrijmaakte binnen het bestandssysteem van de VM, niet op je Mac. Het bestand houdt zijn grootte tot TRIM draait en macOS de blokken terugpakt. Docker Desktop afsluiten en opnieuw openen zet dat meestal in gang.
Verwijdert docker system prune mijn databases?
Alleen als je --volumestoevoegt. Zonder die vlag laat het volumes met rust. Met die vlag verdwijnt elk volume dat niet aan een container hangt, en het volume van een gestopte database telt als niet-aangehecht.
Hoe groot hoort Docker.raw te zijn?
Er is geen goed antwoord, maar op een machine met een handvol actieve projecten is 15 tot 25 GB normaal, en 60 GB betekent dat de build-cache nooit geleegd is. Controleer met docker system df -v voordat je aanneemt dat het de images zijn.