SSD Nodes Learn Hosting plans →
मार्गदर्शक Matt Connorद्वारे Matt Connor

DigitalOcean चे developer साठी सर्वोत्तम पर्याय

RAM प्रति GB किंमत, समाविष्ट transfer, NVMe storage आणि backup खर्चाची तुलना करा. downtime टाळण्यासाठी cutover plan व provider बदलण्याची स्पष्ट पावले मिळवा.

DigitalOcean चे पर्याय प्रत्यक्षात काय बदलतात

बहुतेक DigitalOcean पर्याय केवळ बिल बदलतात, मशीन नाही. तुम्हाला दोन्ही ठिकाणी सार्वजनिक IP, virtio डिस्क आणि root ॲक्सेस असलेले Linux व्हर्च्युअल मशीन मिळते आणि तुमच्या कर्नलला कंट्रोल पॅनेलवर कोणाचा लोगो आहे याने काहीही फरक पडत नाही. निवडीचे निकष म्हणजे प्रति GB RAM ची किंमत, समाविष्ट ट्रान्सफर अलाउन्सचे प्रमाण आणि त्यावरील प्रत्येक बाइटचा खर्च, डिस्क कशापासून बनलेली आहे आणि ऑपरेटिंग सिस्टमच्या वरचा किती स्टॅक तुमच्यासाठी दुसरा कोणीतरी चालवणार आहे.

हे मार्गदर्शक या निकषांवर तुलना करते, कारण एक डेव्हलपर टर्मिनलवरून किंवा प्रकाशित किंमत सूचीवरून यातील प्रत्येक गोष्ट तपासू शकतो. हे मार्गदर्शक अशा परिस्थितींचीही नावे देते जिथे DigitalOcean हाच योग्य पर्याय आहे, कारण कोणतीही सवलत न देणारी तुलना ही केवळ जाहिरात असते.

खालील प्रत्येक किंमत ही प्रकाशित सूची किंमत आहे, जी 5 August 2026 रोजी तपासली गेली आहे. DigitalOcean चे आकडे 21 October 2026 रोजी पुन्हा तपासले गेले आणि त्यात कोणताही बदल झालेला नव्हता. किमती बदलतात आणि येथे असलेल्या एकापेक्षा जास्त प्रोव्हाइडर्सनी 2026 मध्ये त्यांच्या किमती बदलल्या आहेत. किमतीची रचना (pricing structure) खूप हळू बदलते, म्हणून आधी गुणोत्तर आणि बिलिंग मॉडेल वाचा, त्यानंतर तुम्ही निर्णय घेण्यापूर्वी प्रोव्हाइडरच्या स्वतःच्या पेजवर आजचे आकडे तपासा.

RAM च्या प्रति GB किमतीची तुलना करणे

तक्ताMonthly list price per GB of RAM, small shared-CPU plans, checked 5 August 2026
या तक्त्यामागील डेटा
[
  {
    "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 (unavailable Oct 2026)",
    "ram_gb": 4,
    "monthly_usd": "6.49",
    "usd_per_gb_ram": "1.62"
  }
]

एकाच प्रोव्हायडरच्या सेवांमध्ये RAM च्या प्रति GB किमतीत फारसा फरक पडत नाही. DigitalOcean च्या 1 GB प्लॅनवर प्रति GB $6.00 आणि 4 GB प्लॅनवर, ज्याची मासिक किंमत $24.00 आहे, प्रति GB $6.00 आकारले जातात. एकाच प्रोव्हायडरकडे मोठा प्लॅन निवडल्याने कोणतीही सवलत मिळत नाही, त्यामुळे प्लॅनचा आकार हा निर्णय घेण्याचा निकष नसून प्रोव्हायडरची निवड हा मुख्य निकष आहे.

Akamai, जी आता पूर्वीची Linode सेवा चालवते, त्यांच्या 2 GB आणि 4 GB शेअर्ड प्लॅनसाठी अनुक्रमे $12 आणि $24 आकारते, जे DigitalOcean च्या किमतीशी तंतोतंत जुळते. त्यांचा एंट्री प्लॅन $5.00 किमतीत स्वस्त पडतो. दोन कंपन्यांच्या किमती तंतोतंत जुळणे हे एक महत्त्वाचे संकेत आहे: या श्रेणीतील किमती हार्डवेअरच्या खर्चावर आधारित नसून स्पर्धकाच्या किमतीवर आधारित आहेत आणि त्या भविष्यातही स्पर्धकाच्या किमतीनुसारच बदलत राहतील.

