Developers کے لیے DigitalOcean کے بہترین متبادل

DigitalOcean کے متبادل دراصل کیا تبدیل کرتے ہیں

زیادہ تر DigitalOcean متبادل machine کو نہیں بلکہ bill کو تبدیل کرتے ہیں۔ دونوں صورتوں میں آپ کو public IP، virtio disk اور root access کے ساتھ Linux virtual machine ملتی ہے، اور kernel کو اس بات سے کوئی فرق نہیں پڑتا کہ control panel پر کس کمپنی کا logo ہے۔ انتخاب کا فیصلہ کرنے والے اصل فرق RAM کے فی GB کی قیمت، شامل transfer allowance کا حجم اور اس حد سے زائد ہر byte کی قیمت، disk کی اصل ساخت، اور یہ بات ہیں کہ operating system کے اوپر موجود stack میں سے کتنا حصہ کوئی دوسرا فریق آپ کے لیے چلاتا ہے۔

یہ guide انہی پیمانوں پر موازنہ کرتی ہے، کیونکہ developer ان میں سے ہر چیز terminal یا شائع شدہ price list سے جانچ سکتا ہے۔ اس میں وہ حالات بھی بیان کیے گئے ہیں جن میں DigitalOcean درست انتخاب ہے، کیونکہ ایسا موازنہ جو کسی نتیجے کو تسلیم نہ کرے، advertisement بن جاتا ہے۔

ذیل کی ہر قیمت شائع شدہ list price ہے، جسے 5 August 2026 کو چیک کیا گیا تھا۔ DigitalOcean کے اعداد و شمار 21 October 2026 کو دوبارہ چیک کیے گئے اور ان میں کوئی تبدیلی نہیں ہوئی تھی۔ قیمتیں تبدیل ہوتی رہتی ہیں، اور یہاں شامل ایک سے زیادہ providers نے 2026 کے دوران اپنی قیمتیں تبدیل کیں۔ Pricing structure بہت زیادہ آہستہ تبدیل ہوتی ہے، اس لیے پہلے ratios اور billing model پڑھیں، پھر commitment سے پہلے 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 (unavailable Oct 2026)",
    "ram_gb": 4,
    "monthly_usd": "6.49",
    "usd_per_gb_ram": "1.62"
  }
]

ایک ہی provider کے اندر RAM کے فی GB کی قیمت میں بہت کم فرق ہوتا ہے۔ DigitalOcean، 1 GB plan پر فی GB RAM $6.00 لیتا ہے، اور 4 GB plan پر بھی فی GB یہی $6.00 لیتا ہے، جس کی ماہانہ قیمت $24.00 ہے۔ اسی provider کے بڑے plan کا انتخاب کرنے سے کوئی رعایت نہیں ملتی، اس لیے فیصلہ plan کے سائز پر نہیں ہوتا۔ فیصلہ provider پر ہوتا ہے۔

Akamai، جو اب سابقہ Linode plans فروخت کرتا ہے، اپنے 2 GB اور 4 GB shared plans کی قیمت بالترتیب $12 اور $24 رکھتا ہے، یعنی DigitalOcean کے برابر۔ اس کا ابتدائی plan انہیں $5.00 پر پیچھے چھوڑتا ہے۔ دو کمپنیوں کا ایک دوسرے سے عین مطابقت رکھنا ایک اہم اشارہ ہے: اس tier کی قیمت hardware کے بجائے competitor کو سامنے رکھ کر مقرر کی گئی ہے، اور یہ competitor کی قیمت کے ساتھ چلتی رہے گی۔

