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

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

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

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

ذیل کی ہر قیمت 5 August 2026 کو checked published list price ہے۔ قیمتیں تبدیل ہوتی رہتی ہیں، اور یہاں شامل ایک سے زیادہ providers نے 2026 کے دوران اپنی قیمتیں تبدیل کیں۔ Pricing structure کہیں زیادہ آہستہ تبدیل ہوتی ہے، اس لیے پہلے ratios اور billing model پڑھیں، پھر commit کرنے سے پہلے provider کے اپنے page پر آج کی قیمت confirm کریں۔

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 پر بھی فی GB وہی $6.00 وصول کرتا ہے، جس کی ماہانہ قیمت $24.00 ہے۔ اسی provider پر بڑا plan منتخب کرنے سے کوئی رعایت نہیں ملتی، اس لیے فیصلہ plan کے سائز پر منحصر نہیں ہوتا۔ اصل فیصلہ provider کا ہے۔

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

فرق ان providers کے ساتھ نمایاں ہوتا ہے جو اپنے datacentres بناتے ہیں اور euro میں فروخت کرتے ہیں۔ Hetzner CX23 تقریباً $6.49 ماہانہ میں 4 GB RAM دیتا ہے، یعنی فی GB $1.62، جو DigitalOcean کی شرح کے تقریباً ایک چوتھائی کے برابر ہے۔ یہ dollar رقم euro کی فہرستی قیمت سے تبدیل کی گئی ہے، اس لیے exchange rate کے ساتھ بدلتی رہتی ہے۔ Hetzner نے 2026 کے دوران cloud prices بھی بڑھائی تھیں، اس لیے پرانی comparison posts میں ایسی قیمتیں درج ہیں جو اب دستیاب نہیں۔

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

vmstat 1 10

st column پڑھیں۔ یہ بتاتا ہے کہ آپ کا vCPU چلنے کے لیے تیار تھا، مگر hypervisor نے physical core کسی دوسرے tenant کو دے دیا، اس وقت کا فیصد کتنا تھا۔ Load کے دوران چند فیصد معمول کی بات ہے۔ مسلسل دو ہندسوں کا عدد اس بات کی علامت ہے کہ host پر ضرورت سے زیادہ tenants موجود ہیں، اور کوئی بھی فی GB قیمت ایسے core کی تلافی نہیں کر سکتی جسے آپ استعمال نہ کر سکیں۔ اسے اپنے مصروف ترین وقت میں چلائیں، کیونکہ steal time پڑوسی tenant کا مسئلہ ہے اور پڑوسی tenants کے اپنے schedules ہوتے ہیں۔ 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 ابتدائی پلان میں outbound transfer کے 1 TB شامل کرتا ہے اور اضافی استعمال کی billing GiB کے حساب سے کرتا ہے، جو ہر اضافی TB کے لیے تقریباً $10.00 بنتی ہے۔ Akamai میں اتنے ہی TB شامل ہیں اور اس کی billing تقریباً نصف ہے، یعنی فی TB تقریباً $5.00۔ Vultr میں 2 TB شامل ہیں اور اضافی استعمال کی شرح تقریباً اتنی ہی ہے۔ Hetzner میں 20 TB شامل ہیں، اس کے بعد تقریباً $1.20 فی TB چارج ہوتا ہے، جو دیگر providers کے مقابلے میں تقریباً دس گنا فرق ہے۔

تین بنیادی تفصیلات headline numbers سے زیادہ اہم ہیں۔ چاروں providers میں inbound traffic مفت ہے، اس لیے صرف بھیجا جانے والا data شمار ہوتا ہے۔ DigitalOcean اور 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 کی billing ہوتی ہے۔ Database ابتدا میں خالی ہوتا ہے، اس لیے پہلی مفید reading اسے install کرنے کے ایک دن بعد ملتی ہے، جبکہ پہلا مکمل ماہانہ data ایک ماہ بعد دستیاب ہوتا ہے۔ اس وقت تک provider کا اپنا bandwidth graph ہی آپ کے پاس واحد record ہوتا ہے۔

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

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 ناکام ہونا شروع ہو جائیں گی۔

خرید سے پہلے کیا جانچیں

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

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

FAQ

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

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

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

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

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

منتقلی سے کم از کم 48 گھنٹے پہلے DNS TTL کو 300 seconds تک کم کریں، کیونکہ resolvers سابقہ TTL کی مدت تک پرانا IP فراہم کرتے رہتے ہیں۔ پرانا host traffic فراہم کرتا رہے، اسی دوران نیا host تیار کریں اور اس کی جانچ کریں۔ اپنی مشین پر /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 ہیں۔ اس کے بجائے پیمائش کریں: fio کو --iodepth=1 --bs=4k --direct=1 کے ساتھ چلائیں اور 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 بھی آپ کے update کرنے تک پرانے host کی طرف اشارہ کرتے رہتے ہیں۔ Application mail کسی ایسے relay یا email service کے ذریعے بھیجیں جس کی reputation پہلے سے موجود ہو، اور cutover سے پہلے mail کے DNS records update کریں، بعد میں نہیں۔