स्वतःचे डेटासेंटर असणाऱ्या आणि युरोमध्ये विक्री करणाऱ्या प्रोव्हायडर्सच्या बाबतीत मोठी तफावत दिसून येते. 5 ऑगस्ट 2026 रोजी, Hetzner CX23 प्लॅनमध्ये तुम्हाला 4 GB RAM साधारण $6.49 प्रति महिना या दराने मिळत होती, म्हणजेच प्रति GB $1.62, जे DigitalOcean च्या दराच्या जवळपास एक चतुर्थांश आहे. 21 ऑक्टोबर 2026 रोजी तुम्ही हा प्लॅन ऑर्डर करू शकत नाही. Hetzner ने CX23 आणि त्यांच्या Cost-Optimized श्रेणीतील इतर सर्व प्लॅन सध्या उपलब्ध नसल्याचे दर्शवले आहे, कारण ही श्रेणी जुन्या हार्डवेअरवर चालते आणि सर्व्हरची संख्या मर्यादित आहे. त्यांच्या स्टेटस पेजवर 26 जून 2026 पासून क्लाउड इन्स्टन्सच्या मर्यादित उपलब्धतेबद्दलची सूचना आहे आणि ती 21 ऑक्टोबर 2026 रोजीही कायम होती. जो प्लॅन तुम्ही ऑर्डर करू शकत नाही, त्याच्या प्रति GB किमतीची तुलना करण्यात अर्थ नाही. 6 ऑक्टोबर 2026 रोजी Hetzner ने CPX02 हा नवीन प्लॅन सादर केला, ज्यामध्ये 1 vCPU, 1 GB RAM आणि 20 GB NVMe आहे. 21 ऑक्टोबर 2026 रोजी Hetzner च्या पेजवर EU लोकेशन्ससाठी याची किंमत VAT वगळून €6.49 प्रति महिना दर्शवली होती, म्हणजेच डॉलरमध्ये रूपांतर करण्यापूर्वी प्रति GB €6.49, जे DigitalOcean च्या $6.00 च्या तुलनेत आहे. त्याच पेजवर CPX02 आणि इतर सर्व Regular Performance प्लॅन सध्या उपलब्ध नसल्याचे चिन्हांकित केले होते, त्यामुळे तुलना करण्यापूर्वी तुम्हाला हव्या असलेल्या लोकेशनमध्ये तो उपलब्ध आहे का, याची खात्री करा. Hetzner साठीची कोणतीही डॉलर किंमत ही युरोच्या मूळ किमतीवरून रूपांतरित केलेली असते, त्यामुळे ती विनिमय दराप्रमाणे बदलत राहते. Hetzner ने 2026 मध्ये क्लाउडच्या किमती वाढवल्या आहेत, त्यामुळे जुन्या तुलनात्मक पोस्टमधील आकडे आता कालबाह्य झाले आहेत.

RAM च्या प्रति GB किमतीवरून तुम्हाला मिळणाऱ्या CPU बद्दल काहीही समजत नाही. शेअर्ड vCPU म्हणजे हायपरवायझर तुमच्या कोरला इतर वापरकर्त्यांच्या तुलनेत शेड्यूल करतो. याची खात्री करण्यासाठी तुम्ही भाड्याने घेतलेल्या सर्व्हरवर खालील चाचणी करा:

vmstat 1 10

st कॉलम वाचा. हा कॉलम तुमचा vCPU रन होण्यासाठी तयार असताना हायपरवायझरने तो फिजिकल कोर दुसऱ्या कोणाला दिला, याची टक्केवारी मोजतो. लोड असताना काही टक्के प्रमाण असणे सामान्य आहे. जर हे प्रमाण सतत दोन अंकी (double-digit) असेल, तर याचा अर्थ होस्ट ओव्हरसबस्क्राईब झाला आहे आणि तुम्ही वापरू शकत नसलेल्या कोरसाठी प्रति GB किंमत कितीही कमी असली तरी त्याचा उपयोग नाही. ही चाचणी तुमच्या व्यस्त तासांमध्ये (busy hour) करा, कारण 'steal time' ही शेजाऱ्यांशी संबंधित समस्या आहे आणि शेजाऱ्यांचे वेळापत्रक वेगळे असू शकते. स्टोरेज आणि ट्रॅफिक जोडल्यानंतर होस्टिंगचा महिन्याचा खरा खर्च किती येतो, हे समजून घेण्यासाठी VPS चा मासिक खर्च वाचा.

समाविष्ट ट्रान्सफरचा प्रत्यक्ष खर्च

तक्ताIncluded outbound transfer and overage price, same plans, checked 5 August 2026
या तक्त्यामागील डेटा
[
  {
    "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 (unavailable Oct 2026)",
    "included_tb": 20,
    "overage_usd_per_tb": "1.20"
  }
]

