VPS पर Docker चलाने के मुख्य अंतर और सावधानियां

VPS पर Docker चलाने पर क्या बदलता है

VPS पर चलने वाला Docker वही engine और वही images इस्तेमाल करता है जो आपके laptop पर चलती हैं, इसलिए आप जो भी commands जानते हैं, वे यहाँ भी काम करती हैं। जो बदलता है, वह इसके आसपास का वातावरण है। Laptop में अतिरिक्त memory होती है, एक ऐसा firewall होता है जिसे कोई scan नहीं कर रहा होता, और disk इतनी बड़ी होती है कि आपको उसे देखने की जरूरत नहीं पड़ती। किराए के सर्वर में memory की एक निश्चित सीमा होती है, एक public IP address होता है जिसे boot होने के कुछ ही मिनटों के भीतर scan किया जाने लगता है, और एक root filesystem होता है जिसे Docker बिना पूछे भर देता है।

चार अंतर छोटे सर्वर पर अधिकांश समस्याओं का कारण बनते हैं:

• Memory सीमित होती है, और memory कम होने पर kernel किसी process को kill करके स्थिति को संभालता है।
• एक published port सीधे UFW (uncomplicated firewall) से होकर गुजरता है, क्योंकि Docker अपने स्वयं के firewall rules लिखता है।
• Containers reboot के बाद तब तक वापस नहीं आते जब तक आपने पहले से ऐसा करने के लिए न कहा हो।
• Images, containers, volumes और build cache तब तक बढ़ते रहते हैं जब तक disk भर न जाए।

नीचे दिया गया प्रत्येक section विफलता, वह string जो आपको वास्तव में दिखाई देगी, और उसे गहराई से ठीक करने वाली guide का नाम बताता है। यदि आपने अभी तक compose file नहीं लिखी है, तो पहले VPS पर Docker Compose की बुनियादी बातें पढ़ें और फिर वापस आएं। यह पृष्ठ मानता है कि आप पहले से ही एक stack को run करना जानते हैं।

Docker container कितनी RAM का उपयोग करता है?

ज्यादातर लोगों की अपेक्षा से काफी कम। एक container एक cgroup (control group) में चलने वाली process है, न कि virtual machine, इसलिए इसमें कोई guest kernel और कोई निश्चित allocation नहीं होता। इसकी लागत उतनी ही होती है जितनी process के भीतर की चीजें उपयोग करती हैं। यही कारण है कि एक पूरा stack 2 GB में समा जाता है, जबकि virtual machines से बना वही stack इतनी जगह में नहीं आ पाता।

नीचे दिए गए आंकड़े Ubuntu 24.04 पर default configuration के साथ stock images के लिए सामान्य idle numbers हैं, जिन्हें शुरू होने के कुछ मिनट बाद docker stats से पढ़ा गया है। ये योजना बनाने के लिए एक शुरुआती बिंदु हैं, न कि आपके workload का benchmark। किसी भी आंकड़े पर भरोसा करने से पहले, जिसमें ये भी शामिल हैं, अपने box पर docker stats --no-stream चलाएं।

[
  {
    "label": "nginx",
    "idle_mb": 8,
    "budget_mb": 64
  },
  {
    "label": "Redis 7",
    "idle_mb": 12,
    "budget_mb": 128
  },
  {
    "label": "Traefik v3",
    "idle_mb": 40,
    "budget_mb": 128
  },
  {
    "label": "PostgreSQL 16",
    "idle_mb": 45,
    "budget_mb": 512
  },
  {
    "label": "Uptime Kuma",
    "idle_mb": 95,
    "budget_mb": 256
  },
  {
    "label": "MariaDB 11",
    "idle_mb": 190,
    "budget_mb": 512
  },
  {
    "label": "Nextcloud (Apache)",
    "idle_mb": 210,
    "budget_mb": 768
  }
]

ये दो columns अलग-अलग काम करते हैं। idle_mb वह है जो container कुछ न करते समय उपयोग करता है। budget_mb वह है जिसे योजना बनाते समय reserve करना चाहिए, क्योंकि वास्तविक उपयोग idle नहीं होता। PostgreSQL 45 MB के करीब idle रहता है और एक बार connections, sorts और cache के live हो जाने पर उसे 512 MB की आवश्यकता होती है। बजट column के साथ योजना बनाएं। Idle column के साथ debug करें।