یہ فرق ان providers کے ساتھ نمایاں ہوتا ہے جو اپنے datacentres چلاتے ہیں اور قیمتیں euro میں مقرر کرتے ہیں۔ 5 August 2026 کو Hetzner CX23 تقریباً $6.49 ماہانہ میں 4 GB RAM دیتا تھا، یعنی فی GB $1.62؛ یہ DigitalOcean کی شرح کے تقریباً ایک چوتھائی کے برابر ہے۔ 21 October 2026 کو آپ اسے اب بھی order نہیں کر سکتے۔ Hetzner نے CX23 اور اپنی Cost-Optimized line کے ہر دوسرے plan کو فی الحال unavailable درج کیا ہے، اور وضاحت کی ہے کہ یہ line پرانے hardware پر چلتی ہے، اس لیے servers کی تعداد محدود ہے۔ اس کے status page پر cloud instances کی محدود دستیابی سے متعلق notice 26 June 2026 سے موجود ہے، اور 21 October 2026 کو بھی یہ notice موجود تھا۔ جس plan کو آپ order نہیں کر سکتے، اس کی فی GB قیمت موازنے کے قابل نہیں ہوتی۔

6 October 2026 کو Hetzner نے CPX02 شامل کیا، جو 1 vCPU، 1 GB RAM اور 20 GB NVMe والا Regular Performance plan ہے، اور اس کا سب سے چھوٹا shared server ہے۔ 21 October 2026 کو Hetzner کے اپنے page پر EU locations کے لیے اس کی قیمت VAT کے بغیر €6.49 ماہانہ درج تھی۔ یعنی کسی بھی dollar conversion سے پہلے RAM کے فی GB €6.49، جبکہ DigitalOcean کی قیمت $6.00 ہے۔ اسی page پر CPX02 اور ہر دوسرے Regular Performance plan کو بھی فی الحال unavailable نشان زد کیا گیا تھا۔ اس لیے موازنے سے پہلے تصدیق کریں کہ آپ کی مطلوبہ location میں اسے order کیا جا سکتا ہے۔ Hetzner کی ہر dollar figure euro list price سے convert کی گئی ہے، اس لیے exchange rate کے ساتھ بدلتی رہتی ہے۔ Hetzner نے 2026 کے دوران cloud prices بھی بڑھائی ہیں، اس لیے پرانی comparison posts میں ایسی قیمتیں درج ہو سکتی ہیں جو اب موجود نہیں۔

RAM کے فی GB کی قیمت آپ کو CPU کے بارے میں کچھ نہیں بتاتی۔ Shared vCPU کا مطلب ہے کہ hypervisor آپ کے core کو دوسرے tenants کے ساتھ schedule کرتا ہے۔ درست جانچ ایسے box پر کی جاتی ہے جسے آپ نے واقعی rent کیا ہو:

vmstat 1 10

st column پڑھیں۔ یہ اس وقت کا فیصد بتاتا ہے جب آپ کا vCPU run ہونے کے لیے ready تھا لیکن hypervisor نے physical core کسی دوسرے tenant کو دے دیا۔ Load کے دوران چند فیصد معمول کی بات ہے۔ مسلسل دو ہندسوں کی value کا مطلب ہے کہ host پر ضرورت سے زیادہ tenants موجود ہیں۔ جس core کو آپ استعمال ہی نہیں کر سکتے، اس کی تلافی RAM کے فی GB کوئی قیمت نہیں کر سکتی۔ اسے اپنے مصروف ترین وقت میں چلائیں، کیونکہ steal time پڑوسی tenant کا مسئلہ ہے اور 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 (unavailable Oct 2026)",
    "included_tb": 20,
    "overage_usd_per_tb": "1.20"
  }
]