DigitalOcean त्यांच्या $6.00 च्या 1 GiB प्लॅनवर सुमारे 1 TB (1,000 GiB) आउटबाउंड ट्रान्सफर समाविष्ट करते आणि मर्यादेपेक्षा जास्त वापरासाठी प्रति GiB $0.01 आकारते, जे अतिरिक्त TB साठी सुमारे $10.00 इतके पडते. त्यांचा खरा एंट्री प्लॅन, जो $4.00 प्रति महिना दराने 512 MiB RAM देतो, त्यात फक्त 500 GiB समाविष्ट आहेत. ही मर्यादा प्लॅनच्या आकारानुसार वाढत जाऊन मोठ्या Basic प्लॅनवर 6,000 GiB पर्यंत पोहोचते, त्यामुळे तुम्ही निवडलेल्या प्लॅनसाठीची नेमकी आकडेवारी तपासा. Akamai त्यांच्या Nanode वर तितकेच TB समाविष्ट करते आणि त्यापेक्षा साधारण अर्धे, म्हणजे प्रति TB सुमारे $5.00 आकारते. Vultr समान ओव्हरएज दराने 2 TB समाविष्ट करते. 5 ऑगस्ट 2026 रोजी, Hetzner CX23 मध्ये 20 TB समाविष्ट होते आणि त्यानंतर प्रति TB सुमारे $1.20 आकारले जात होते, जे इतरांच्या तुलनेत खूपच कमी आहे. 21 ऑक्टोबर 2026 रोजी, Hetzner च्या पेजवर त्यांच्या EU लोकेशन्सवर 20 TB ट्रॅफिक समाविष्ट असल्याचे नमूद होते, जे CPX02 साठीही लागू होते. मात्र, सिंगापूर आणि US लोकेशन्सवर हे प्रमाण खूप कमी आहे, जिथे CPX02 ला सिंगापूरमध्ये 0.5 TB मिळते.

हेडलाईनवरील आकड्यांपेक्षा तीन संरचनात्मक बाबी अधिक महत्त्वाच्या आहेत. या चारही ठिकाणी इनबाउंड ट्रॅफिक मोफत आहे, त्यामुळे फक्त तुम्ही बाहेर पाठवलेल्या डेटाचीच गणना होते. DigitalOcean, Akamai आणि Vultr खात्यातील सर्व सर्व्हरसाठी ही मर्यादा एकत्रित (pool) करतात. त्यामुळे एका व्यस्त मशीनचा वापर दुसऱ्या मशीनच्या कोट्यातून वजा होतो आणि अनेक लहान सर्व्हर मिळून एका मोठ्या पूलचा वापर करतात. तसेच, खाजगी किंवा VPC नेटवर्कद्वारे सर्व्हरमधील ट्रॅफिक सहसा मोजले जात नाही. म्हणूनच तुमचा डेटाबेस खाजगी इंटरफेसवर ठेवणे हा सुरक्षेसोबतच खर्चाचाही निर्णय असतो.

जर तुमचा वापर मर्यादेच्या आसपासही नसेल, तर या गोष्टींचा काहीही फरक पडत नाही. एखादा ब्लॉग, JSON रिस्पॉन्स देणारे API किंवा लहान SaaS महिनाभरात 1 TB पर्यंत पोहोचणार नाहीत. मात्र, व्हिडिओ, इमेज गॅलरी, गेम सर्व्हर, पॅकेज मिरर आणि ऑफ-साइट बॅकअप टार्गेट्स सहजपणे ही मर्यादा ओलांडू शकतात. गृहीत धरण्यापूर्वी मोजमाप करा:

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

vnstat -m महिन्यानुसार ट्रान्सफरची माहिती प्रिंट करते, ज्याचे 'received' आणि 'transmitted' असे विभाजन असते. फक्त 'transmitted' कॉलमसाठी शुल्क आकारले जाते. डेटाबेस सुरुवातीला रिकामा असतो, त्यामुळे पहिली उपयुक्त माहिती तुम्ही तो इन्स्टॉल केल्यानंतर एक दिवसाने मिळते आणि पहिला पूर्ण महिना पूर्ण झाल्यावरच अचूक आकडेवारी मिळते. तोपर्यंत, प्रोव्हायडरचा स्वतःचा बँडविड्थ ग्राफ हाच तुमच्याकडे असलेला एकमेव रेकॉर्ड असतो.

कोणतीही किंमत सूची उत्तर देत नाही असा आणखी एक प्रश्न विचारा: जेव्हा तुम्ही मर्यादा ओलांडता, तेव्हा प्रोव्हायडर तुम्हाला बिल पाठवतो की पोर्टची गती मर्यादित (throttle) करतो? बिलिंगमुळे पैसे खर्च होतात. थ्रॉटलिंगमुळे वापरकर्ते गमावले जातात, आणि ते नेमके त्याच वेळी घडते जेव्हा तुमच्याकडे सर्वाधिक वापरकर्ते असतात. ट्रॅफिकमध्ये अचानक वाढ झाल्यास काय घडेल, हे तुम्हाला जाणून घेणे आवश्यक आहे.

NVMe किंवा SATA, आणि प्रत्यक्षात तुम्हाला काय मिळाले आहे ते कसे तपासावे

पॅनेलमध्ये NVMe असे दिसते. हा host मधील disks बद्दलचा दावा आहे; तुमची virtual machine त्याच disks वर चालत असेलच असे नाही. Local storage मध्ये तुमची virtual disk त्याच physical machine मधील drives वर असते. Network storage मध्ये ती datacentre network द्वारे जोडलेल्या स्वतंत्र storage cluster वर असते. त्यामुळे instant resize, live migration आणि snapshot-in-place शक्य होते.