उन 7 rows के आकार पर ध्यान दें। nginx 8 MB पर और Nextcloud 210 MB पर idle रहता है। आपके applications के सामने वाला proxy लगभग मुफ्त है। database और PHP application ही वे चीजें हैं जिनके लिए आप box का आकार तय करते हैं।

docker stats के बारे में एक चेतावनी: memory के आंकड़े में वह page cache शामिल होता है जिसे container की अपनी file reads ने खींच लिया है, इसलिए यह शुरू होने के बाद कुछ समय तक बढ़ता है और फिर स्थिर हो जाता है। यह तय करने से पहले कि कुछ leak हो रहा है, इसे एक घंटे तक monitor करें।

VPS का आकार तय करना: 2 GB, 4 GB और 8 GB में क्या समा सकता है

सबसे पहले होस्ट के हिस्से को अलग रखें। Kernel, systemd, journald, sshd और Docker daemon उसी RAM में चलते हैं जिसमें आपके containers चलते हैं, और dockerd के साथ containerd इसमें से लगभग 100 MB घेर लेते हैं। आपको page cache के लिए भी खाली मेमोरी की आवश्यकता होती है, और उस समय के लिए भी जब image build या database dump के दौरान अचानक लोड बढ़ता है।

[
  {
    "plan": "2 GB VPS",
    "total_mb": 2048,
    "host_reserve_mb": 768,
    "container_mb": 1280
  },
  {
    "plan": "4 GB VPS",
    "total_mb": 4096,
    "host_reserve_mb": 1024,
    "container_mb": 3072
  },
  {
    "plan": "8 GB VPS",
    "total_mb": 8192,
    "host_reserve_mb": 1536,
    "container_mb": 6656
  }
]

host_reserve_mb ऑपरेटिंग सिस्टम, Docker daemon और उस अतिरिक्त क्षमता (headroom) को कवर करता है जो लोड के दौरान सर्वर को responsive बनाए रखती है। जो बचता है वह container_mb है, और यही वह एकमात्र संख्या है जिसे आप खर्च कर सकते हैं। यह रिज़र्व प्लान के साथ बढ़ता जाता है, सबसे छोटे बॉक्स पर 768 MB से लेकर सबसे बड़े पर 1536 MB तक, क्योंकि एक बड़ा बॉक्स अधिक containers चलाता है, अधिक logs लिखता है और उसे अधिक page cache की आवश्यकता होती है।

2 GB का प्लान containers के लिए 1280 MB छोड़ता है। इसमें से 512 MB PostgreSQL पर और 128 MB Traefik पर खर्च करें, तो आधा हिस्सा पहले ही खत्म हो जाता है। बाकी बची मेमोरी में लगभग 256 MB के दो छोटे applications आ सकते हैं। यह एक वास्तविक और उपयोगी सर्वर है। इसमें Nextcloud और एक search cluster के लिए जगह नहीं है।

4 GB का प्लान 3072 MB छोड़ता है, जिसमें एक database, एक reverse proxy, तीन applications और एक monitoring container एक साथ समा सकते हैं। यह किसी भी महत्वपूर्ण काम के लिए उपयोग करने योग्य सबसे छोटा आकार है, क्योंकि अतिरिक्त मेमोरी ही वह चीज है जो खराब deploy के प्रभाव को सोख लेती है।

8 GB का प्लान अपने 8192 MB में से 6656 MB छोड़ता है, और सीमा आमतौर पर मेमोरी से हटकर CPU या disk throughput पर चली जाती है। SSD Nodes इससे छोटा कुछ नहीं बेचता: उनका सबसे छोटा प्लान 8 GB RAM का है (pricing page 2026-10-11 को जाँचा गया), इसलिए उस होस्ट पर यही पंक्ति लागू होती है, और 2 GB तथा 4 GB वाली पंक्तियाँ अन्य प्रदाताओं के छोटे बॉक्स का वर्णन करती हैं। containers का एक वर्ग लोड के बजाय अपने configuration के आधार पर अपना आकार तय करता है: एक local model server अपने context window के अनुपात में KV cache रिज़र्व करता है, इसलिए Ollama के num_ctx को बढ़ाना एक भी request आने से पहले ही बजट में कई gigabytes जोड़ सकता है। यदि गणित यह कहता है कि आपका stack फिट नहीं हो रहा है, तो उसे ट्यून करने के बजाय बड़ा प्लान खरीदें: एक VPS की वास्तविक लागत यह बताती है कि अतिरिक्त gigabytes प्रति माह कितने मूल्य के हैं।