DigitalOcean اپنے $6.00 والے 1 GiB plan میں تقریباً 1 TB (1,000 GiB) outbound transfer شامل کرتا ہے اور اضافی استعمال کے لیے $0.01 فی GiB وصول کرتا ہے، جو ہر اضافی TB کے لیے تقریباً $10.00 بنتا ہے۔ اس کا حقیقی entry plan، یعنی $4.00 ماہانہ میں 512 MiB RAM، صرف 500 GiB شامل کرتا ہے۔ اس کے بعد allowance plan کے سائز کے ساتھ بڑھتا ہے اور بڑے Basic plans میں 6,000 GiB تک پہنچتا ہے، اس لیے اسی plan کا figure دیکھیں جسے آپ واقعی منتخب کرتے ہیں۔ Akamai اپنے Nanode پر اتنا ہی TB شامل کرتا ہے اور تقریباً نصف قیمت، یعنی فی TB تقریباً $5.00، وصول کرتا ہے۔ Vultr 2 TB شامل کرتا ہے اور اضافی استعمال کی شرح تقریباً اتنی ہی ہے۔ 5 August 2026 کو Hetzner کے CX23 میں 20 TB شامل تھا اور اس کے بعد تقریباً $1.20 فی TB وصول کیا جاتا تھا، جو دیگر providers کے مقابلے میں تقریباً ایک order of magnitude کا فرق ہے۔ 21 October 2026 کو Hetzner کے صفحے پر اس کے EU locations کے لیے اب بھی 20 TB شامل traffic درج تھا، اور CPX02 پر بھی یہی allowance تھا، اگرچہ Singapore اور US locations میں یہ بہت کم تھا؛ Singapore میں CPX02 کو 0.5 TB ملتا ہے۔

تین بنیادی تفصیلات headline numbers سے زیادہ اہم ہیں۔ چاروں providers پر inbound traffic مفت ہے، اس لیے صرف بھیجا جانے والا data شمار ہوتا ہے۔ DigitalOcean، Akamai اور Vultr account کے تمام servers کے درمیان allowance مشترک رکھتے ہیں، اس لیے ایک مصروف machine دوسری machine کا quota استعمال کر سکتی ہے، اور چھوٹے servers کی پوری fleet ایک بڑے مشترک pool کو استعمال کرتی ہے۔ Private یا VPC network پر servers کے درمیان traffic عموماً بالکل شمار نہیں ہوتا۔ اسی لیے database کو private interface پر رکھنا security کے ساتھ ساتھ billing کا فیصلہ بھی ہے۔

اگر آپ cap کے قریب بھی نہیں پہنچ رہے تو ان میں سے کسی بات کی اہمیت نہیں۔ ایک 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 billed ہوتا ہے۔ Database ابتدا میں خالی ہوتا ہے، اس لیے پہلی مفید reading اسے install کرنے کے ایک دن بعد ملتی ہے، اور پہلا مکمل مہینہ ایک ماہ بعد دستیاب ہوتا ہے۔ اس سے پہلے provider کا اپنا bandwidth graph ہی آپ کے پاس موجود واحد record ہوتا ہے۔

ایک اور سوال پوچھیں جس کا جواب کوئی price list نہیں دیتی: allowance ختم ہونے پر provider آپ سے bill وصول کرے گا یا port کو throttle کرے گا؟ Billing پر پیسہ خرچ ہوتا ہے۔ Throttling سے users متاثر ہوتے ہیں، عین اس وقت جب ان کی تعداد سب سے زیادہ ہوتی ہے۔ آپ کو معلوم ہونا چاہیے کہ traffic spike کی صورت میں آپ کے users کے لیے ان دونوں میں سے کون سا نتیجہ پیدا ہوگا۔

NVMe یا SATA، اور یہ کیسے معلوم کریں کہ آپ کو حقیقت میں کیا ملا

پینل میں NVMe لکھا ہے۔ یہ host میں موجود disks کے بارے میں ایک دعویٰ ہے، اور ضروری نہیں کہ آپ کی virtual machine انہی disks پر چل رہی ہو۔ Local storage میں آپ کی virtual disk اسی physical machine کے اندر موجود drives پر ہوتی ہے۔ Network storage میں یہ datacentre network کے ذریعے ایک الگ storage cluster تک پہنچتی ہے۔ اسی وجہ سے فوری resize، live migration اور snapshot-in-place ممکن ہوتے ہیں۔

Guest کے اندر دونوں ایک جیسے نظر آتے ہیں:

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