Guest च्या आत दोन्ही एकसारखे दिसतात:

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

ROTA आणि rotational host ने non-rotational म्हणून घोषित केलेल्या कोणत्याही गोष्टीसाठी 0 दाखवतात. त्यामुळे NVMe वर आधारित network volume, local NVMe प्रमाणेच अहवाल देतो. या value वरून disk फिरणाऱ्या platter वर आधारित नाही हे समजते. Disk प्रत्यक्षात कुठे आहे हे मात्र समजत नाही. Linux वर NVMe disk निश्चित करणे या प्रक्रियेत device names आणि त्यांपैकी प्रत्येकाचा अर्थ स्पष्ट केला आहे.

दोन्हींमध्ये फरक करण्यासाठी queue depth 1 वरील latency तपासा. कारण एका छोट्या read मागे लपवण्यासाठी दुसरे कोणतेही काम नसते. Local NVMe त्याच chassis मधून उत्तर देते. Network volume मध्ये प्रत्येक read साठी datacentre network वरून round trip करावा लागतो. त्यामुळे deep queue depth वर throughput समान दिसत असला तरी त्याची latency floor जास्त असते.

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

पहिल्या run मध्ये clat block दाखवला जातो. ही completion latency आहे. Average ऐवजी 99th percentile line वाचा. Average मुळे वापरकर्त्यांना जाणवणारे stalls लपतात. दुसऱ्या run मध्ये summary line वर IOPS= दाखवले जाते. तुमच्याकडे असलेल्या provider वर आणि तुम्ही विचार करत असलेल्या provider च्या trial instance वर, त्याच दिवशी, दोन्ही tests चालवा आणि तुमच्या स्वतःच्या दोन values ची तुलना करा. कोणत्याही vendor ने प्रकाशित केलेली figure तुम्हाला दिसत नसलेल्या machine वर मोजलेली असते. वेगवेगळ्या hours मध्येही हे test तीन वेळा चालवा. कारण quiet host आणि busy host एकाच plan वर वेगवेगळी उत्तरे देतात. VPS चे योग्य benchmarking या पद्धतीचे स्पष्टीकरण देते, तर प्रत्यक्षात SSD VPS म्हणजे काय त्यामागील marketing शब्दांचे स्पष्टीकरण देते.

प्रदेश: latency मोजा, नकाशा वाचू नका

प्रदेशांची यादी तुम्ही latency मोजत नाही तोपर्यंत केवळ marketing असते. वापरकर्त्याला जाणवणारी गोष्ट म्हणजे त्याच्या network पासून तुमच्या server पर्यंतचा round trip. हे packets ज्या मार्गाने जातात त्यावर अवलंबून असते, नकाशावरील अंतरावर नाही. congested transit link मागे असलेला 300 km दूरचा server, स्वच्छ मार्गावरील 1,500 km दूरच्या server पेक्षा खराब ठरतो.

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 दाखवते. त्यामुळे दोन hop मधील 60 ms ची वाढ कोणत्या link मुळे समस्या निर्माण होत आहे हे स्पष्ट करते; destination ला विनाकारण दोष देता येत नाही. वापरकर्ते ज्या network वर आहेत, त्या network वरील machine वरून ते चालवा. Datacentre ते datacentre routes हे internet वरील सर्वोत्तम routes असतात. त्यामुळे ते प्रत्येक provider चे चित्र प्रत्यक्षापेक्षा चांगले दाखवतात.

किंमत बदलली तरी एक structural मुद्दा कायम राहतो. तुमच्या continent मध्ये एखाद्या provider कडे केवळ एक region असेल, तर तुमची disaster recovery plan म्हणजे continent बदलण्याची plan आहे आणि त्यासोबत संबंधित latency येते. पृष्ठावर दाखवलेल्या regions ची संख्या मोजू नका. तुम्ही प्रत्यक्षात fail over करू शकता अशा regions ची संख्या मोजा.

Snapshots आणि backups चे बिल वेगळे असते

Storage add-ons मुळे स्वस्त plan महाग होतो. DigitalOcean snapshots साठी दरमहा प्रति GiB $0.06 आकारते. Automatic backups साठी ती server plan च्या किमतीवर आधारित शुल्क आकारते: weekly backups साठी plan price च्या 20%, daily backups साठी 30%, तसेच प्रति GiB usage-based पर्यायही उपलब्ध आहे. दोन्ही pricing models योग्य ठरू शकतात, पण त्यांचे तोटे परस्परविरुद्ध आहेत. Percentage-based price server च्या आकारानुसार वाढते. त्यामुळे लहान dataset असलेल्या मोठ्या server साठी जास्त पैसे मोजावे लागतात. Per GiB price तुमच्या data च्या प्रमाणानुसार वाढते. त्यामुळे मोठ्या volume ला जोडलेल्या छोट्या server साठी जास्त पैसे मोजावे लागतात.

