DigitalOcean के बेहतरीन विकल्प: तुलना और गाइड

DigitalOcean के विकल्प वास्तव में क्या बदलते हैं

DigitalOcean के अधिकांश विकल्प बिल बदलते हैं, मशीन नहीं। आपको हर स्थिति में public IP, virtio disk और root access वाला एक Linux virtual machine मिलता है, और आपके kernel को इससे कोई फर्क नहीं पड़ता कि control panel पर किसका लोगो है। चुनाव तय करने वाले अंतर ये हैं: प्रति GB RAM की कीमत, शामिल transfer allowance का आकार और उससे अधिक डेटा होने पर प्रति byte की लागत, disk वास्तव में किस चीज़ से बनी है, और operating system के ऊपर के stack का कितना हिस्सा कोई और आपके लिए चलाएगा।

यह गाइड इन आधारों पर तुलना करती है, क्योंकि एक developer terminal या प्रकाशित price list से इनमें से हर एक की जाँच कर सकता है। यह उन स्थितियों के नाम भी बताती है जहाँ DigitalOcean सही विकल्प है, क्योंकि ऐसी तुलना जो कुछ भी स्वीकार नहीं करती, वह केवल एक विज्ञापन है।

नीचे दी गई प्रत्येक कीमत एक प्रकाशित list price है, जिसे 5 August 2026 को जाँचा गया है। कीमतें बदलती रहती हैं, और यहाँ मौजूद एक से अधिक प्रदाता ने 2026 के दौरान अपनी कीमतें बदली हैं। मूल्य निर्धारण का ढांचा बहुत धीमी गति से बदलता है, इसलिए पहले अनुपात और billing model को पढ़ें, फिर commit करने से पहले प्रदाता के अपने page पर आज की संख्या की पुष्टि करें।

RAM की प्रति GB कीमत तुलना करने के लिए सबसे महत्वपूर्ण आंकड़ा है

[
  {
    "provider": "DigitalOcean 1 GB",
    "ram_gb": 1,
    "monthly_usd": "6.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "DigitalOcean 4 GB",
    "ram_gb": 4,
    "monthly_usd": "24.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "Akamai Nanode 1 GB",
    "ram_gb": 1,
    "monthly_usd": "5.00",
    "usd_per_gb_ram": "5.00"
  },
  {
    "provider": "Vultr NVMe 1 GB",
    "ram_gb": 1,
    "monthly_usd": "6.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "Hetzner CX23 4 GB",
    "ram_gb": 4,
    "monthly_usd": "6.49",
    "usd_per_gb_ram": "1.62"
  }
]

एक ही प्रदाता (provider) के भीतर, RAM की प्रति GB कीमत में बहुत कम बदलाव होता है। DigitalOcean अपने 1 GB प्लान पर $6.00 प्रति GB और 4 GB प्लान पर भी $6.00 प्रति GB चार्ज करता है, जिसकी मासिक कीमत $24.00 है। एक ही प्रदाता के साथ बड़ा प्लान चुनने पर कोई छूट नहीं मिलती है, इसलिए निर्णय प्लान के आकार पर नहीं, बल्कि प्रदाता के चुनाव पर निर्भर करता है।

Akamai, जो अब पूर्व में Linode के नाम से जानी जाने वाली सेवाओं को बेचता है, अपने 2 GB और 4 GB shared प्लान की कीमत क्रमशः $12 और $24 रखता है, जो DigitalOcean के बराबर है। इसका एंट्री प्लान $5.00 पर उन्हें पछाड़ देता है। दो कंपनियों का कीमतों को बिल्कुल समान रखना एक महत्वपूर्ण संकेत है: यह टियर हार्डवेयर के बजाय प्रतिस्पर्धी की कीमतों के आधार पर तय किया गया है, और यह भविष्य में भी उसी प्रतिस्पर्धी का अनुसरण करेगा।

कीमतों में अंतर उन प्रदाताओं के साथ आता है जो अपने स्वयं के डेटा सेंटर बनाते हैं और यूरो में बिक्री करते हैं। Hetzner CX23 आपको लगभग $6.49 प्रति माह में 4 GB RAM देता है, जो कि $1.62 प्रति GB है, यानी DigitalOcean की दर का लगभग एक चौथाई। यह डॉलर का आंकड़ा यूरो की सूची मूल्य से परिवर्तित किया गया है, इसलिए यह विनिमय दर के साथ बदलता रहता है। Hetzner ने 2026 के दौरान अपनी क्लाउड कीमतों में वृद्धि भी की थी, इसलिए पुरानी तुलनात्मक पोस्ट में दिए गए आंकड़े अब मान्य नहीं हैं।