ROTA اور rotational ہر اس چیز کے لیے 0 رپورٹ کرتے ہیں جسے host non-rotational قرار دیتا ہے۔ اس لیے NVMe سے backed network volume وہی رپورٹ دیتا ہے جو local NVMe دیتا ہے۔ یہ value بتاتی ہے کہ disk spinning platter نہیں ہے۔ یہ نہیں بتا سکتی کہ disk کہاں موجود ہے۔ Linux پر NVMe disk کی تصدیق میں device names اور ان کے مضمرات کی وضاحت کی گئی ہے۔

ان دونوں میں فرق کرنے کے لیے queue depth 1 پر latency کی پیمائش کریں، کیونکہ ایک چھوٹی single read کے پیچھے چھپنے کے لیے کچھ نہیں ہوتا۔ Local NVMe اسی chassis سے جواب دیتا ہے۔ Network volume ہر read کے لیے datacentre network پر round trip شامل کرتا ہے، اس لیے اس کی latency floor زیادہ ہوتی ہے، خواہ deep queue depth پر اس کا throughput یکساں دکھائی دے۔

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 کو چھپا دیتا ہے جو users محسوس کرتے ہیں۔ دوسری run اپنی summary line پر IOPS= دکھاتی ہے۔ دونوں tests اپنے موجودہ provider اور اس provider کی trial instance پر چلائیں جس پر آپ غور کر رہے ہیں۔ دونوں tests ایک ہی دن چلائیں اور اپنے حاصل کردہ دو numbers کا موازنہ کریں۔ کسی بھی vendor کا شائع کردہ figure ایسی machine پر ناپا گیا تھا جسے آپ دیکھ نہیں سکتے۔ مختلف اوقات میں بھی اسے تین بار چلائیں، کیونکہ quiet host اور busy host ایک ہی plan پر مختلف نتائج دیتے ہیں۔ VPS کی درست benchmarking میں طریقہ بیان کیا گیا ہے، جبکہ SSD VPS کا حقیقی مطلب اس کے پیچھے موجود marketing اصطلاحات کی وضاحت کرتا ہے۔

علاقے: latency کی پیمائش کریں، نقشہ نہ پڑھیں

علاقوں کی فہرست اس وقت تک صرف تشہیر ہے جب تک آپ خود پیمائش نہ کریں۔ صارف کو محسوس ہونے والی کارکردگی اس کے 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 کے ساتھ دکھاتا ہے۔ اس طرح دو hops کے درمیان 60 ms کا اضافہ اس link کی نشاندہی کرتا ہے جو مسئلہ پیدا کر رہا ہے، بجائے اس کے کہ destination کو ذمہ دار ٹھہرایا جائے۔ اسے اس network سے منسلک machine پر چلائیں جسے آپ کے users استعمال کرتے ہیں۔ Datacentre سے datacentre تک کے routes internet پر بہترین routes ہوتے ہیں، اس لیے وہ ہر provider کو یکساں طور پر بہتر دکھاتے ہیں۔

قیمت میں کسی بھی تبدیلی کے باوجود ایک بنیادی نکتہ برقرار رہتا ہے۔ اگر provider کے پاس آپ کے continent میں صرف ایک region ہے تو آپ کا disaster recovery plan دراصل continent تبدیل کرنے کا plan ہے، اور اس کے ساتھ متعلقہ latency بھی آتی ہے۔ ان regions کو شمار کریں جن پر آپ حقیقتاً fail over کریں گے، نہ کہ webpage پر درج regions کو۔

Snapshots اور backups کا بل الگ ہوتا ہے

Storage add-ons وہ جگہ ہیں جہاں سستا plan مہنگا ہو جاتا ہے۔ DigitalOcean snapshots کے لیے $0.06 فی GiB ماہانہ چارج کرتا ہے، جبکہ automatic backups کی قیمت server کی قیمت کے تناسب سے مقرر کرتا ہے: weekly backups کے لیے plan price کا 20%، daily backups کے لیے 30%، اور usage-based option میں فی GiB کے حساب سے billing ہوتی ہے۔ دونوں models قابلِ دفاع ہیں، لیکن دونوں مخالف سمتوں میں ناکام ہوتے ہیں۔ Percentage price server کے size کے ساتھ بڑھتی ہے، اس لیے چھوٹا dataset رکھنے والا بڑا server زیادہ ادائیگی کرتا ہے۔ Per GiB price آپ کے data کے ساتھ بڑھتی ہے، اس لیے بڑے volume سے منسلک چھوٹا server زیادہ ادائیگی کرتا ہے۔