Restore साठी किती खर्च येतो आणि त्याला किती वेळ लागतो हे विचारा. Backup साठवून ठेवण्याची किंमत हा या प्रश्नाचा फक्त साधा भाग आहे. Server destroy केल्यावर त्याचे snapshots देखील नष्ट होतात का, हे विचारा.

त्यानंतर provider च्या नियंत्रणाबाहेर एक copy ठेवा. Provider snapshots त्याच provider च्या account मध्ये असतात. त्यामुळे login हरवणे, payment failure किंवा account suspend होणे यांपैकी कोणतीही घटना server आणि त्याचे backups एकाच वेळी अनुपलब्ध करू शकते. तुमच्या मालकीच्या storage मध्ये restic backups ठेवल्यास object storage साठी काही dollars खर्च होतात, ते backups कोणत्याही provider वर restore करता येतात आणि migration अंतिम न राहता परत उलटवता येण्यासारखी बनते.

तुम्हाला stack पैकी किती भाग स्वतः चालवायचा आहे

Providers एका सलग श्रेणीवर असतात. एका टोकाला तुम्ही एक machine भाड्याने घेता आणि त्यावर सर्व काही स्वतः चालवता. दुसऱ्या टोकाला तुम्ही git branch push करता आणि server कधीही पाहत नाही. पहिल्या टोकाला RAM च्या प्रत्येक GB ची किंमत ही योग्य तुलना असते. दुसऱ्या टोकाला मात्र तुम्ही memory ऐवजी labour खरेदी करत असता. Labour ची प्रत्येक GB मागे किंमत नसते.

कशाचीही तुलना करण्यापूर्वी तुम्ही या श्रेणीच्या कोणत्या टोकावर आहात हे प्रामाणिकपणे ठरवा. $15.15 प्रतिमाह managed database हा $6 server च्या तुलनेत महाग वाटतो. पण त्यामागील तासांचा खर्च मोजल्यानंतर चित्र बदलते: replication, failover, point in time restore, minor version upgrades आणि 03:00 वाजता कोणाला तरी जागे करणारा alert. हे काम तुमचे असेल, तर ते स्वतः करा आणि फरकाची रक्कम वाचवा. तुमचे काम application विकसित करणे असेल, तर हे काम पुन्हा बाहेरून घेणे स्वस्त ठरते. Managed आणि unmanaged मधील फरक यावरून price list मधील कोणता column पाहायचा हे ठरते. तुम्हाला संपूर्ण machine आणि तिचे disks स्वतःकडेच ठेवायचे आहेत, असे प्रामाणिक उत्तर असल्यास, हा provider चा प्रश्न नसून VPS आणि dedicated server मधील तुलना करण्याचा प्रश्न आहे. हाच प्रश्न developer च्या मासिक खर्चाच्या इतर भागांमध्येही दिसतो. Claude आणि ChatGPT plans ची तुलना करताना मुख्य मुद्दा headline price नसून तुम्हाला किती काम दुसऱ्याकडे सोपवायचे आहे हा असतो.

DigitalOcean योग्य पर्याय कधी ठरतो

तुम्ही आभासी मशीनऐवजी प्लॅटफॉर्म खरेदी करत असाल, तेव्हा DigitalOcean अधिक योग्य ठरतो.

  • Managed databases. Managed PostgreSQL आणि MySQL ची सुरुवात 1 GiB RAM आणि 10 GiB storage साठी दरमहा $15.15 पासून होते. अतिरिक्त storage साठी प्रति GiB शुल्क आकारले जाते आणि standby nodes साठी प्रति node किंमत लागू होते. हीच reliability स्वतः उभारण्यासाठी Patroni किंवा repmgr, consensus store, connection proxy आणि प्रत्यक्ष सराव केलेली failover drill आवश्यक असते. दोन जणांची टीम हे सांभाळून features release करू शकत नाही.
  • App Platform. Branch push करा, build, certificate आणि चालू service मिळवा; operating system patch करण्याची गरज नाही. या product ची स्वस्त VPS आवृत्ती म्हणजे शनिवारी हे काम करणारे तुम्ही स्वतः.
  • Mature Terraform provider द्वारे समर्थित object storage आणि load balancers. Code मधून पूर्ण fleet नष्ट करून पुन्हा उभारता येणे, कमी unit price पेक्षा अधिक मौल्यवान असते.
  • Product मागील कंपनी. Published support tiers, इतिहास असलेले status page आणि client च्या security questionnaire ला उत्तर देणारी organisation. तुम्ही hosting resell करत असाल, तर प्रति GB वाचणाऱ्या काही dollars पेक्षा हे अधिक मौल्यवान असते.