RAM की प्रति GB कीमत आपको मिलने वाले CPU के बारे में कुछ नहीं बताती है। Shared vCPU का अर्थ है कि हाइपरवाइजर आपके कोर को अन्य किरायेदारों (tenants) के साथ शेड्यूल करता है, और इसका वास्तविक परीक्षण उस सर्वर पर होता है जिसे आपने किराए पर लिया है:

vmstat 1 10

st कॉलम को देखें। यह उस समय के प्रतिशत को दर्शाता है जब आपका vCPU चलने के लिए तैयार था, लेकिन हाइपरवाइजर ने physical core किसी और को दे दिया था। लोड के दौरान कुछ प्रतिशत की कमी सामान्य है। यदि यह आंकड़ा लगातार दो अंकों (double-digit) में रहता है, तो इसका मतलब है कि होस्ट oversubscribed है, और RAM की कोई भी कम कीमत उस कोर की भरपाई नहीं कर सकती जिसे आप उपयोग ही नहीं कर पा रहे हैं। इसे अपने व्यस्त समय (busy hour) में चलाकर देखें, क्योंकि steal time एक पड़ोसी की समस्या है और पड़ोसियों का अपना शेड्यूल होता है। स्टोरेज और ट्रैफिक जुड़ने के बाद होस्टिंग की वास्तविक मासिक लागत के व्यापक दृष्टिकोण के लिए, VPS की मासिक लागत क्या है पढ़ें।

शामिल ट्रांसफर की वास्तविक लागत

[
  {
    "provider": "DigitalOcean 1 GB",
    "included_tb": 1,
    "overage_usd_per_tb": "10.00"
  },
  {
    "provider": "Akamai Nanode 1 GB",
    "included_tb": 1,
    "overage_usd_per_tb": "5.00"
  },
  {
    "provider": "Vultr NVMe 1 GB",
    "included_tb": 2,
    "overage_usd_per_tb": "10.00"
  },
  {
    "provider": "Hetzner CX23 4 GB",
    "included_tb": 20,
    "overage_usd_per_tb": "1.20"
  }
]

DigitalOcean अपने एंट्री प्लान में 1 TB आउटबाउंड ट्रांसफर शामिल करता है और अतिरिक्त उपयोग के लिए GiB के हिसाब से बिल करता है, जो प्रति अतिरिक्त TB लगभग $10.00 बैठता है। Akamai इतनी ही TB शामिल करता है और उससे लगभग आधी कीमत, यानी प्रति TB लगभग $5.00 चार्ज करता है। Vultr समान ओवरएज दर पर 2 TB शामिल करता है। Hetzner 20 TB शामिल करता है और उसके बाद प्रति TB लगभग $1.20 चार्ज करता है, जो अन्य प्रदाताओं की तुलना में काफी कम है।

मुख्य आंकड़ों से अधिक तीन संरचनात्मक विवरण मायने रखते हैं। इन चारों प्रदाताओं पर इनबाउंड ट्रैफिक मुफ्त है, इसलिए केवल वही गिना जाता है जिसे आप बाहर भेजते हैं। DigitalOcean और Vultr अकाउंट के सभी सर्वर्स के बीच कोटा को पूल करते हैं, इसलिए एक व्यस्त मशीन दूसरी मशीन का कोटा इस्तेमाल कर सकती है और छोटे सर्वर्स का एक समूह एक बड़े पूल को साझा करता है। इसके अलावा, प्राइवेट या VPC नेटवर्क पर सर्वर्स के बीच का ट्रैफिक आमतौर पर बिल्कुल नहीं गिना जाता है, यही कारण है कि अपने डेटाबेस को प्राइवेट इंटरफेस पर रखना सुरक्षा के साथ-साथ एक बिलिंग निर्णय भी है।

यदि आप सीमा के आसपास भी नहीं हैं, तो इनमें से कुछ भी मायने नहीं रखता। एक ब्लॉग, JSON रिस्पॉन्स वाला API या एक छोटा SaaS महीने में 1 TB तक नहीं पहुंचेगा। वीडियो, इमेज गैलरी, गेम सर्वर्स, पैकेज मिरर्स और ऑफ-साइट बैकअप टारगेट्स ऐसा कर सकते हैं। अनुमान लगाने से पहले मापें:

