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

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

बहुतेक DigitalOcean पर्याय मशीन बदलत नाहीत; ते बिल बदलतात. दोन्ही बाबतीत तुम्हाला सार्वजनिक IP, virtio disk आणि root access असलेली Linux virtual machine मिळते. Control panel वर कोणाचा लोगो आहे याची kernel ला पर्वा नसते. निवड ठरवणारे फरक म्हणजे RAM च्या प्रत्येक GB ची किंमत, समाविष्ट transfer allowance चे प्रमाण आणि त्यापेक्षा जास्त वापरलेल्या प्रत्येक byte ची किंमत, disk प्रत्यक्षात कोणत्या storage वर आधारित आहे, तसेच operating system वरील stack पैकी किती भाग दुसरा provider तुमच्यासाठी चालवतो.

या guide मध्ये याच निकषांवर तुलना केली आहे, कारण developer terminal किंवा प्रकाशित price list मधून यापैकी प्रत्येक बाब तपासू शकतो. DigitalOcean योग्य पर्याय ठरणारी प्रकरणेही येथे दिली आहेत. कोणताही तोटा न मानणारी तुलना ही जाहिरात ठरते.

खालील प्रत्येक किंमत 5 August 2026 रोजी तपासलेली प्रकाशित list price आहे. किंमती बदलतात आणि येथे नमूद केलेल्या एकापेक्षा अधिक provider ने 2026 मध्ये त्यांच्या किंमती बदलल्या आहेत. Pricing structure अधिक हळूहळू बदलते. त्यामुळे प्रथम ratios आणि billing model समजून घ्या. त्यानंतर सेवा घेण्यापूर्वी provider च्या स्वतःच्या 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 plan साठी प्रति GB $6.00 आकारतो. 4 GB plan साठीही तोच $6.00 प्रति GB आकारला जातो. या plan ची मासिक किंमत $24.00 आहे. त्याच provider कडून मोठा plan घेतल्याने discount मिळत नाही. त्यामुळे plan size हा निर्णयाचा मुख्य घटक नाही. Provider हा मुख्य घटक आहे.

पूर्वी Linode म्हणून ओळखली जाणारी सेवा आता विकणारा Akamai, 2 GB आणि 4 GB shared plans साठी अनुक्रमे $12 आणि $24 आकारतो. DigitalOcean च्या किमतींशी या किमती डॉलरच्या अचूक पातळीवर जुळतात. त्यांचा entry plan $5.00 असून तो या दोन्हींपेक्षा स्वस्त आहे. दोन कंपन्यांच्या किमती अगदी सारख्या असणे हा लक्षात घेण्यासारखा संकेत आहे. त्या tier ची किंमत hardware नुसार नव्हे, तर competitor नुसार ठरवली आहे. त्यामुळे ती competitor च्या किमतीशी जुळत राहण्याची शक्यता असते.

स्वतःची datacentres उभारून euro मध्ये विक्री करणाऱ्या providers मुळे हा फरक स्पष्ट दिसतो. Hetzner CX23 plan मध्ये 4 GB RAM मिळते. त्याची मासिक किंमत सुमारे $6.49 आहे. म्हणजे प्रति GB $1.62. ही किंमत DigitalOcean च्या दराच्या जवळपास एक चतुर्थांश आहे. ही dollar किंमत euro list price मधून रूपांतरित केली जाते. त्यामुळे exchange rate नुसार तिच्यात बदल होतो. Hetzner ने 2026 मध्ये cloud prices वाढवल्या आहेत. त्यामुळे जुन्या comparison posts मध्ये आता लागू नसलेल्या किमती दिसतात.

RAM च्या प्रति GB किमतीवरून तुम्हाला मिळणाऱ्या CPU बद्दल काहीही समजत नाही. Shared vCPU मध्ये hypervisor तुमचा core इतर tenants सोबत schedule करतो. याची अचूक तपासणी तुम्ही प्रत्यक्ष भाड्याने घेतलेल्या box वर करावी:

vmstat 1 10

st column वाचा. तुमचा vCPU run होण्यासाठी तयार होता, पण hypervisor ने physical core दुसऱ्या tenant ला दिला, अशा वेळेची टक्केवारी यात दिसते. Load असताना काही टक्के steal time सामान्य आहे. सतत double-digit संख्या दिसत असल्यास host वर oversubscription आहे. तुम्ही वापरू शकत नसलेल्या core ची भरपाई कोणतीही प्रति-GB किंमत करू शकत नाही. ही चाचणी तुमच्या व्यस्त वेळेत चालवा. Steal time ही शेजारी tenants मुळे उद्भवणारी समस्या आहे आणि त्यांच्या वापराच्या वेळा ठरलेल्या असतात. Storage आणि traffic जोडल्यावर hosting ची प्रत्यक्ष मासिक किंमत किती होते, याचे व्यापक चित्र पाहण्यासाठी VPS ची महिन्या-महिन्याची किंमत वाचा.