پوچھیں کہ restore کی لاگت کیا ہے اور اس میں کتنا وقت لگتا ہے، کیونکہ backup محفوظ رکھنے کی قیمت سوال کا صرف کم اہم حصہ ہے۔ یہ بھی پوچھیں کہ کیا server destroy کرنے سے اس کے snapshots بھی destroy ہو جاتے ہیں۔

اس کے بعد ایک copy ایسے provider کے باہر رکھیں جس پر provider کا کنٹرول نہ ہو۔ Provider کے snapshots اسی provider کے account کے اندر رہتے ہیں، اس لیے login کھو جانے، payment failure یا account suspend ہونے سے server اور اس کے backups ایک ہی وقت میں دستیاب نہیں رہتے۔ اپنی ملکیت والی storage میں restic backups کے لیے object storage پر چند dollars خرچ ہوتے ہیں، انہیں کسی بھی provider پر restore کیا جا سکتا ہے، اور یہی migration کو حتمی اقدام کے بجائے reversible بناتا ہے۔

آپ 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، اور وہ alert جو کسی کو 03:00 بجے جگا دیتا ہے۔ اگر یہ کام آپ کی ذمہ داری ہے تو اسے خود چلائیں اور فرق کی رقم بچائیں۔ اگر آپ کی ذمہ داری application ہے تو یہ کام دوبارہ خرید لینا سستا ہے۔ managed اور unmanaged کا فرق طے کرتا ہے کہ price list کا کون سا column آپ کو دیکھنا چاہیے۔ اگر دیانت دارانہ جواب یہ ہے کہ آپ پوری machine اور اس کی disks صرف اپنے لیے چاہتے ہیں، تو یہ VPS بمقابلہ dedicated server کا سوال ہے، نہ کہ provider کا۔ یہی سوال developer کے ماہانہ bill کے باقی حصوں میں بھی سامنے آتا ہے، جہاں Claude اور ChatGPT plans کا موازنہ اس بات پر منحصر ہوتا ہے کہ آپ کتنا کام دوسروں کے سپرد کرنا چاہتے ہیں، نہ کہ صرف نمایاں کی گئی قیمت پر۔

جہاں DigitalOcean درست انتخاب ہے

DigitalOcean اس وقت بہتر ثابت ہوتا ہے جب آپ صرف virtual machine کے بجائے مکمل platform خرید رہے ہوں۔

• Managed databases۔ Managed PostgreSQL اور MySQL کی قیمت 1 GiB RAM اور 10 GiB storage کے لیے ماہانہ $15.15 سے شروع ہوتی ہے۔ اضافی storage کی billing فی GiB ہوتی ہے، جبکہ standby nodes کی قیمت فی node مقرر ہوتی ہے۔ یہی reliability خود بنانا ہو تو Patroni یا repmgr، ایک consensus store، ایک connection proxy، اور باقاعدہ rehearsed failover drill درکار ہوتی ہے۔ دو افراد کی ٹیم اسے برقرار رکھتے ہوئے features بھی جاری نہیں کر سکتی۔
• App Platform۔ ایک branch push کریں، build، certificate اور running service حاصل کریں، اور operating system patch کرنے کی ضرورت نہ رہے۔ اس product کا سستا VPS متبادل آپ خود ہیں، ہفتہ کے دن۔
• Object storage اور load balancers جنہیں ایک mature Terraform provider support کرتا ہو۔ ایسی fleet جسے code سے destroy اور rebuild کیا جا سکے، کم unit price سے زیادہ قیمتی ہوتی ہے۔
• Product کے پیچھے موجود کمپنی۔ شائع شدہ support tiers، سابقہ record کے ساتھ status page، اور ایسی organisation جو client کے security questionnaire کا جواب دے۔ اگر آپ hosting resell کرتے ہیں تو یہ چند dollars فی GB سے زیادہ اہم ہے۔