sudo apt update && sudo apt install -y vnstat
sudo systemctl enable --now vnstat
vnstat -m

vnstat -m महीने के अनुसार ट्रांसफर को प्रिंट करता है, जिसे प्राप्त और प्रेषित (received and transmitted) में विभाजित किया जाता है। केवल प्रेषित कॉलम के लिए बिल किया जाता है। डेटाबेस खाली शुरू होता है, इसलिए पहली उपयोगी रीडिंग आपके द्वारा इसे इंस्टॉल करने के एक दिन बाद आती है, और पहला पूरा महीना एक महीने बाद आता है। तब तक प्रदाता का अपना बैंडविड्थ ग्राफ ही एकमात्र रिकॉर्ड होता है जो आपके पास होता है।

एक और सवाल पूछें जिसका जवाब कोई भी मूल्य सूची नहीं देती: जब आप सीमा पार कर जाते हैं, तो क्या प्रदाता आपको बिल भेजता है या पोर्ट को थ्रॉटल (throttle) कर देता है। बिलिंग में पैसे खर्च होते हैं। थ्रॉटलिंग में यूजर्स का नुकसान होता है, ठीक उसी समय जब आपके पास सबसे अधिक यूजर्स होते हैं। आपको यह जानना चाहिए कि ट्रैफिक स्पाइक होने पर क्या होगा।

NVMe या SATA, और यह कैसे जाँचें कि आपको वास्तव में क्या मिला है

पैनल पर NVMe लिखा होता है। यह होस्ट में लगी डिस्क के बारे में एक दावा है, और हो सकता है कि आपकी वर्चुअल मशीन उन पर न चल रही हो। लोकल स्टोरेज आपकी वर्चुअल डिस्क को उसी फिजिकल मशीन के अंदर मौजूद ड्राइव पर रखता है। नेटवर्क स्टोरेज इसे डेटासेंटर नेटवर्क के माध्यम से एक्सेस किए जाने वाले एक अलग स्टोरेज क्लस्टर पर रखता है, जो इंस्टेंट रिसाइज, लाइव माइग्रेशन और स्नैपशॉट-इन-प्लेस को संभव बनाता है।

गेस्ट के अंदर, दोनों एक जैसे दिखते हैं:

lsblk -d -o NAME,ROTA,MODEL,SIZE
cat /sys/block/vda/queue/rotational

ROTA और rotational किसी भी ऐसी चीज़ के लिए 0 रिपोर्ट करते हैं जिसे होस्ट नॉन-रोटेशनल घोषित करता है, इसलिए NVMe द्वारा समर्थित नेटवर्क वॉल्यूम बिल्कुल वही रिपोर्ट करता है जो लोकल NVMe करता है। यह मान आपको बताता है कि डिस्क घूमने वाली प्लैटर नहीं है। यह आपको यह नहीं बता सकता कि डिस्क कहाँ स्थित है। Linux पर NVMe डिस्क की पुष्टि करना डिवाइस नामों और उनके अर्थों के बारे में विस्तार से बताता है।

जो परीक्षण उन्हें अलग करता है वह है queue depth 1 पर लेटेंसी, क्योंकि एक छोटे से रीड ऑपरेशन के पास छिपाने के लिए कुछ नहीं होता। लोकल NVMe उसी चेसिस से जवाब देता है। नेटवर्क वॉल्यूम हर एक रीड के लिए डेटासेंटर नेटवर्क पर एक राउंड ट्रिप जोड़ता है, इसलिए इसकी लेटेंसी का न्यूनतम स्तर अधिक होता है, भले ही गहरी queue depth पर इसका थ्रूपुट समान दिखे।

sudo apt update && sudo apt install -y fio
fio --name=lat --filename=/var/tmp/fiotest --size=1G --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based --group_reporting
fio --name=iops --filename=/var/tmp/fiotest --size=1G --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 --iodepth=32 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fiotest