दो नियम इस गणित को सही रखते हैं। हर service पर एक memory limit लगाएँ, ताकि एक अनियंत्रित process पूरे बॉक्स को क्रैश न कर सके। और बजट का ऊपरी हिस्सा खर्च न करें, क्योंकि docker compose build और pg_dump दोनों को सबसे खराब समय पर मेमोरी की आवश्यकता होती है। Docker Compose में memory limits में इसका syntax और सावधानियाँ दी गई हैं।

मेरा container exit code 137 के साथ क्यों बंद हो जाता है?

ऐसा इसलिए होता है क्योंकि kernel ने इसे बंद कर दिया है। 137 का मतलब 128 जमा 9 है, और signal 9 का अर्थ SIGKILL है। container ने अपनी निर्धारित सीमा से अधिक memory की मांग की, जिसके कारण out of memory (OOM) killer ने इसे समाप्त कर दिया।

CONTAINER ID   IMAGE         STATUS
9f2c1a4d7b3e   postgres:16   Exited (137) 4 minutes ago

अनुमान लगाने के बजाय कारण की पुष्टि करें:

docker inspect my-db | grep -i oomkilled
sudo journalctl -k | grep -i "out of memory"

"OOMKilled": true का अर्थ है कि container अपनी cgroup सीमा तक पहुँच गया था, और kernel log उस process का नाम बताता है जिसे उसने चुना है:

Memory cgroup out of memory: Killed process 2417 (postgres) total-vm:1284416kB

यह एक बेहतर स्थिति है, क्योंकि नुकसान केवल एक container तक सीमित रहा। खराब स्थिति वह है जहाँ container पर कोई सीमा (limit) निर्धारित नहीं है। बिना किसी सीमा के, इसकी अधिकतम क्षमता पूरी machine के बराबर होती है, इसलिए एक service में memory leak होने पर पूरा host प्रभावित होता है, और kernel पूरे system में से किसी भी process को victim के रूप में चुन लेता है। ऐसी स्थिति में log line से Memory cgroup prefix हट जाता है और वह Out of memory: Killed process 2417 (postgres) के रूप में दिखाई देता है। kernel अक्सर आपकी database process को चुन लेता है, जबकि leak करने वाला container चलता रहता है। यही कारण है कि किसी एक limit के सटीक मान से अधिक महत्वपूर्ण यह है कि हर service पर एक सीमा निर्धारित हो।

Swap समय (timing) को बदलता है, गणित को नहीं। अधिकांश VPS images में swap नहीं होता है। swapon --show के साथ जांचें, जो swap न होने पर कुछ भी print नहीं करता है। एक swap file kernel को cold pages रखने के लिए जगह देती है, जिससे आपको समस्या पर ध्यान देने के लिए कुछ मिनट मिल जाते हैं।

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
free -h

free -h को अब Swap row में शून्य से अधिक total दिखाना चाहिए। Swap RAM नहीं बढ़ाता है। लगातार memory pressure के तहत एक machine इतनी धीमी हो जाती है कि आप उसे ठीक करने के लिए SSH भी नहीं कर पाते, इसलिए swap को एक alarm buffer के रूप में देखें और sizing को ठीक करें।

UFW मेरे published Docker port को block क्यों नहीं करता है?

क्योंकि traffic कभी भी उस chain तक नहीं पहुँचता है जिसे UFW सुरक्षित करता है। जब आप -p 5432:5432 या compose ports: entry के साथ कोई port publish करते हैं, तो daemon nat table में एक DNAT (destination network address translation) rule और अपनी खुद की DOCKER chain में एक accept rule लिख देता है। container के लिए लक्षित packet को host तक पहुँचाने के बजाय सीधे उस container पर forward कर दिया जाता है, इसलिए इसे FORWARD path में handle किया जाता है और यह कभी भी उन INPUT rules से नहीं गुजरता जिन्हें UFW लिखता है।

आप सर्वर पर इसे होते हुए देख सकते हैं:

sudo ufw status | grep 5432
sudo iptables -t nat -L DOCKER -n | grep 5432