DigitalOcean اس وقت مہنگا پڑتا ہے جب سادہ virtual machine بڑی تعداد میں درکار ہو اور حقیقی outbound traffic بھی ہو۔ یہی وہ صورت ہے جسے ایک متبادل حل کرتا ہے، اور self-hosting developer کی زیادہ تر خریداری اسی نوعیت کی ہوتی ہے۔

نئے provider پر بغیر downtime کے منتقل ہونا

Migration کے دوران downtime صرف ایک وجہ سے ہوتا ہے: data نئے IP پر منتقل ہونے کے بعد بھی traffic پرانے IP پر پہنچتا رہتا ہے۔ ذیل کے ہر مرحلے کا مقصد اس وقفے کو مختصر اور قابلِ پیش گوئی بنانا ہے۔

Move سے کم از کم 48 گھنٹے پہلے DNS سے آغاز کریں۔ Resolvers آپ کے A record کو اس کے TTL (time to live) کی مدت تک cache کرتے ہیں۔ اس لیے 24 گھنٹے کے TTL والا record تبدیل کرنے کے بعد بھی صارفین کو ایک دن تک پرانے server پر بھیجتا رہ سکتا ہے۔ Cutover کے وقت TTL کم کرنے سے مدد نہیں ملتی، کیونکہ resolvers پہلے ہی پرانی expiry کے ساتھ پرانی value محفوظ کیے ہوتے ہیں۔ پہلے TTL کم کریں، پرانی value کی مدت ختم ہونے کا انتظار کریں، پھر migrate کریں۔

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

پہلی command جواب کے دوسرے column میں موجودہ TTL دکھاتی ہے۔ اپنے DNS provider پر اسے 300 پر set کریں، پھر اس number سے زیادہ وقت انتظار کریں جسے آپ نے ابھی replace کیا ہے۔

اس کے بعد درج ذیل ترتیب سے کام کریں۔

1. نئے server کو provision کریں اور اس پر کوئی چیز رکھنے سے پہلے اسے harden کریں۔ نئے VPS کے پہلے دس منٹ میں وہ حصہ شامل ہے جسے لوگ جلدی میں چھوڑ دیتے ہیں۔
2. application stack install کریں اور rsync کے ذریعے data کی پہلی copy بنائیں، جبکہ پرانا server معمول کے مطابق service فراہم کرتا رہے۔
3. نئے host پر ابھی TLS certificate جاری کریں۔ اس کے لیے DNS-01 challenge استعمال کریں، کیونکہ HTTP-01 challenge اس IP کے خلاف validation کرتا ہے جس کی طرف DNS فی الحال اشارہ کر رہا ہے، اور وہ اب بھی پرانا server ہے۔ DNS-01 challenge اس ترتیب کے مسئلے کو مکمل طور پر ختم کر دیتا ہے۔
4. کسی public تبدیلی سے پہلے نئے host کی testing کریں۔ اپنے laptop پر DNS کو override کریں۔ 203.0.113.20 example.com کو /etc/hosts میں شامل کریں، حقیقی site browse کریں، پھر یہ line delete کر دیں۔ اس test سے کسی user پر اثر نہیں پڑتا۔
5. Database کے size کا فیصلہ کریں۔ چند GB تک dump اور restore، write freeze کے اندر مکمل ہو جاتا ہے۔ اس سے زیادہ size کے لیے کئی دن پہلے پرانے database سے نئے database تک replication set up کریں اور اسے catch up کرنے دیں، تاکہ freeze صرف promotion تک محدود رہے۔
6. Writes freeze کریں۔ Application کو maintenance یا read-only mode میں رکھیں۔ صارفین صرف اسی حصے کو دیکھ سکتے ہیں، اور اسے چند منٹ تک محدود رہنا چاہیے۔
7. Final delta چلائیں: وہی rsync دوبارہ چلائیں، پھر آخری database sync کریں۔
8. A اور AAAA records کو نئے IP پر تبدیل کریں۔ 300 second کے TTL کے ساتھ زیادہ تر resolvers تقریباً پانچ منٹ میں follow کر لیتے ہیں۔
9. پرانے server کو کم از کم ایک دن تک running اور reachable رکھیں، کیونکہ کچھ resolvers مختصر TTLs نظرانداز کرتے ہیں۔ اگر پرانی application اب بھی writable ہے تو دیر سے آنے والے requests غلط database میں لکھیں گے۔ اس لیے پرانے host کو نئے database کی طرف point کریں یا وہاں maintenance page واپس کریں۔
10. ایک دن تک نئے server کی error rate monitor کریں، TTL کو معمول کی value پر واپس بڑھائیں، اور پرانے server کو اسی شام کے بجائے ایک ہفتے بعد destroy کریں۔

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 rsync کو مختلف machines کے درمیان مختلف user IDs کو names کے ذریعے remap کرنے سے روکتا ہے۔ اسے چند دن پہلے چلائیں، پھر freeze کے دوران دوبارہ چلائیں۔ دوسری بار یہ صرف تبدیل شدہ data منتقل کرے گا۔