पहला रन एक clat ब्लॉक प्रिंट करता है, जो कंप्लीशन लेटेंसी है। औसत के बजाय 99th percentile लाइन को पढ़ें, क्योंकि औसत उन रुकावटों को छिपा देता है जिन्हें उपयोगकर्ता महसूस करते हैं। दूसरा रन अपनी समरी लाइन पर IOPS= प्रिंट करता है। दोनों को अपने वर्तमान प्रदाता पर और जिस प्रदाता पर आप विचार कर रहे हैं उसके ट्रायल इंस्टेंस पर, एक ही दिन चलाएं, और अपने दोनों नंबरों की तुलना करें। किसी भी वेंडर द्वारा प्रकाशित आंकड़े एक ऐसी मशीन पर मापे गए थे जिसे आप देख नहीं सकते। इसे अलग-अलग घंटों में तीन बार चलाएं, क्योंकि एक ही प्लान पर एक शांत होस्ट और एक व्यस्त होस्ट अलग-अलग परिणाम देते हैं। VPS की उचित बेंचमार्किंग इस विधि को कवर करती है, और SSD VPS का वास्तविक अर्थ इसके पीछे के मार्केटिंग शब्दों को स्पष्ट करता है।

Regions: latency मापें, नक्शा न देखें

Region की सूची केवल मार्केटिंग है जब तक आप उसे मापते नहीं हैं। उपयोगकर्ता को जो महसूस होता है वह उनके नेटवर्क से आपके सर्वर तक का round trip है, और यह इस बात पर निर्भर करता है कि उनके packets किस रास्ते से जाते हैं, न कि नक्शे पर मौजूद दूरी पर। 300 km दूर स्थित एक सर्वर, जो congested transit link के पीछे है, 1,500 km दूर स्थित उस सर्वर से हार जाता है जो एक साफ रास्ते पर है।

ping -c 20 203.0.113.10
mtr -rwc 50 203.0.113.10
curl -o /dev/null -s -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} total %{time_total}\n' https://example.com

mtr हर hop को उसके अपने loss और latency के साथ print करता है, इसलिए दो hops के बीच 60 ms का jump उस link को दर्शाता है जो समस्या पैदा कर रहा है, न कि destination को दोष देता है। इसे उस नेटवर्क पर मौजूद मशीन से चलाएं जिस पर आपके उपयोगकर्ता हैं। Datacentre-to-datacentre routes इंटरनेट पर सबसे अच्छे रास्ते होते हैं, और वे हर provider को समान रूप से बेहतर दिखाते हैं।

एक संरचनात्मक बिंदु किसी भी मूल्य परिवर्तन के बाद भी बना रहता है। आपके महाद्वीप पर केवल एक region वाला provider होने का मतलब है कि आपका disaster recovery plan महाद्वीपों को बदलने का एक प्लान है, जिसमें वह latency भी शामिल है जो इसके साथ आती है। उन regions की गिनती करें जिन पर आप वास्तव में fail over करेंगे, न कि उन regions की जो पेज पर लिखे हैं।

Snapshots और backups का बिल अलग होता है

Storage add-ons वह जगह है जहाँ एक सस्ता plan महंगा हो जाता है। DigitalOcean snapshots के लिए प्रति GiB $0.06 प्रति माह का शुल्क लेता है, और automatic backups की कीमत server के एक हिस्से के रूप में तय करता है: weekly backups के लिए plan की कीमत का 20%, daily के लिए 30%, और GiB के आधार पर usage-based विकल्प भी उपलब्ध है। दोनों मॉडल तर्कसंगत हैं लेकिन दोनों की अपनी सीमाएं हैं। प्रतिशत-आधारित कीमत server के आकार के साथ बढ़ती है, इसलिए यदि एक बड़े server पर छोटा डेटासेट है, तो आप अधिक भुगतान करते हैं। प्रति GiB कीमत आपके डेटा के साथ बढ़ती है, इसलिए यदि एक छोटे server के साथ बड़ी volume जुड़ी है, तो आप अधिक भुगतान करते हैं।

यह पूछें कि restore करने में कितना खर्च आता है और कितना समय लगता है, क्योंकि backup को सुरक्षित रखना तो केवल आधा काम है। यह भी सुनिश्चित करें कि क्या server को delete करने पर उसके snapshots भी delete हो जाते हैं।

इसके बाद, एक ऐसी copy रखें जिसे provider नियंत्रित न करता हो। Provider के snapshots उसी के account के भीतर रहते हैं, इसलिए login खोने, payment विफल होने या account suspend होने पर server और उसके backups दोनों एक साथ चले जाते हैं। restic backups into storage you own में object storage के लिए कुछ डॉलर का खर्च आता है, इन्हें किसी भी provider पर restore किया जा सकता है, और यही वह तरीका है जो migration को अंतिम होने के बजाय reversible बनाता है।