UFW 5432 DENY IN Anywhere दिखा सकता है जबकि nat table में उसी port के लिए DNAT tcp ... to:172.18.0.2:5432 rule मौजूद होता है। किसी अन्य machine से, nc -vz your.server.ip 5432 अभी भी connect हो जाता है। database public internet पर है और firewall कहता है कि यह नहीं है।

इसका समाधान यह है कि कम ports publish करें। एक compose project में containers एक network साझा करते हैं और service name के जरिए एक-दूसरे तक पहुँचते हैं, इसलिए जिस database को केवल अपने बगल वाले application को सेवा देनी है, उसे किसी ports: entry की आवश्यकता नहीं है। जब आप local access चाहते हैं, तो publish को loopback पर bind करें:

services:
  db:
    image: postgres:16
    ports:
      - "127.0.0.1:5432:5432"

docker compose up -d के बाद, बाहर से nc -vz your.server.ip 5432 विफल हो जाता है, और box पर psql -h 127.0.0.1 -p 5432 अभी भी काम करता है। एक स्वस्थ छोटे stack में केवल reverse proxy ही कुछ publish करता है, वह भी 80 और 443 पर। Docker द्वारा published ports UFW को bypass क्यों करते हैं उन मामलों के लिए DOCKER-USER chain को कवर करता है जहाँ आपको port publish करना है और फिर भी उसे filter करना है, और UFW firewall की बुनियादी जानकारी नीचे दिए गए host rules को कवर करती है।

Reboot के बाद मेरे containers गायब क्यों हो जाते हैं?

क्योंकि उन्हें वापस आने का निर्देश नहीं दिया गया था। जब तक आप कोई policy सेट नहीं करते, container no restart policy के साथ बनाया जाता है, इसलिए reboot के बाद वह stopped अवस्था में रहता है और daemon उस पर ध्यान नहीं देता। VPS पर reboot असामान्य नहीं हैं: unattended upgrades से kernel updates, provider maintenance, और ऊपर वर्णित OOM sequence, ये सभी reboot का कारण बनते हैं।

दो चीजें सही होनी चाहिए। Daemon को boot के समय start होना चाहिए:

systemctl is-enabled docker

यह एक standard Ubuntu install पर enabled प्रिंट करता है। फिर प्रत्येक service के लिए एक policy की आवश्यकता होती है:

services:
  app:
    image: ghcr.io/example/app:1.4
    restart: unless-stopped

unless-stopped reboot के बाद container को वापस लाता है और आपके द्वारा जानबूझकर रोके गए container का सम्मान करता है। always उन containers को भी restart कर देता है जिन्हें आपने जानबूझकर रोका था, जब भी daemon restart होता है, जो debugging के दौरान आश्चर्यजनक हो सकता है। केवल file को edit करना पर्याप्त नहीं है, क्योंकि restart policy तब सेट होती है जब container बनाया जाता है। docker compose up -d चलाएं ताकि इसे फिर से बनाया जा सके, फिर live value की जाँच करें:

docker inspect my-app | grep -A3 RestartPolicy

फिर box को जानबूझकर reboot करें और project directory में docker compose ps चलाएं। जो stack एक नियोजित reboot के बाद जीवित रहता है, वह अनियोजित reboot के बाद भी जीवित रहेगा। यदि आपके stack को boot के समय ordering guarantee या one-shot job की आवश्यकता है, तो systemd unit एक बेहतर tool है: boot पर Docker Compose शुरू करना में unit file दी गई है। यह जानने के लिए कि क्या वापस आया container वास्तव में सेवा दे रहा है, Compose healthchecks जोड़ें।

मेरा VPS डिस्क फुल क्यों है?

Docker तब तक सब कुछ रखता है जब तक आप उसे न हटाने के लिए न कहें। आपके द्वारा पुल किया गया हर image tag, हर stopped container, recreate के बाद छूटा हुआ हर anonymous volume, और build cache की हर layer डिस्क पर बनी रहती है। बड़ी डिस्क केवल समय खरीदती है। SSD Nodes के सबसे छोटे प्लान पर मौजूद 160 GB SSD भी (pricing page 2026-10-11 को जाँची गई) उसी तरह भर जाती है जिस पर हर हफ्ते images पुल और बिल्ड होती हैं, और छोटा root filesystem इसे और जल्दी outage में बदल देता है।