PostgreSQL کے لیے، اگر database dump کے لیے کافی چھوٹا ہو:

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 ہو سکتی ہے۔ ایسی relay کے ذریعے mail بھیجیں جس کی reputation پہلے سے موجود ہو۔ اسی طرح ہر وہ partner جو آپ کے outbound IP کو allowlist کرتا ہے، جیسے payment gateway یا client firewall، cutover سے پہلے update کیا جانا چاہیے۔ بصورتِ دیگر traffic منتقل ہوتے ہی وہ calls ناکام ہونا شروع ہو جائیں گی۔

کمٹ کرنے سے پہلے کیا جانچیں

• کیا منصوبہ آج واقعی اس مقام پر آرڈر کیا جا سکتا ہے جہاں آپ اسے چاہتے ہیں۔ قیمت کی فہرست میں unavailable درج منصوبہ کوئی اختیار نہیں، خواہ اس کی فی GB قیمت کتنی ہی اچھی کیوں نہ دکھائی دے۔
• کیا قیمت promotional ہے، اور renewal پر کتنی ہو جائے گی۔ پہلے term کی discount جو renewal پر دوگنی ہو جائے، حقیقی لاگت ہے؛ صرف مؤخر کی گئی ہے۔
• کیا term prepaid ہے۔ SSD Nodes اسی طرح فروخت کرتا ہے۔ کئی سال کے prepaid plans، رقم پہلے ادا کرنے کے عوض، RAM کی فی GB قیمت بہت کم کر دیتے ہیں۔ اس کا نقصان یہ ہے کہ آپ اگلے ماہ سروس چھوڑ نہیں سکتے، اس لیے term کو اپنے اطمینان کی سطح کے مطابق منتخب کریں۔
• snapshot کی ماہانہ قیمت، اور restore کی مالی لاگت اور درکار منٹ معلوم کریں۔
• کیا اضافی استعمال پر overage bill کیا جاتا ہے یا رفتار محدود کی جاتی ہے۔
• کیا IPv6 درست طور پر route کیا جاتا ہے، یا صرف ایک address شامل کیا گیا ہے۔
• اگر آپ سرور کو ہاتھ سے بنانے کے بجائے code سے دوبارہ بنانا چاہتے ہیں تو دیکھیں کہ maintained Terraform provider کے ساتھ API موجود ہے یا نہیں۔
• support سے رابطہ کیسے کیا جاتا ہے، اور down server کے لیے شائع شدہ response target کیا ہے، نہ کہ صرف sales question کے لیے۔