आप स्टैक का कितना हिस्सा चलाना चाहते हैं

Providers एक स्पेक्ट्रम पर स्थित होते हैं। एक छोर पर आप एक मशीन किराए पर लेते हैं और सब कुछ खुद चलाते हैं। दूसरे छोर पर आप केवल एक git branch push करते हैं और सर्वर कभी नहीं देखते। प्रति GB RAM की कीमत की तुलना केवल पहले छोर पर ही सही है, क्योंकि दूसरे छोर पर आप मेमोरी के बजाय श्रम (labour) खरीद रहे होते हैं, और श्रम की कोई प्रति GB कीमत नहीं होती।

किसी भी चीज़ की तुलना करने से पहले ईमानदार रहें कि आप किस छोर पर हैं। $15.15 प्रति माह वाला एक managed database $6 वाले सर्वर की तुलना में महंगा लग सकता है, जब तक कि आप इसके पीछे के घंटों की कीमत न जोड़ें: replication, failover, point in time restore, minor version upgrades, और वह अलर्ट जो किसी को रात 03:00 बजे जगाता है। यदि यह काम आपकी नौकरी है, तो इसे स्वयं चलाएं और अंतर बचाएं। यदि आपकी नौकरी application है, तो इसे खरीदना सस्ता है। Managed और unmanaged का विभाजन यह तय करता है कि आपको मूल्य सूची का कौन सा कॉलम पढ़ना चाहिए। यदि ईमानदार उत्तर यह है कि आप पूरी मशीन और उसकी डिस्क स्वयं चाहते हैं, तो यह एक VPS बनाम dedicated सर्वर का प्रश्न है, न कि किसी provider का।

जहाँ DigitalOcean सही विकल्प है

DigitalOcean तब बेहतर साबित होता है जब आप वर्चुअल मशीन के बजाय एक पूरा प्लेटफॉर्म खरीद रहे हों।

• Managed databases. Managed PostgreSQL और MySQL की शुरुआत $15.15 प्रति माह से होती है, जिसमें 1 GiB RAM और 10 GiB स्टोरेज मिलता है। अतिरिक्त स्टोरेज के लिए प्रति GiB शुल्क लिया जाता है और standby nodes की कीमत प्रति नोड के आधार पर तय होती है। इसी तरह की विश्वसनीयता खुद तैयार करने का मतलब है Patroni या repmgr, एक consensus store, एक connection proxy और failover drill का उपयोग करना, जिसका आपने वास्तव में अभ्यास किया हो। दो लोगों की टीम इसे मेंटेन नहीं कर सकती और साथ ही नए फीचर्स पर काम नहीं कर सकती।
• App Platform. एक branch push करें, आपको एक build, एक certificate और एक running service मिल जाएगी, जिसमें आपको किसी ऑपरेटिंग सिस्टम को पैच करने की आवश्यकता नहीं है। इस उत्पाद का सस्ता VPS संस्करण आप स्वयं हैं, जो शनिवार को काम कर रहे हैं।
• Object storage और load balancers जिन्हें एक mature Terraform provider कवर करता है। एक ऐसा fleet जिसे आप कोड के जरिए नष्ट और पुनः निर्मित कर सकते हैं, उसकी कीमत कम यूनिट प्राइस से कहीं अधिक है।
• उत्पाद के पीछे की कंपनी। प्रकाशित support tiers, इतिहास के साथ एक status page, और एक ऐसा संगठन जो क्लाइंट की सुरक्षा प्रश्नावली (security questionnaire) का उत्तर देगा। यदि आप होस्टिंग को रीसेल करते हैं, तो यह प्रति GB कुछ डॉलर से कहीं अधिक मूल्यवान है।

DigitalOcean तब महंगा हो जाता है जब आप बड़ी मात्रा में साधारण वर्चुअल मशीनें लेते हैं और उनमें वास्तविक outbound traffic होता है। यह वही स्थिति है जिसे कोई विकल्प ठीक करता है, और यही वह चीज़ है जिसे अधिकांश self-hosting डेवलपर्स खरीदते हैं।

बिना डाउनटाइम के नए प्रदाता पर माइग्रेट करें