डिस्क फुल होने पर यह crash जैसा नहीं दिखता। आपको एक ही घंटे में container से no space left on device, apt से, journald से और docker pull से error मिलते हैं। PostgreSQL writes स्वीकार करना बंद कर देता है। सर्वर अभी भी चालू रहता है, जिससे इसे reboot loop की तुलना में पहचानना कठिन हो जाता है।

हटाने से पहले देखें:

docker system df
df -h /

docker system df कुल डेटा को images, containers, local volumes और build cache में विभाजित करता है, और प्रत्येक के बगल में RECLAIMABLE कॉलम दिखाता है। जो सर्वर अपनी images खुद बिल्ड करता है, वहाँ build cache आमतौर पर सबसे बड़ी लाइन होती है।

docker image prune -a
docker builder prune
docker system df

docker image prune -a उन सभी images को हटा देता है जिनका कोई container उपयोग नहीं कर रहा है। docker builder prune build cache को साफ करता है। ये दोनों कमांड services चलते समय सुरक्षित हैं, क्योंकि जो कुछ भी उपयोग में है उसे छोड़ दिया जाता है। जो सुरक्षित नहीं है वह है docker system prune --volumes। यह stopped containers को हटाता है, और फिर हर उस anonymous volume को हटा देता है जिसे कोई भी शेष container उपयोग नहीं कर रहा है। आपने सप्ताहांत के लिए जो stack रोका है, उसकी स्थिति बिल्कुल ऐसी ही होती है, और यदि उसके database ने अपना डेटा anonymous volume में रखा है (जो Docker तब बनाता है जब image एक volume घोषित करती है और आपकी compose file वहाँ कुछ भी mount नहीं करती), तो वह डेटा भी साथ चला जाता है। Named volumes इस कमांड से बच जाते हैं, लेकिन docker volume prune --all unused named volumes को भी हटा देता है। कोई भी flag टाइप करने से पहले bind mounts बनाम named volumes पढ़ें, और पहले backup लें।

Container logs धीरे-धीरे जगह घेरते हैं। डिफ़ॉल्ट json-file driver की कोई size limit नहीं होती, इसलिए एक अधिक log लिखने वाला container /var/lib/docker/containers में gigabytes डेटा भर देता है। /etc/docker/daemon.json में हर container के लिए इसकी सीमा तय करें:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

इसे sudo systemctl restart docker के साथ लागू करें, जो आपके containers को restart करता है, इसलिए सही समय चुनें। यह सीमा बदलाव के बाद बनाए गए containers पर लागू होती है, इसलिए चल रहे containers को docker compose up -d --force-recreate के साथ recreate करें और पुष्टि करें:

docker inspect my-app | grep -A5 LogConfig
sudo du -sh /var/lib/docker/containers

Inspect output में max-size सेट दिखना चाहिए। यदि यह खाली है, तो वह container बदलाव से पहले का है और अभी भी बिना किसी सीमा के लिख रहा है।

एक छोटे Docker बॉक्स को स्वस्थ रखने की आदतें

इनमें से किसी के लिए भी किसी डैशबोर्ड या ऐसे टूल की आवश्यकता नहीं है जिसे आपको अलग से सीखना पड़े।

• महीने की पहली तारीख को docker system df और df -h / चलाएं। केवल दो कमांड, तीस सेकंड का समय, और आप आउटेज होने से काफी पहले ही ट्रेंड को देख पाएंगे।
• हर सर्विस को एक मेमोरी लिमिट दें, उन सर्विसेज को भी जिनके बारे में आप सुनिश्चित हैं कि वे छोटी हैं। यह लिमिट पूरे होस्ट के आउटेज को केवल एक रीस्टार्ट हुए कंटेनर तक सीमित कर देती है।
• बॉक्स को कहीं और से मॉनिटर करें, ताकि कर्नल के कोई कदम उठाने से पहले ही आपको मेमोरी या डिस्क के दबाव के बारे में पता चल जाए। Uptime Kuma एक कंटेनर में चलता है और लगभग 95 MB पर आइडल रहता है।
• कंटेनरों का नहीं, बल्कि वॉल्यूम्स का बैकअप लें। कंटेनर डिस्पोजेबल होते हैं, लेकिन वॉल्यूम नहीं। restic backups on a VPS में शेड्यूल और रिस्टोर टेस्ट के बारे में जानकारी दी गई है।
• compose फाइल में इमेज टैग्स को पिन करें और उन्हें अपनी पसंद के दिन अपडेट करें। latest के साथ, अगले docker compose pull से आपको जो वर्जन मिलेगा, वह वही होगा जो उस सुबह रिलीज किया गया था।