प्रत्यक्षात outbound traffic असलेल्या साध्या virtual machine मोठ्या संख्येने घेतल्यास DigitalOcean महाग पडतो. नेमकी हीच परिस्थिती alternative सोडवतो आणि self-hosting करणारा developer यापैकीच बहुतांश गोष्टी खरेदी करतो.

नवीन provider कडे downtime शिवाय स्थलांतर

स्थलांतरादरम्यान downtime येण्याचे एकच कारण असते: data नवीन IP वर हलवल्यानंतरही traffic जुन्या IP वर येत राहतो. खालील प्रत्येक पायरी ही हा कालावधी कमी आणि अंदाज करता येण्यासारखा ठेवण्यासाठी आहे.

स्थलांतराच्या किमान 48 तास आधी DNS पासून सुरुवात करा. Resolvers तुमचा A record त्याच्या TTL (time to live) इतका cache करतात. त्यामुळे 24 तासांच्या TTL असलेला record बदलल्यानंतरही users ना एक दिवसापर्यंत जुन्या server कडे पाठवत राहतो. Cutover वेळी TTL कमी केल्याने फायदा होत नाही, कारण resolvers कडे जुनी expiry जोडलेली जुनी value आधीच असते. आधी TTL कमी करा, जुनी value कालबाह्य होईपर्यंत थांबा आणि नंतर स्थलांतर करा.

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

पहिल्या command मध्ये answer च्या दुसऱ्या column मध्ये सध्याचा TTL दिसतो. तुमच्या DNS provider कडे तो 300 वर सेट करा. त्यानंतर तुम्ही नुकतीच बदललेली value असलेल्या कालावधीपेक्षा जास्त वेळ थांबा.

त्यानंतर पुढील क्रमाने काम करा.

  1. नवीन server तयार करा आणि त्यावर काहीही ठेवण्यापूर्वी तो सुरक्षित करा. घाईत लोक वगळतात तो भाग नवीन VPS वरील पहिली दहा मिनिटे यात समाविष्ट आहे.
  2. Application stack install करा आणि जुना server नेहमीप्रमाणे सेवा देत असताना rsync वापरून data ची पहिली copy करा.
  3. नवीन host वर आत्ताच TLS certificate जारी करा आणि DNS-01 challenge वापरा. HTTP-01 challenge सध्या DNS ज्या IP कडे निर्देश करते त्या IP विरुद्ध पडताळणी करते, आणि तो अजूनही जुना server असतो. DNS-01 challenge वापरल्याने हा क्रमाचा प्रश्न पूर्णपणे दूर होतो.
  4. सार्वजनिक बदल करण्यापूर्वी तुमच्या स्वतःच्या laptop वर DNS override करून नवीन host तपासा. 203.0.113.20 example.com हे /etc/hosts मध्ये जोडा, प्रत्यक्ष site उघडा आणि नंतर ती line काढा. या test मुळे कोणत्याही user वर परिणाम होत नाही.
  5. Database च्या size चा प्रश्न सोडवा. काही GB पेक्षा कमी असल्यास dump आणि restore हे write freeze च्या कालावधीत पूर्ण होतात. त्यापेक्षा जास्त असल्यास काही दिवस आधी जुन्या database मधून नवीन database कडे replication सेट करा आणि ते समक्रमित होऊ द्या. त्यामुळे freeze मध्ये फक्त promotion करावे लागते.
  6. Writes थांबवा. Application ला maintenance किंवा read-only mode मध्ये ठेवा. Users ना दिसणारा हा एकमेव भाग आहे आणि तो काही मिनिटांचाच असावा.
  7. अंतिम delta चालवा: पुन्हा तोच rsync चालवा आणि त्यानंतर अंतिम database sync करा.
  8. A आणि AAAA records नवीन IP वर बदला. 300 seconds TTL असल्यास बहुतेक resolvers साधारण पाच मिनिटांत बदल स्वीकारतात.
  9. जुना server किमान एक दिवस सुरू आणि उपलब्ध ठेवा, कारण काही resolvers कमी TTL कडे दुर्लक्ष करतात. जुनी application अजून writable असल्यास उशिरा येणारे requests चुकीच्या database मध्ये लिहिले जातील. त्यामुळे जुन्या host ला नवीन database कडे निर्देशित करा किंवा त्यावरून maintenance page परत पाठवा.
  10. नवीन server चा error rate एक दिवस monitor करा, TTL पुन्हा नेहमीच्या value वर वाढवा आणि जुन्या server चा नाश त्याच संध्याकाळी न करता एका आठवड्यानंतर करा.

Copy साठी दोन commands आहेत आणि प्रत्येक command दोनदा चालवायचा आहे. File sync:

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

-a ownership, permissions आणि timestamps जतन करते, -H hard links जतन करते, -AX ACLs आणि extended attributes जतन करते आणि --numeric-ids दोन machines मधील वेगवेगळ्या names द्वारे user IDs remap करण्यापासून rsync ला थांबवते. हे command काही दिवस आधी चालवा. त्यानंतर freeze दरम्यान पुन्हा चालवा. तेव्हा फक्त बदललेला data transfer होतो.