माइग्रेशन के दौरान डाउनटाइम का मुख्य कारण यह है: डेटा के नए सर्वर पर जाने के बाद भी ट्रैफिक का पुराने IP पर आना। नीचे दिए गए प्रत्येक चरण का उद्देश्य इस अवधि को छोटा और अनुमानित बनाना है।

DNS के साथ शुरुआत करें, माइग्रेशन से कम से कम 48 घंटे पहले। Resolvers आपके A record को उसके TTL (time to live) की अवधि तक कैश (cache) करते हैं। इसलिए, 24 घंटे के TTL वाला रिकॉर्ड बदलने के बाद भी एक दिन तक उपयोगकर्ताओं को पुराने सर्वर पर भेजता रहता है। कटओवर के समय TTL कम करने से कोई मदद नहीं मिलती, क्योंकि resolvers पहले से ही पुरानी समाप्ति तिथि के साथ पुरानी वैल्यू को होल्ड किए होते हैं। पहले इसे कम करें, पुरानी वैल्यू के समाप्त होने की प्रतीक्षा करें, फिर माइग्रेट करें।

dig +noall +answer example.com A
dig +noall +authority example.com SOA

पहली कमांड उत्तर के दूसरे कॉलम में वर्तमान TTL प्रिंट करती है। इसे अपने DNS प्रदाता पर 300 पर सेट करें, फिर उस संख्या से अधिक प्रतीक्षा करें जिसे आपने अभी बदला है।

फिर इस क्रम में काम करें।

1. नया सर्वर प्रोविजन करें और उस पर कुछ भी डालने से पहले उसे सुरक्षित (harden) करें। नए VPS पर पहले दस मिनट उस हिस्से को कवर करता है जिसे लोग जल्दबाजी में छोड़ देते हैं।
2. एप्लिकेशन स्टैक इंस्टॉल करें और rsync के साथ डेटा कॉपी का पहला राउंड चलाएं, जबकि पुराना सर्वर सामान्य रूप से काम करता रहे।
3. नए होस्ट पर अभी TLS सर्टिफिकेट जारी करें, DNS-01 challenge का उपयोग करके। HTTP-01 challenge उस IP के विरुद्ध वैलिडेट करता है जिस पर DNS वर्तमान में पॉइंट करता है, जो अभी भी पुराना सर्वर है। DNS-01 challenge इस क्रमबद्ध समस्या को पूरी तरह से हटा देता है।
4. किसी भी सार्वजनिक बदलाव से पहले अपने लैपटॉप पर DNS को ओवरराइड करके नए होस्ट का परीक्षण करें। 203.0.113.20 example.com को /etc/hosts में जोड़ें, वास्तविक साइट ब्राउज़ करें, फिर लाइन को हटा दें। इस परीक्षण से कोई भी उपयोगकर्ता प्रभावित नहीं होता है।
5. डेटाबेस के आकार के प्रश्न को हल करें। कुछ GB से कम डेटा के लिए, डंप और रिस्टोर राइट फ्रीज (write freeze) के भीतर फिट हो जाता है। उससे ऊपर के लिए, पुराने डेटाबेस से नए डेटाबेस में दिनों पहले रेप्लिकेशन सेट करें और उसे सिंक होने दें, ताकि फ्रीज केवल प्रमोशन तक ही सीमित रहे।
6. राइट्स को फ्रीज करें। एप्लिकेशन को मेंटेनेंस या रीड-ओनली मोड में डालें। यह एकमात्र हिस्सा है जिसे उपयोगकर्ता देख सकते हैं, और इसमें केवल कुछ मिनट लगने चाहिए।
7. अंतिम डेल्टा चलाएं: वही rsync फिर से, फिर अंतिम डेटाबेस सिंक।
8. A और AAAA रिकॉर्ड्स को नए IP पर बदलें। 300 सेकंड के TTL के साथ, अधिकांश resolvers लगभग पांच मिनट के भीतर इसका पालन करते हैं।
9. पुराने सर्वर को कम से कम एक दिन के लिए चालू और पहुंच योग्य रखें, क्योंकि कुछ resolvers छोटे TTLs को अनदेखा कर देते हैं। यदि पुराना एप्लिकेशन अभी भी लिखने योग्य है, तो देर से आने वाले ट्रैफिक गलत डेटाबेस में लिखेंगे। इसलिए पुराने होस्ट को नए डेटाबेस पर पॉइंट करें या उससे मेंटेनेंस पेज दिखाएं।
10. एक दिन के लिए नए सर्वर की एरर रेट पर नज़र रखें, TTL को वापस उसकी सामान्य वैल्यू पर सेट करें, और पुराने सर्वर को उसी शाम के बजाय एक सप्ताह बाद नष्ट करें।