Docker चलाने वाला एक छोटा VPS वर्षों तक स्वस्थ रहता है यदि चार संख्याएं सीमा के भीतर रहें: मेमोरी बजट, पब्लिश किए गए पोर्ट्स की सूची, प्रत्येक सर्विस पर रीस्टार्ट पॉलिसी, और खाली डिस्क। बाकी सब कुछ वही Docker है जिसे आप पहले से ही घर पर चला रहे हैं।

FAQ

Docker को VPS पर चलाने के लिए मुझे कितनी RAM की आवश्यकता है?

Docker स्वयं बहुत कम संसाधन लेता है। daemon और containerd मिलकर लगभग 100 MB RAM का उपयोग करते हैं, बाकी आवश्यकता आपके containers पर निर्भर करती है। सबसे पहले host के हिस्से का बजट तय करें: 2048 MB के बॉक्स में operating system, daemon और headroom के लिए 768 MB सुरक्षित रखें, जिससे आपके पास उपयोग के लिए 1280 MB बचेंगे। 512 MB पर एक database, 128 MB पर एक reverse proxy और दो छोटे applications इसमें आसानी से आ सकते हैं। किसी भी प्रकाशित आंकड़े पर भरोसा करने के बजाय docker stats --no-stream का उपयोग करके अपने stack को स्वयं मापें।

क्या मैं 1 GB VPS पर Docker चला सकता हूँ?

हाँ, एक या दो हल्के containers के लिए यह संभव है, लेकिन शुरू करने से पहले एक swap file जरूर जोड़ें। 1 GB के बॉक्स का लगभग आधा हिस्सा operating system और Docker daemon के चलने के बाद भर जाता है, जिससे एक छोटा application और reverse proxy चलाने की जगह तो बचती है, लेकिन वास्तविक load के तहत database चलाने के लिए पर्याप्त जगह नहीं होती। इतने छोटे आकार के बॉक्स पर images build करने से प्रक्रिया विफल हो सकती है या कोई अन्य service बंद हो सकती है, इसलिए images को कहीं और build करें और तैयार image को pull करें।

क्या UFW Docker container की सुरक्षा करता है?

उन ports के लिए नहीं जिन्हें आप publish करते हैं। Docker अपने स्वयं के DNAT और forward rules लिखता है, इसलिए किसी published container port पर आने वाला packet host तक पहुँचने के बजाय सीधे container को भेज दिया जाता है, और UFW द्वारा प्रबंधित INPUT rules उसे देख ही नहीं पाते। जब वह port internet से जवाब दे रहा हो, तब भी ufw deny 5432 सक्रिय रह सकता है। 127.0.0.1:5432:5432 का उपयोग करके loopback पर publish करें, internal services को unpublished छोड़ दें, या DOCKER-USER chain में filtering करें।

क्या VPS reboot होने के बाद मेरे containers फिर से start होंगे?

केवल तभी, यदि उन्हें restart policy के साथ बनाया गया हो। प्रत्येक service पर restart: unless-stopped सेट करें, docker compose up -d चलाएं ताकि containers को उस policy के साथ फिर से बनाया जा सके, और पुष्टि करें कि systemctl is-enabled docker का आउटपुट enabled है। इसके बाद जानबूझकर reboot करें और docker compose ps की जाँच करें। जिस restart policy का आपने परीक्षण नहीं किया है, वह वास्तव में कोई policy नहीं है।

मुझे Docker images को कितनी बार prune करना चाहिए?

अधिकांश छोटे servers के लिए महीने में एक बार काफी है, या जब भी docker system df ऐसी जगह खाली होने की रिपोर्ट दे जिसकी आपको आवश्यकता हो। docker image prune -a और docker builder prune दोनों services के चलने के दौरान सुरक्षित हैं, क्योंकि उपयोग में आने वाली images और cache को छोड़ दिया जाता है। docker system prune --volumes का उपयोग तब तक न करें जब तक आप यह न जानते हों कि कौन से volumes unreferenced हैं, क्योंकि यह किसी भी रुके हुए stack के anonymous volumes को हटा देता है, और docker volume prune --all अप्रयुक्त named volumes को भी हटा देता है।