Dump करण्याइतका लहान PostgreSQL database असल्यास:

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 tables मधील dump एकाच transaction मध्ये घेते. त्यामुळे result consistent राहतो आणि command चालू असताना application writes करत राहते. हा flag नसल्यास mysqldump tables lock करते. त्यामुळे तुमचा write freeze नियोजित वेळेआधीच सुरू होतो आणि तो कधी सुरू करायचा हे तुमच्या नियंत्रणात राहत नाही.

तुमच्या servers च्या बाहेर दोन गोष्टी अडचण निर्माण करतात. नवीन IP address ची email reputation नसते. त्यामुळे नवीन box वरून थेट पाठवलेला mail spam म्हणून filter केला जाऊ शकतो. आधीपासून reputation असलेल्या relay मार्फत mail पाठवा. तसेच payment gateway किंवा client firewall सारख्या कोणत्याही partner ने तुमचा outbound IP allowlist केला असल्यास cutover पूर्वी तो update करणे आवश्यक आहे. अन्यथा traffic हलताच त्या calls अपयशी ठरू लागतात.

कमिट करण्यापूर्वी काय तपासावे

  • तुम्ही निवडलेल्या ठिकाणी ती योजना आज प्रत्यक्षात घेता येईल का. किंमत सूचीमध्ये 'unavailable' असलेली योजना, तिची प्रति GB किंमत कितीही आकर्षक असली तरी, ती एक पर्याय असू शकत नाही.
  • किंमत प्रमोशनल आहे का आणि नूतनीकरणानंतर (renewal) ती किती असेल. सुरुवातीच्या काळातील सवलत जी नूतनीकरणानंतर दुप्पट होते, ती एक प्रकारची वास्तविक किंमतच आहे, फक्त ती पुढे ढकलली गेली आहे.
  • कालावधी प्रीपेड आहे का. SSD Nodes प्रमाणे बहु-वर्षीय प्रीपेड योजनांमध्ये आगाऊ पैसे भरून प्रति GB RAM ची किंमत खूप कमी मिळते. याचा तोटा असा की तुम्ही पुढच्या महिन्यात सेवा बंद करू शकत नाही, त्यामुळे तुमच्या खात्रीनुसार कालावधी निवडा.
  • स्नॅपशॉटसाठी दरमहा किती खर्च येतो आणि रिस्टोर करण्यासाठी किती पैसे व किती वेळ लागतो.
  • ओव्हरएज (overage) साठी बिल आकारले जाते की वेग मर्यादित (throttle) केला जातो.
  • IPv6 योग्यरित्या राउट केलेले आहे की केवळ एक स्वतंत्र ॲड्रेस जोडलेला आहे.
  • जर तुम्हाला मॅन्युअली ऐवजी कोडद्वारे सर्व्हर पुन्हा तयार करायचे असतील, तर त्यासाठी मेंटेन केलेला Terraform provider असलेला API उपलब्ध आहे का.
  • सपोर्टशी संपर्क कसा साधता येतो आणि सर्व्हर डाऊन असताना मिळणारा प्रतिसाद वेळ काय आहे (विक्रीविषयक प्रश्नांसाठी नव्हे).

तुमच्या बिलावर ज्या घटकाचा सर्वाधिक परिणाम होतो, त्या आधारावर निवड करा. जर तो घटक मेमरी असेल, तर प्रति GB RAM ची किंमत निर्णायक ठरते. जर तो आउटबाउंड ट्रॅफिक असेल, तर समाविष्ट असलेले ट्रान्सफर निर्णायक ठरते. जर तुमचा स्वतःचा वेळ महत्त्वाचा असेल, तर मॅनेज्ड प्लॅटफॉर्म निर्णायक ठरतो आणि येथे तुलना केलेल्या चार पर्यायांपैकी DigitalOcean चा प्लॅटफॉर्म सर्वात सक्षम आहे.

FAQ

Hetzner हे नेहमी DigitalOcean पेक्षा स्वस्त असते का?

साध्या व्हर्च्युअल मशीनसाठी, प्रति GB RAM चा खर्च खूपच कमी होता: 5 ऑगस्ट 2026 रोजी लहान शेअर्ड प्लॅन्सवर तो सुमारे $1.62 होता, तर DigitalOcean वर तो $6.00 होता. Hetzner चा हा आकडा CX23 वरून आला होता, जो 21 ऑक्टोबर 2026 रोजी त्यांच्या Cost-Optimized लाईन आणि नवीन CPX02 सोबत उपलब्ध नसल्याचे सूचीबद्ध केले होते. त्यामुळे, आज तुम्ही जो प्लॅन ऑर्डर करू शकता, त्याच्याशीच तुलना करा. जेव्हा मॅनेज्ड सर्व्हिसेसचा विचार येतो, तेव्हा ही तुलना बदलते. Hetzner फक्त सर्व्हर आणि नेटवर्किंग विकते, त्यामुळे मॅनेज्ड डेटाबेस किंवा push-to-deploy प्लॅटफॉर्म तुम्हाला स्वतःला किंवा तिसऱ्या पक्षाकडून घ्यावे लागतील आणि त्या वेळेलाही एक किंमत असते. Hetzner ने 2026 मध्ये क्लाउडच्या किमती वाढवल्या होत्या, त्यामुळे जुन्या लेखांवर विश्वास ठेवण्याऐवजी सध्याची युरोमधील किंमत तपासा.