कॉपी करने की प्रक्रिया में दो कमांड्स हैं, जिन्हें दो बार चलाया जाता है। फाइल सिंक:

rsync -aHAX --numeric-ids --delete -e ssh /srv/ deploy@203.0.113.20:/srv/

-a ओनरशिप, अनुमतियों और टाइमस्टैम्प को सुरक्षित रखता है, -H हार्ड लिंक्स को बनाए रखता है, -AX ACLs और एक्सटेंडेड एट्रिब्यूट्स को रखता है, और --numeric-ids rsync को दो मशीनों के बीच भिन्न यूजर IDs को रीमैप करने से रोकता है। इसे दिनों पहले चलाएं, फिर फ्रीज के दौरान दोबारा, जब यह केवल वही ट्रांसफर करेगा जो बदल गया है।

PostgreSQL के लिए जो डंप करने के लिए पर्याप्त छोटा है:

pg_dump --format=custom --no-owner --dbname=appdb --file=appdb.dump
scp appdb.dump deploy@203.0.113.20:/var/tmp/
pg_restore --clean --if-exists --no-owner --dbname=appdb /var/tmp/appdb.dump

MySQL या MariaDB के लिए:

mysqldump --single-transaction --routines --triggers --databases appdb > appdb.sql

--single-transaction InnoDB टेबल्स पर एक ट्रांजेक्शन के भीतर डंप लेता है, इसलिए परिणाम सुसंगत (consistent) रहता है और एप्लिकेशन चलते समय लिखता रहता है। इस फ्लैग के बिना mysqldump टेबल्स को लॉक कर देता है, जिसका अर्थ है कि आपका राइट फ्रीज आपकी योजना से पहले शुरू हो गया और आपने समय नहीं चुना।

दो चीजें आपके सर्वर के बाहर खराब हो सकती हैं। एक नए IP एड्रेस की कोई ईमेल प्रतिष्ठा (reputation) नहीं होती है, इसलिए नए बॉक्स से सीधे भेजा गया मेल स्पैम के रूप में फिल्टर हो जाता है: ऐसे रिले के माध्यम से भेजें जिसकी पहले से ही प्रतिष्ठा है। और कोई भी पार्टनर जो आपके आउटबाउंड IP को allowlist करता है, जैसे कि पेमेंट गेटवे या क्लाइंट फायरवाल, उसे कटओवर से पहले अपडेट किया जाना चाहिए, अन्यथा ट्रैफिक मूव होते ही वे कॉल विफल होने लगेंगे।

Commit करने से पहले क्या जाँचें

• क्या कीमत promotional है और renewal के समय यह कितनी होगी। पहले term पर मिलने वाली छूट जो renewal पर दोगुनी हो जाती है, वह एक वास्तविक लागत है, जिसे केवल आगे के लिए टाला गया है।
• क्या term prepaid है। Multi-year prepaid plans, जिस तरह से SSD Nodes बेचता है, वे अग्रिम भुगतान के बदले प्रति GB RAM की बहुत कम कीमत प्रदान करते हैं। इसमें समझौता यह है कि आप अगले महीने सेवा नहीं छोड़ सकते, इसलिए अपनी निश्चितता के अनुसार ही term चुनें।
• प्रति माह snapshot की लागत क्या है, और restore करने में कितना पैसा और कितना समय लगता है।
• क्या overage के लिए billing की जाती है या उसे throttled किया जाता है।
• क्या IPv6 को ठीक से route किया गया है या यह केवल एक अलग से जोड़ा गया address है।
• यदि आप हाथ से बनाने के बजाय code से rebuild करना चाहते हैं, तो क्या कोई ऐसा API है जिसका Terraform provider maintain किया जाता है।
• support तक कैसे पहुँचा जाए, और server down होने की स्थिति में response का निर्धारित समय क्या है, न कि केवल sales संबंधी प्रश्नों के लिए।