انتخاب اس معیار پر کریں جو آپ کے اپنے bill پر سب سے زیادہ اثر ڈالتا ہے۔ اگر وہ معیار memory ہے تو RAM کی فی GB قیمت فیصلہ کر دے گی۔ اگر outbound traffic ہے تو شامل transfer فیصلہ کرے گا۔ اگر آپ کا اپنا وقت ہے تو managed platform فیصلہ کرے گا، اور یہاں موازنہ کیے گئے چار options میں DigitalOcean کا platform سب سے مضبوط ہے۔

FAQ

کیا Hetzner ہمیشہ DigitalOcean سے سستا ہوتا ہے؟

عام virtual machine کے لیے یہ RAM کے فی GB کے حساب سے خاصا سستا تھا: 5 August 2026 کو چھوٹے shared plans پر تقریباً $1.62 کے مقابلے میں $6.00۔ Hetzner کا یہ عدد CX23 سے لیا گیا تھا، جسے Hetzner نے 21 October 2026 کو اپنی Cost-Optimized line اور نئے CPX02 سمیت unavailable درج کیا تھا، اس لیے موازنہ ایسے plan سے کریں جسے آپ آج واقعی order کر سکتے ہوں۔ Managed services شامل ہونے کے بعد موازنہ بھی بدل جاتا ہے۔ Hetzner servers اور networking فروخت کرتا ہے، اس لیے managed database یا push-to-deploy platform آپ کو خود فراہم کرنا ہوگا یا کسی third party سے لینا ہوگا، اور ان خدمات کی الگ لاگت ہوتی ہے۔ Hetzner نے 2026 کے دوران cloud prices بھی بڑھائی تھیں، اس لیے کسی پرانے مضمون پر بھروسا کرنے کے بجائے موجودہ euro قیمت دیکھیں۔

اگر مجھے managed database درکار ہو تو میں DigitalOcean کا کون سا متبادل منتخب کروں؟

Vultr اور Akamai دونوں managed databases فراہم کرتے ہیں، اس لیے اگر managed database ہی DigitalOcean استعمال کرنے کی بنیادی وجہ ہے تو یہ سب سے قریب متبادل ہیں۔ کم لاگت والے European hosts عموماً managed database فراہم نہیں کرتے۔ اس کا مطلب ہے کہ PostgreSQL یا MySQL آپ کو خود چلانا ہوگا، جس میں replication اور آزمودہ failover بھی شامل ہیں۔ یہ باقاعدہ انتظامی کام ہے۔ یہ فیصلہ کرنے سے پہلے اس کی لاگت کا موازنہ $15.15 ماہانہ سے کریں، جو managed 1 GiB instance کی قیمت ہے، تاکہ معلوم ہو سکے کہ سستے server سے واقعی کوئی بچت ہوئی یا نہیں۔

میں downtime کے بغیر live site کو نئے provider پر کیسے منتقل کروں؟

منتقلی سے کم از کم 48 گھنٹے پہلے DNS TTL کو 300 seconds کر دیں، کیونکہ resolvers پچھلے TTL کے مطابق اتنی مدت تک پرانا IP فراہم کرتے رہتے ہیں۔ نیا host اس وقت تیار اور test کریں جب پرانا host ابھی network traffic فراہم کر رہا ہو۔ اپنی 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 report کرتا ہے، کیونکہ دونوں 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 ملتا جلتا ہو۔

کیا نئے server سے میری email اب بھی deliver ہوگی؟

اکثر شروع میں نہیں۔ نئے IP address کی sending history نہیں ہوتی، اس لیے receivers اس سے آنے والی mail کو مشتبہ سمجھتے ہیں، اور وہ spam میں چلی جاتی ہے یا براہ راست reject ہو جاتی ہے۔ SPF اور DKIM records بھی اس وقت تک پرانے host کی طرف اشارہ کرتے ہیں جب تک آپ انہیں update نہ کریں۔ Application mail کو ایسے relay یا email service کے ذریعے بھیجیں جس کی reputation پہلے سے موجود ہو، اور cutover سے پہلے mail کے DNS records update کریں، بعد میں نہیں۔