जर मला मॅनेज्ड डेटाबेस हवा असेल, तर मी DigitalOcean चा कोणता पर्याय निवडावा?

Vultr आणि Akamai हे दोन्ही मॅनेज्ड डेटाबेस विकतात, त्यामुळे जर मॅनेज्ड डेटाबेस हेच तुमचे DigitalOcean वर असण्याचे मुख्य कारण असेल, तर हे सर्वात जवळचे पर्याय आहेत. कमी किमतीचे युरोपियन होस्ट्स सहसा मॅनेज्ड डेटाबेस विकत नाहीत, याचा अर्थ तुम्हाला PostgreSQL किंवा MySQL स्वतः चालवावे लागेल, ज्यामध्ये रेप्लिकेशन आणि टेस्टेड फेलओव्हरचा समावेश असेल. हे एक मोठे काम आहे. स्वस्त सर्व्हरमुळे काही बचत झाली आहे असे ठरवण्यापूर्वी, मॅनेज्ड 1 GiB इन्स्टन्ससाठी लागणाऱ्या $15.15 प्रति महिन्याच्या खर्चाशी त्याची तुलना करा.

डाउनटाइमशिवाय लाइव्ह साइट नवीन प्रोव्हायडरकडे कशी हलवायची?

स्थलांतराच्या किमान 48 तास आधी DNS TTL 300 सेकंदांपर्यंत कमी करा, कारण मागील TTL ने सांगितल्याप्रमाणे रिझोल्व्हर्स जुना IP सर्व्ह करत राहतात. जुना सर्व्हर ट्रॅफिक सर्व्ह करत असतानाच नवीन होस्ट तयार करा आणि टेस्ट करा. यासाठी तुमच्या स्वतःच्या मशीनवर /etc/hosts ओव्हरराइड वापरा, जेणेकरून इतर कोणालाही ते दिसणार नाही. त्यानंतर काही मिनिटांसाठी राइट्स (writes) थांबवा, अंतिम rsync डेल्टा आणि डेटाबेस सिंक पूर्ण करा, A आणि AAAA रेकॉर्ड्स बदला आणि जुना सर्व्हर एक आठवडा चालू ठेवा, जेणेकरून एखाद्या रिझोल्व्हरने कमी TTL कडे दुर्लक्ष केले तरी अडचण येणार नाही.

स्वस्त VPS म्हणजे डिस्कचा वेग कमी असतो का?

नेहमीच नाही. महत्त्वाची गोष्ट म्हणजे तुमची व्हर्च्युअल डिस्क होस्टवर स्थानिक (local) आहे की नेटवर्क स्टोरेज क्लस्टरवर, आणि हे पॅनेलवर सहसा दिलेले नसते. lsblk -o NAME,ROTA दोन्हीसाठी 0 रिपोर्ट करते, कारण दोन्ही नॉन-रोटेशनल असतात. त्याऐवजी मोजमाप करा: fio कमांड --iodepth=1 --bs=4k --direct=1 सोबत चालवा आणि 99 व्या पर्सेंटाइलची लॅटन्सी तपासा. नेटवर्क व्हॉल्यूममुळे प्रत्येक रीडसाठी डेटासेंटर नेटवर्कचा राऊंड ट्रिप वेळ वाढतो, त्यामुळे डीप-क्यू थ्रूपुट सारखा दिसत असला तरीही त्याची लॅटन्सी स्थानिक NVMe पेक्षा जास्त असते.

नवीन सर्व्हरवरून माझे ईमेल डिलीव्हर होतील का?

सुरुवातीला अनेकदा नाही. नवीन IP ॲड्रेसचा कोणताही सेंडिंग इतिहास नसतो, त्यामुळे प्राप्तकर्ते त्यावरून येणाऱ्या मेलला संशयास्पद मानतात आणि ते स्पॅममध्ये जातात किंवा थेट नाकारले जातात. तुम्ही अपडेट करेपर्यंत SPF आणि DKIM रेकॉर्ड्स देखील जुन्या होस्टकडेच निर्देश करत असतात. ॲप्लिकेशन मेल एखाद्या रिले किंवा ईमेल सर्व्हिसद्वारे पाठवा ज्याची आधीच चांगली प्रतिष्ठा आहे, आणि कटओव्हरनंतर करण्याऐवजी मेलसाठीचे DNS रेकॉर्ड्स आधीच अपडेट करा.

हा लेख उपयुक्त होता का?