उस आधार पर निर्णय लें जो आपके बिल में सबसे अधिक प्रभाव डालता है। यदि वह memory है, तो प्रति GB RAM की कीमत निर्णायक है। यदि वह outbound traffic है, तो शामिल transfer limit निर्णायक है। यदि वह आपका अपना समय है, तो managed platform निर्णायक है, और यहाँ तुलना किए गए चारों विकल्पों में DigitalOcean सबसे मजबूत है।

FAQ

क्या Hetzner हमेशा DigitalOcean से सस्ता होता है?

एक साधारण virtual machine के लिए, यह प्रति GB RAM के हिसाब से काफी सस्ता है: 5 अगस्त 2026 तक entry shared plans पर यह लगभग $1.62 है, जबकि DigitalOcean पर यह $6.00 है। जब managed services की बात आती है तो यह तुलना बदल जाती है। Hetzner केवल servers और networking बेचता है, इसलिए managed database या push-to-deploy platform आपको खुद या किसी third party के जरिए प्रबंधित करना होगा, और उन घंटों की अपनी लागत होती है। Hetzner ने 2026 के दौरान अपनी cloud कीमतें भी बढ़ाई हैं, इसलिए किसी पुराने लेख पर भरोसा करने के बजाय वर्तमान euro मूल्य की जाँच करें।

यदि मुझे managed database की आवश्यकता है, तो मुझे कौन सा DigitalOcean विकल्प चुनना चाहिए?

Vultr और Akamai दोनों managed databases बेचते हैं, इसलिए यदि managed database ही वह कारण है जिसकी वजह से आप DigitalOcean का उपयोग कर रहे हैं, तो ये सबसे करीबी विकल्प हैं। कम लागत वाले यूरोपीय hosts आमतौर पर managed database नहीं बेचते हैं, जिसका अर्थ है कि आपको PostgreSQL या MySQL को स्वयं चलाना होगा, जिसमें replication और tested failover भी शामिल है। यह एक वास्तविक जिम्मेदारी है। निर्णय लेने से पहले कि सस्ता सर्वर आपके पैसे बचा रहा है, इसकी तुलना $15.15 प्रति माह की लागत वाले managed 1 GiB instance से करें।

मैं बिना downtime के live site को नए provider पर कैसे ले जाऊं?

स्थानांतरण से कम से कम 48 घंटे पहले DNS TTL को 300 seconds पर कम कर दें, क्योंकि resolvers पुराने TTL के समाप्त होने तक पुराने IP को ही serve करते रहते हैं। नए host को तब तैयार और test करें जब पुराना host अभी भी traffic serve कर रहा हो, इसके लिए अपनी मशीन पर /etc/hosts override का उपयोग करें ताकि अन्य users इसे न देख सकें। फिर कुछ मिनटों के लिए writes को freeze करें, अंतिम rsync delta और database sync चलाएं, A और AAAA records को switch करें, और पुराने सर्वर को एक सप्ताह तक चालू रखें, ताकि यदि किसी resolver ने छोटे TTL को अनदेखा किया हो, तो भी काम चलता रहे।

क्या सस्ते VPS का मतलब धीमी disks है?

स्वयं में ऐसा नहीं है। मायने यह रखता है कि आपकी virtual disk host के local है या network storage cluster पर, और control panel में यह शायद ही कभी बताया जाता है। lsblk -o NAME,ROTA दोनों के लिए 0 रिपोर्ट करता है, क्योंकि दोनों non-rotational हैं। इसके बजाय मापें: --iodepth=1 --bs=4k --direct=1 के साथ fio चलाएं और 99th percentile completion latency को देखें। एक network volume हर read के साथ एक datacentre network round trip जोड़ता है, इसलिए इसकी latency floor local NVMe से अधिक होती है, भले ही deep-queue throughput समान दिखाई दे।

क्या मेरा email नए सर्वर से deliver होगा?

अक्सर शुरुआत में ऐसा नहीं होता है। एक नए IP address का कोई sending history नहीं होता है, इसलिए प्राप्तकर्ता सर्वर इसे संदिग्ध मानते हैं और mail spam में चला जाता है या सीधे reject कर दिया जाता है। जब तक आप update नहीं करते, SPF और DKIM records भी पुराने host की ओर ही इशारा करते हैं। application mail को किसी ऐसे relay या email service के माध्यम से भेजें जिसकी reputation पहले से बनी हुई है, और cutover के बाद के बजाय पहले ही mail के लिए DNS records को update कर लें।