समाविष्ट transfer ची वास्तविक किंमत

[
  {
    "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 च्या entry plan मध्ये outbound transfer चे 1 TB समाविष्ट आहेत आणि त्यापेक्षा जास्त वापरासाठी GiB नुसार शुल्क आकारले जाते. याचा दर प्रत्येक अतिरिक्त TB साठी सुमारे $10.00 इतका पडतो. Akamai मध्ये तेवढेच TB समाविष्ट आहेत आणि त्यापेक्षा जास्त वापरासाठी साधारण निम्मे शुल्क आकारले जाते, म्हणजे प्रत्येक TB साठी सुमारे $5.00. Vultr मध्ये 2 TB समाविष्ट आहेत आणि अतिरिक्त वापराचा दर त्याच पातळीच्या आसपास आहे. Hetzner मध्ये 20 TB समाविष्ट आहेत. त्यानंतर प्रत्येक TB साठी सुमारे $1.20 आकारले जातात. हा दर इतरांपेक्षा सुमारे एका क्रमाने वेगळा आहे.

शीर्षकातील आकड्यांपेक्षा तीन संरचनात्मक बाबी अधिक महत्त्वाच्या आहेत. चारही providers मध्ये inbound traffic विनामूल्य आहे. त्यामुळे फक्त तुम्ही बाहेर पाठवलेला traffic मोजला जातो. DigitalOcean आणि Vultr मध्ये ही मर्यादा account वरील सर्व servers साठी एकत्रित असते. त्यामुळे एका व्यस्त machine मुळे दुसऱ्या machine चा quota कमी होतो आणि लहान servers च्या संपूर्ण संचासाठी एकच मोठा pool वापरला जातो. Private किंवा VPC network वरील servers मधील traffic सहसा मोजला जात नाही. म्हणून database private interface वर ठेवणे हा security सोबतच billing शी संबंधित निर्णयही आहे.

तुम्ही मर्यादेच्या जवळपासही नसाल, तर यापैकी कोणतीही बाब महत्त्वाची नाही. Blog, JSON responses देणारा API किंवा लहान SaaS एका महिन्यात 1 TB पर्यंत पोहोचणार नाही. Video, image galleries, game servers, package mirrors आणि off-site backup targets मात्र पोहोचू शकतात. गृहीत धरण्यापूर्वी मोजमाप करा:

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

vnstat -m transfer ची महिन्यानुसार माहिती received आणि transmitted अशा दोन भागांत दाखवते. फक्त transmitted column साठी शुल्क आकारले जाते. Database सुरुवातीला रिकामी असते. त्यामुळे ती install केल्यानंतर एका दिवसाने पहिले उपयुक्त reading मिळते आणि पूर्ण पहिल्या महिन्याचे reading एका महिन्याने मिळते. तोपर्यंत provider चा स्वतःचा bandwidth graph हाच तुमच्याकडे असलेला एकमेव record असतो.

कोणत्याही price list मध्ये नसलेल्या आणखी एका प्रश्नाचे उत्तर मिळवा: allowance ओलांडल्यावर provider तुमच्याकडून शुल्क आकारतो की port चा वेग कमी करतो? Billing मुळे पैसे खर्च होतात. Throttling मुळे users वर परिणाम होतो, आणि तो नेमका त्या वेळी होतो जेव्हा users ची संख्या सर्वाधिक असते. Traffic spike मुळे यापैकी नेमका कोणता परिणाम होईल हे आधी जाणून घ्या.

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 अपयशी ठरू लागतात.

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

• किंमत promotional आहे का आणि renewal वेळी ती किती होते. पहिल्या term वरील discount renewal वेळी दुप्पट होत असेल, तर तो प्रत्यक्ष खर्चच आहे; तो फक्त पुढे ढकलला जातो.
• term prepaid आहे का. SSD Nodes ज्या पद्धतीने विकते त्या multi-year prepaid plans मुळे आगाऊ पैसे भरून RAM च्या प्रत्येक GB मागील किंमत बरीच कमी होते. याचा trade-off असा आहे की पुढील महिन्यात सेवा सोडता येत नाही. त्यामुळे तुम्ही किती निश्चित आहात त्यानुसार term निवडा.
• snapshot साठी दरमहा किती खर्च येतो आणि restore साठी पैसे व वेळ, दोन्ही किती लागतात.
• overage साठी billing केले जाते की traffic throttled केला जातो.
• IPv6 योग्य प्रकारे routed आहे का, की तो फक्त जोडलेला single address आहे.
• तुम्ही manually करण्याऐवजी code मधून rebuild करणार असाल, तर maintained Terraform provider असलेले API उपलब्ध आहे का.
• support शी संपर्क कसा साधायचा आणि server down असल्यास प्रकाशित response target काय आहे. हा target sales question साठीचा नसावा.

तुमच्या bill वर सर्वाधिक परिणाम करणाऱ्या axis नुसार निवड करा. तो axis memory असेल, तर RAM च्या प्रत्येक GB मागील किंमत निर्णायक ठरते. तो outbound traffic असेल, तर included transfer निर्णायक ठरतो. तो तुमचा स्वतःचा वेळ असेल, तर managed platform निर्णायक ठरते. येथे तुलना केलेल्या चार पर्यायांमध्ये DigitalOcean याबाबतीत सर्वात मजबूत आहे.

FAQ

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

साध्या virtual machine साठी, RAM च्या प्रत्येक GB मागे Hetzner ची किंमत खूपच कमी असते: 5 August 2026 रोजी entry shared plans मध्ये Hetzner ची किंमत सुमारे $1.62 होती, तर DigitalOcean ची $6.00 होती. Managed services विचारात घेतल्यावर हे गणित बदलते. Hetzner servers आणि networking विकते. त्यामुळे managed database किंवा push-to-deploy platform तुम्हाला स्वतः चालवावे लागते किंवा third party कडून घ्यावे लागते. त्या कामासाठी लागणाऱ्या वेळेचीही किंमत असते. Hetzner ने 2026 मध्ये cloud prices वाढवल्या आहेत. त्यामुळे जुन्या article वर अवलंबून न राहता सध्याची euro किंमत तपासा.

Managed database आवश्यक असल्यास कोणता DigitalOcean पर्याय निवडावा?

Vultr आणि Akamai दोन्ही managed databases विकतात. त्यामुळे managed database मुळेच तुम्ही DigitalOcean वापरत असाल, तर हे दोन्ही सर्वात जवळचे पर्याय आहेत. कमी-किमतीचे European hosts सामान्यतः managed database देत नाहीत. त्यामुळे PostgreSQL किंवा MySQL तुम्हालाच चालवावे लागेल. त्यात replication आणि तपासलेले failover यांचाही समावेश होतो. हे प्रत्यक्षात एक स्वतंत्र काम आहे. स्वस्त server मुळे खरोखर बचत झाली का हे ठरवण्यापूर्वी, managed 1 GiB instance साठी लागणाऱ्या दरमहा $15.15 शी त्याची तुलना करा.

Downtime न आणता live site नवीन provider कडे कशी हलवावी?

Move करण्याच्या किमान 48 तास आधी DNS TTL 300 seconds पर्यंत कमी करा. कारण मागील TTL मध्ये सांगितलेल्या कालावधीपर्यंत resolvers जुन्या IP वरूनच response देत राहतात. जुना host अजूनही traffic देत असताना नवीन host तयार करून तपासा. यासाठी स्वतःच्या machine वर /etc/hosts override वापरा, म्हणजे इतर कोणालाही तो बदल दिसणार नाही. त्यानंतर काही मिनिटांसाठी writes थांबवा. अंतिम rsync delta आणि अंतिम database sync चालवा. A आणि AAAA records बदला. जुन्या server ला एक आठवडा चालू ठेवा, कारण एखाद्या resolver ने कमी केलेला TTL दुर्लक्षित केलेला असू शकतो.

स्वस्त VPS म्हणजे disks धीमे असतात का?

केवळ स्वस्त असल्यामुळे तसे होत नाही. तुमचा virtual disk host वर local आहे की network storage cluster वर आहे, हे महत्त्वाचे असते. Panel मध्ये ही माहिती क्वचितच दिली जाते. lsblk -o NAME,ROTA दोन्हींसाठी 0 दाखवते, कारण दोन्ही non-rotational आहेत. त्याऐवजी मोजमाप करा: --iodepth=1 --bs=4k --direct=1 सह fio चालवा आणि 99th percentile completion latency वाचा. प्रत्येक read साठी network volume ला datacentre network round trip लागतो. त्यामुळे deep-queue throughput सारखा दिसत असला तरी त्याची latency floor local NVMe पेक्षा जास्त असते.

नवीन server वरून माझे email अद्याप deliver होतील का?

सुरुवातीला अनेकदा होत नाही. नवीन IP address ची sending history नसते. त्यामुळे receivers त्यावरून आलेल्या mail कडे संशयाने पाहतात. तो spam मध्ये जाऊ शकतो किंवा थेट reject होऊ शकतो. तुम्ही ते update करेपर्यंत SPF आणि DKIM records देखील जुन्या host कडे निर्देश करत असतात. आधीपासून reputation असलेल्या relay किंवा email service मार्फत application mail पाठवा. Cutover नंतर नव्हे, तर त्यापूर्वी mail साठीचे DNS records update करा.