Developerদের জন্য DigitalOcean-এর বিকল্প কোনগুলো ভালো?

DigitalOcean-এর বিকল্পগুলোতে আসলে কী পরিবর্তন হয়

বেশিরভাগ DigitalOcean বিকল্পে মেশিন নয়, বিল পরিবর্তিত হয়। উভয় ক্ষেত্রেই আপনি একটি public IP, একটি virtio disk এবং root access-সহ Linux virtual machine পান। Control panel-এ কার logo আছে, আপনার kernel তা বিবেচনা করে না। পছন্দ নির্ধারণকারী মূল পার্থক্যগুলো হলো প্রতি GB RAM-এর দাম, অন্তর্ভুক্ত transfer allowance-এর পরিমাণ এবং সীমা ছাড়ালে প্রতি byte-এর খরচ, disk আসলে কী দিয়ে তৈরি, এবং operating system-এর ওপরের stack-এর কতটা অন্য কেউ আপনার হয়ে চালাবে।

এই guide-এ ওই বিষয়গুলো ধরে তুলনা করা হয়েছে, কারণ একজন developer terminal বা প্রকাশিত price list থেকেই প্রতিটি বিষয় যাচাই করতে পারেন। DigitalOcean কোথায় সঠিক পছন্দ, সেটিও এখানে বলা হয়েছে। কারণ কোনো তুলনায় কোনো সুবিধাই স্বীকার না করলে সেটি advertisement হয়ে যায়।

নিচের প্রতিটি price হলো প্রকাশিত list price, যা 5 August 2026-এ যাচাই করা হয়েছে। Price পরিবর্তিত হয়, এবং এখানে থাকা একাধিক provider 2026 সালেই তাদের price পরিবর্তন করেছে। Pricing structure অনেক ধীরে পরিবর্তিত হয়। তাই আগে ratio এবং billing model পড়ুন। এরপর commit করার আগে provider-এর নিজস্ব page-এ আজকের price নিশ্চিত করুন।

প্রতি GB RAM-এর মূল্যই তুলনা করার সংখ্যা

[
  {
    "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-এর মধ্যে প্রতি GB RAM-এর মূল্য খুব সামান্যই পরিবর্তিত হয়। 1 GB plan-এ DigitalOcean প্রতি GB-এর জন্য $6.00 নেয়। 4 GB plan-এও প্রতি GB-এর একই $6.00 মূল্য, যদিও plan-টির মাসিক মূল্য $24.00। একই provider-এ বড় plan নিলে কোনো ছাড় পাওয়া যায় না। তাই সিদ্ধান্তের বিষয় plan-এর আকার নয়। সিদ্ধান্তের বিষয় provider।

এখন Linode নামে পরিচিত যে service বিক্রি হয়, সেটি Akamai পরিচালনা করে। তারা 2 GB ও 4 GB shared plan-এর মূল্য যথাক্রমে $12 ও $24 রেখেছে। DigitalOcean-এর সঙ্গে dollar-এ এই মূল্য হুবহু একই। তাদের entry plan-এর মূল্য $5.00, যা DigitalOcean ও Akamai—উভয়ের চেয়ে কম। দুটি company-এর মূল্য একেবারে মিলে যাওয়া একটি গুরুত্বপূর্ণ সংকেত। এই tier-এর মূল্য hardware-এর ভিত্তিতে নয়, competitor-এর ভিত্তিতে নির্ধারিত। তাই এটি সেই competitor-এর মূল্য অনুসরণ করতেই থাকবে।

নিজেদের datacentre তৈরি করে euro-তে service বিক্রি করা provider-গুলোর ক্ষেত্রে পার্থক্য দেখা যায়। Hetzner CX23-এ প্রায় প্রতি মাসে $6.49 মূল্যে 4 GB RAM পাওয়া যায়। অর্থাৎ প্রতি GB-এর মূল্য $1.62, যা DigitalOcean-এর হারের প্রায় এক-চতুর্থাংশ। এই dollar মূল্য euro-তে প্রকাশিত list price থেকে রূপান্তর করা হয়েছে। তাই exchange rate পরিবর্তনের সঙ্গে এটি ওঠানামা করে। Hetzner 2026 সালে cloud-এর মূল্যও বাড়িয়েছে। ফলে পুরোনো comparison post-গুলোতে এমন মূল্য থাকতে পারে, যা এখন আর প্রযোজ্য নয়।

প্রতি GB RAM-এর মূল্য থেকে আপনি যে CPU পাবেন, সে সম্পর্কে কিছু জানা যায় না। Shared vCPU হলে hypervisor আপনার core-কে অন্য tenant-এর সঙ্গে ভাগ করে schedule করে। সঠিক পরীক্ষা করতে হলে আপনি যে server ভাড়া নিয়েছেন, সেটিতেই পরীক্ষা চালান:

vmstat 1 10

st column দেখুন। এটি দেখায়, আপনার vCPU চালানোর জন্য প্রস্তুত থাকা সময়ের কত শতাংশে hypervisor physical core অন্য tenant-কে দিয়েছে। Load-এর সময় কয়েক শতাংশ স্বাভাবিক। দীর্ঘ সময় ধরে double-digit সংখ্যা দেখা গেলে host oversubscribed। আপনি ব্যবহার করতে পারছেন না এমন core-এর ক্ষতিপূরণ কোনো প্রতি-GB মূল্যই করতে পারে না। আপনার ব্যস্ত সময়ে পরীক্ষা চালান। কারণ steal time পাশের tenant-এর সমস্যার ওপর নির্ভর করে, আর পাশের tenant-এরও নিজস্ব schedule থাকে। 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-এ 1 TB outbound transfer অন্তর্ভুক্ত করে এবং অতিরিক্ত ব্যবহারের জন্য GiB অনুযায়ী বিল করে। এতে প্রতি অতিরিক্ত TB-এর খরচ প্রায় $10.00 হয়। Akamai একই পরিমাণ TB অন্তর্ভুক্ত করে এবং এর প্রায় অর্ধেক বিল করে, অর্থাৎ প্রতি TB প্রায় $5.00। Vultr একই ধরনের overage rate-এ 2 TB অন্তর্ভুক্ত করে। Hetzner 20 TB অন্তর্ভুক্ত করে এবং এরপর প্রতি TB প্রায় $1.20 নেয়। এই হার অন্যগুলোর তুলনায় প্রায় এক order of magnitude ভিন্ন।

Headline সংখ্যার চেয়ে তিনটি কাঠামোগত বিষয় বেশি গুরুত্বপূর্ণ। চারটি provider-এই inbound traffic বিনামূল্যে। তাই শুধু আপনি বাইরে যে traffic পাঠান, সেটিই গণনা করা হয়। DigitalOcean এবং Vultr account-এর সব server-এর মধ্যে allowance ভাগ করে। ফলে একটি ব্যস্ত machine অন্য machine-এর quota ব্যবহার করতে পারে, আবার অনেক ছোট server একটি বড় pool ভাগ করে নিতে পারে। Private বা VPC network-এর মাধ্যমে serverগুলোর মধ্যে চলাচল করা traffic সাধারণত মোটেই গণনা করা হয় না। তাই database-কে private interface-এ রাখা billing decision-এর পাশাপাশি security decision-ও।

আপনি যদি cap-এর কাছাকাছিও না থাকেন, তাহলে এসব গুরুত্বপূর্ণ নয়। একটি blog, JSON response দেওয়া API বা ছোট SaaS এক মাসে 1 TB-এ পৌঁছাবে না। Video, image gallery, game server, package mirror এবং off-site backup target-এ পৌঁছাতে পারে। অনুমান করার আগে পরিমাপ করুন:

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 throttle করবে? Billing-এর জন্য অর্থ খরচ হয়। Throttling-এর প্রভাব পড়ে users-এর ওপর, ঠিক সেই সময়ে যখন users-এর সংখ্যা সবচেয়ে বেশি থাকে। Traffic spike হলে কোনটি ঘটবে, তা আগে থেকেই জানা দরকার।

NVMe নাকি SATA, এবং আপনি আসলে কোনটি পেয়েছেন তা যাচাই করার পদ্ধতি

Panel-এ NVMe লেখা আছে। এটি host-এর disk সম্পর্কে একটি দাবি; আপনার virtual machine সেই disk-গুলোর ওপর চলছে কি না, তা এতে নিশ্চিত হয় না। Local storage-এ আপনার virtual disk একই physical machine-এর ভেতরের drive-এ থাকে। Network storage-এ এটি datacentre network-এর মাধ্যমে একটি আলাদা storage cluster-এ পৌঁছায়। এ কারণেই তাৎক্ষণিক resize, live migration এবং একই জায়গায় snapshot নেওয়া সম্ভব হয়।

Guest-এর ভেতর দুটিকেই একই রকম দেখায়:

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

ROTA এবং rotational host যেকোনো non-rotational storage হিসেবে ঘোষণা করা device-এর জন্য 0 দেখায়। তাই NVMe-নির্ভর network volume, local NVMe-এর মতোই একই ফল দেখায়। এই মানটি জানায় যে disk-টি spinning platter নয়। Disk-টি কোথায় আছে, তা এটি জানাতে পারে না। Linux-এ NVMe disk নিশ্চিত করা অংশে device name এবং প্রতিটি name-এর অর্থ ব্যাখ্যা করা হয়েছে।

দুটিকে আলাদা করার পরীক্ষাটি হলো queue depth 1-এ latency মাপা। কারণ একটি ছোট read request-এর আড়ালে লুকিয়ে থাকার মতো আর কোনো কাজ থাকে না। 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 ব্যবহারকারীরা যে stall অনুভব করেন, তা আড়াল করে। দ্বিতীয় run-এ summary line-এ IOPS= দেখায়। আপনার বর্তমান provider এবং যে provider বিবেচনা করছেন তার একটি trial instance-এ একই দিনে দুটিই চালান, তারপর নিজের পাওয়া দুটি সংখ্যা তুলনা করুন। কোনো vendor-এর প্রকাশিত figure এমন একটি machine-এ মাপা হয়েছে যা আপনি দেখতে পারেন না। ভিন্ন সময়ে তিনবারও এটি চালান, কারণ একই plan-এ quiet host এবং busy host ভিন্ন ফল দেয়। VPS সঠিকভাবে benchmark করা অংশে পদ্ধতিটি ব্যাখ্যা করা হয়েছে, আর SSD VPS বলতে আসলে কী বোঝায় অংশে এর পেছনের marketing শব্দগুলোর অর্থ ব্যাখ্যা করা হয়েছে।

অঞ্চল: latency পরিমাপ করুন, মানচিত্র পড়বেন না

কোনো region list পরিমাপ না করা পর্যন্ত তা শুধু marketing। ব্যবহারকারী যে latency অনুভব করেন, তা হলো তাঁদের network থেকে আপনার server পর্যন্ত round trip। এটি map-এর দূরত্বের ওপর নয়, packet যে route দিয়ে যায় তার ওপর নির্ভর করে। 300 km দূরে থাকা একটি server congested transit link-এর পেছনে থাকলে, 1,500 km দূরে থাকা একটি server-এর কাছে হেরে যেতে পারে, যদি সেটি পরিষ্কার path ব্যবহার করে।

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-এর নিজস্ব packet loss ও latency দেখায়। তাই দুই hop-এর মধ্যে 60 ms বৃদ্ধি destination-কে দোষারোপ না করে কোন link সমস্যা তৈরি করছে তা শনাক্ত করে। আপনার ব্যবহারকারীরা যে network ব্যবহার করেন, সেই network-এর একটি machine থেকে এটি চালান। Internet-এ datacentre থেকে datacentre route-গুলো সাধারণত সবচেয়ে ভালো route। এগুলো প্রতিটি provider-এর কর্মক্ষমতাকে সমানভাবে ভালো দেখায়।

একটি মৌলিক বিষয় price পরিবর্তন হলেও বদলায় না। আপনার continent-এ কোনো provider-এর মাত্র একটি region থাকলে disaster recovery plan বাস্তবে continent পরিবর্তনের plan হয়ে দাঁড়ায়, এবং এর সঙ্গে সংশ্লিষ্ট latency-ও যুক্ত হয়। পৃষ্ঠায় থাকা region নয়, বাস্তবে যেসব region-এ failover করবেন সেগুলো গণনা করুন।

স্ন্যাপশট এবং ব্যাকআপের বিল আলাদা

স্টোরেজ অ্যাড-অনই সস্তা প্ল্যানকে ব্যয়বহুল করে তোলে। DigitalOcean স্ন্যাপশটের জন্য প্রতি মাসে প্রতি GiB $0.06 চার্জ করে। স্বয়ংক্রিয় ব্যাকআপের দাম তারা সার্ভারের দামের একটি অংশ হিসেবে নির্ধারণ করে: সাপ্তাহিক ব্যাকআপের জন্য প্ল্যানের দামের 20%, দৈনিক ব্যাকআপের জন্য 30%; এ ছাড়া প্রতি GiB ভিত্তিক usage-based বিকল্পও রয়েছে। উভয় pricing model-এর যুক্তি আছে, তবে এগুলো বিপরীত ধরনের সমস্যায় পড়ে। percentage price সার্ভারের আকার অনুযায়ী বাড়ে। তাই অল্প dataset থাকা বড় সার্ভারের ক্ষেত্রে অতিরিক্ত খরচ হয়। per GiB price আপনার data-এর পরিমাণ অনুযায়ী বাড়ে। তাই বড় volume-এ যুক্ত ছোট সার্ভারের ক্ষেত্রে অতিরিক্ত খরচ হয়।

একটি restore করতে কত খরচ হয় এবং কত সময় লাগে, তা জিজ্ঞাসা করুন। কারণ ব্যাকআপ সংরক্ষণের খরচ এই প্রশ্নের অপেক্ষাকৃত সহজ অংশ। সার্ভার destroy করলে তার snapshots-ও destroy হয় কি না, তা জিজ্ঞাসা করুন।

এরপর এমন একটি copy রাখুন, যার ওপর provider-এর নিয়ন্ত্রণ নেই। Provider-এর snapshots provider-এর account-এর ভেতরেই থাকে। তাই login হারানো, payment failure বা suspended account হলে একই সময়ে server এবং তার backups—দুটিই হারাতে পারেন। আপনার মালিকানাধীন storage-এ restic backups রাখতে object storage-এর জন্য কয়েক ডলার খরচ হয়। এগুলো যেকোনো provider-এ restore করা যায় এবং migration-কে চূড়ান্ত পরিবর্তনের বদলে reversible করে তোলে।

আপনি স্ট্যাকের কতটা নিজে চালাতে চান

প্রোভাইডাররা একটি ধারাবাহিক রেখায় অবস্থান করে। এক প্রান্তে আপনি একটি মেশিন ভাড়া নিয়ে তার সবকিছু নিজেই পরিচালনা করেন। অন্য প্রান্তে আপনি একটি git branch push করেন এবং কোনো server দেখতেই হয় না। RAM-এর প্রতি GB দামের তুলনা কেবল প্রথম প্রান্তে কার্যকর, কারণ দ্বিতীয় প্রান্তে আপনি memory নয়, শ্রম কিনছেন; আর শ্রমের প্রতি GB হিসেবে কোনো দাম থাকে না।

যে প্রান্তে আপনি আছেন, তুলনা করার আগে সে বিষয়ে সৎ থাকুন। প্রতি মাসে $15.15 দামের একটি managed database, $6 দামের একটি server-এর তুলনায় ব্যয়বহুল মনে হতে পারে। কিন্তু এর পেছনের কাজের ঘণ্টাগুলোর দাম হিসাব করলে চিত্রটি বদলে যায়: replication, failover, point in time restore, minor version upgrade এবং 03:00-এ কাউকে জাগিয়ে দেওয়া alert। এই কাজ যদি আপনার দায়িত্ব হয়, তাহলে নিজেই চালান এবং পার্থক্যের অর্থ রেখে দিন। আপনার কাজ যদি application পরিচালনা করা হয়, তাহলে এই কাজের দায়িত্ব আবার কিনে নেওয়া সাশ্রয়ী। Managed ও unmanaged-এর পার্থক্য নির্ধারণ করে price list-এর কোন কলামটি আপনার পড়া উচিত। আপনার সৎ উত্তর যদি হয় যে পুরো machine এবং তার disk নিজের নিয়ন্ত্রণে রাখতে চান, তাহলে সেটি provider বেছে নেওয়ার প্রশ্ন নয়; বরং VPS বনাম dedicated server বেছে নেওয়ার প্রশ্ন।

DigitalOcean সঠিক পছন্দ যেখানে

আপনি যখন শুধু virtual machine নয়, platform কিনছেন, তখন DigitalOcean বেশি কার্যকর।

• Managed databases। 1 GiB RAM এবং 10 GiB storage-এর জন্য Managed PostgreSQL এবং MySQL-এর দাম মাসে $15.15 থেকে শুরু হয়। অতিরিক্ত storage প্রতি GiB হিসেবে বিল করা হয়, আর standby node-এর দাম প্রতি node হিসেবে নির্ধারিত হয়। একই নির্ভরযোগ্যতা নিজে তৈরি করতে হলে Patroni বা repmgr, একটি consensus store, একটি connection proxy এবং বাস্তবে অনুশীলন করা একটি failover drill দরকার। দুই সদস্যের একটি team একই সঙ্গে এটি রক্ষণাবেক্ষণ এবং নতুন feature প্রকাশ করতে পারে না।
• App Platform। একটি branch push করলে build, certificate এবং চলমান service পাওয়া যায়। কোনো operating system patch করার প্রয়োজন নেই। এই product-এর সস্তা VPS সংস্করণে শনিবারে আপনাকেই সেই কাজ করতে হয়।
• Object storage এবং load balancer, যেগুলো একটি পরিণত Terraform provider সমর্থন করে। Code থেকে পুরো fleet ধ্বংস করে আবার তৈরি করা যায়—এটি কম unit price-এর চেয়ে বেশি মূল্যবান।
• Product-এর পেছনের company। প্রকাশিত support tier, history-সহ status page এবং client-এর security questionnaire-এর উত্তর দেওয়ার মতো একটি organisation। আপনি hosting resell করলে, প্রতি GB-তে কয়েক dollar সাশ্রয়ের চেয়ে এটি বেশি মূল্যবান।

প্রকৃত outbound traffic-সহ সাধারণ virtual machine বেশি সংখ্যায় ব্যবহার করলেই DigitalOcean ব্যয়বহুল হয়ে ওঠে। একটি alternative ঠিক এই পরিস্থিতির সমাধান করে, আর self-hosting করা developer-এর কেনাকাটার অধিকাংশই এই ধরনের virtual machine।

Downtime ছাড়া নতুন provider-এ স্থানান্তর

Migration-এর সময় downtime-এর একমাত্র কারণ হলো data নতুন IP-তে চলে যাওয়ার পরও পুরোনো IP-তে traffic আসা। নিচের প্রতিটি ধাপ এই সময়সীমা ছোট এবং পূর্বানুমানযোগ্য করার জন্য।

Move-এর অন্তত 48 ঘণ্টা আগে DNS নিয়ে কাজ শুরু করুন। Resolver আপনার A record-টি তার TTL (time to live) যতক্ষণ নির্ধারিত থাকে, ততক্ষণ cache করে রাখে। তাই 24 hour TTL থাকা কোনো record পরিবর্তন করার পরও resolver সর্বোচ্চ এক দিন পর্যন্ত user-কে পুরোনো server-এ পাঠাতে পারে। Cutover-এর সময় TTL কমালে কোনো লাভ নেই, কারণ resolver ইতিমধ্যে পুরোনো expiry-সহ পুরোনো value ধরে রেখেছে। আগে TTL কমান, পুরোনো value-এর মেয়াদ শেষ হওয়া পর্যন্ত অপেক্ষা করুন, তারপর migrate করুন।

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

প্রথম command-টি answer-এর দ্বিতীয় column-এ বর্তমান TTL দেখায়। আপনার DNS provider-এ সেটি 300 করুন, তারপর যে সংখ্যাটি বদলেছেন তার চেয়ে বেশি সময় অপেক্ষা করুন।

এরপর এই ক্রমে কাজ করুন।

1. নতুন server provision করুন এবং সেখানে অন্য কিছু দেওয়ার আগে harden করুন। নতুন VPS-এ প্রথম দশ মিনিট-এ তাড়াহুড়োর সময় সাধারণত বাদ পড়ে যাওয়া অংশটি ব্যাখ্যা করা হয়েছে।
2. Application stack install করুন এবং পুরোনো server স্বাভাবিকভাবে service দিতে থাকা অবস্থায় rsync দিয়ে data copy-এর প্রথম ধাপ চালান।
3. এখনই নতুন host-এ TLS certificate issue করুন এবং DNS-01 challenge ব্যবহার করুন। কারণ HTTP-01 challenge DNS বর্তমানে যে IP-তে নির্দেশ করছে, সেই IP-র বিরুদ্ধে validation করে; সেটি এখনও পুরোনো server। একটি DNS-01 challenge এই ক্রম-নির্ভরতার সমস্যা পুরোপুরি দূর করে।
4. কোনো public change করার আগে নিজের laptop-এ DNS override করে নতুন host পরীক্ষা করুন। 203.0.113.20 example.com-কে /etc/hosts-এ যোগ করে আসল site browse করুন, তারপর line-টি মুছে দিন। এই test-এ কোনো user প্রভাবিত হবে না।
5. Database-এর size বিবেচনা করুন। কয়েক GB-এর মধ্যে হলে dump ও restore write freeze-এর সময়ের মধ্যে করা যায়। এর চেয়ে বেশি হলে কয়েক দিন আগে পুরোনো database থেকে নতুন database-এ replication চালু করুন এবং সেটিকে sync হতে দিন, যাতে freeze শুধু promotion-এর সময়টুকু জুড়ে থাকে।
6. Write freeze করুন। Application-কে maintenance বা read-only mode-এ রাখুন। User-রা শুধু এই অংশটিই দেখতে পাবে, এবং এটি কয়েক মিনিট স্থায়ী হওয়া উচিত।
7. Final delta চালান: একই rsync আবার চালান, তারপর final database sync করুন।
8. A এবং AAAA record নতুন IP-তে পরিবর্তন করুন। 300 second TTL থাকলে অধিকাংশ resolver প্রায় পাঁচ মিনিটের মধ্যে নতুন value অনুসরণ করবে।
9. পুরোনো server অন্তত এক দিন চালু ও reachable রাখুন, কারণ কিছু resolver ছোট TTL উপেক্ষা করে। পুরোনো application এখনও writable থাকলে দেরিতে আসা request ভুল database-এ write করবে। তাই পুরোনো host-কে নতুন database-এ নির্দেশ করুন অথবা সেখান থেকে maintenance page ফেরত দিন।
10. এক দিন নতুন server-এর error rate monitor করুন, TTL আবার স্বাভাবিক value-তে বাড়ান, এবং একই সন্ধ্যায় নয়—এক সপ্তাহ পরে পুরোনো server destroy করুন।

Copy করার কাজটি দুটি command-এ হয় এবং প্রতিটি command দুবার চালানো হয়। File sync:

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

-a ownership, permissions এবং timestamps সংরক্ষণ করে, -H hard link সংরক্ষণ করে, -AX ACL এবং extended attribute সংরক্ষণ করে, আর --numeric-ids দুই machine-এ আলাদা হওয়া name-এর মাধ্যমে rsync যেন user ID remap না করে তা নিশ্চিত করে। কয়েক দিন আগে এটি চালান, তারপর freeze-এর সময় আবার চালান। দ্বিতীয়বার শুধু পরিবর্তিত data transfer হবে।

Dump করার মতো ছোট PostgreSQL-এর জন্য:

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

MySQL বা MariaDB-এর জন্য:

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

--single-transaction InnoDB table-এ একটি transaction-এর মধ্যে dump নেয়। ফলে result consistent থাকে এবং command চলার সময় application write চালিয়ে যেতে পারে। এই flag না দিলে mysqldump table lock করে। এতে আপনার পরিকল্পনার আগেই write freeze শুরু হয়ে যায় এবং কখন তা শুরু হবে সেই নিয়ন্ত্রণ আপনার হাতে থাকে না।

আপনার server-এর বাইরের দুটি বিষয় সমস্যা তৈরি করতে পারে। নতুন IP address-এর কোনো email reputation থাকে না। তাই নতুন box থেকে সরাসরি পাঠানো mail spam হিসেবে filter হতে পারে। আগে থেকেই reputation থাকা relay ব্যবহার করে mail পাঠান। এছাড়া payment gateway বা client firewall-এর মতো যেসব partner আপনার outbound IP allowlist করে, cutover-এর আগে তাদের configuration update করতে হবে। তা না হলে traffic সরানোর মুহূর্তে ওই call ব্যর্থ হতে শুরু করবে।

কমিট করার আগে যা পরীক্ষা করবেন

• মূল্যটি promotional কি না এবং renewal-এর সময় কত হবে। প্রথম মেয়াদের discount renewal-এর সময় দ্বিগুণ হলে সেটি প্রকৃত খরচই, শুধু পরে পরিশোধ করতে হবে।
• মেয়াদটি prepaid কি না। SSD Nodes যেভাবে বিক্রি করে, multi-year prepaid plan-এ আগে টাকা পরিশোধের বিনিময়ে RAM-এর প্রতি GB-এর দাম অনেক কম হয়। এর বিনিময়ে পরের মাসে plan বাতিল করে সরে আসা যায় না। তাই আপনি কতটা নিশ্চিত, তার সঙ্গে মেয়াদ মিলিয়ে নিন।
• প্রতি মাসে snapshot-এর খরচ কত এবং restore করতে অর্থ ও কত মিনিট লাগে।
• অতিরিক্ত ব্যবহারের জন্য billing করা হয়, নাকি traffic throttling করা হয়।
• IPv6 সঠিকভাবে routed কি না, নাকি শুধু একটি address আলাদাভাবে যুক্ত করা আছে।
• আপনার code থেকে server পুনর্নির্মাণের পরিকল্পনা থাকলে, রক্ষণাবেক্ষণ করা Terraform provider-সহ API আছে কি না।
• support-এ কীভাবে যোগাযোগ করতে হয় এবং server down থাকলে published response target কত। Sales question-এর response target নয়।

আপনার নিজের bill-এ যে বিষয়টির প্রভাব সবচেয়ে বেশি, সেই ভিত্তিতে নির্বাচন করুন। সেই বিষয়টি memory হলে RAM-এর প্রতি GB-এর দামই সিদ্ধান্ত নির্ধারণ করবে। outbound traffic হলে included transfer-এর পরিমাণই সিদ্ধান্ত নির্ধারণ করবে। আপনার নিজের সময়ের মূল্য বেশি হলে managed platform-ই সিদ্ধান্ত নির্ধারণ করবে। এখানে তুলনা করা চারটির মধ্যে DigitalOcean-এর managed platform সবচেয়ে শক্তিশালী।

FAQ

Hetzner কি সবসময় DigitalOcean-এর চেয়ে সস্তা?

সাধারণ virtual machine-এর ক্ষেত্রে প্রতি GB RAM-এর খরচ অনেক কম: 5 August 2026 অনুযায়ী entry shared plan-এ প্রায় $1.62, যেখানে DigitalOcean-এ খরচ $6.00। Managed service যুক্ত হলে তুলনাটি বদলে যায়। Hetzner server ও networking বিক্রি করে। তাই managed database বা push-to-deploy platform আপনাকেই চালাতে হবে, অথবা third party থেকে নিতে হবে, এবং সেই কাজের সময়েরও খরচ আছে। 2026 সালে Hetzner cloud-এর দামও বাড়িয়েছে। তাই পুরোনো কোনো article-এর ওপর নির্ভর না করে বর্তমান euro মূল্য যাচাই করুন।

Managed database প্রয়োজন হলে কোন DigitalOcean বিকল্প বেছে নেব?

Vultr এবং Akamai উভয়ই managed database বিক্রি করে। তাই managed database-ই যদি DigitalOcean ব্যবহারের প্রধান কারণ হয়, তবে এগুলো সবচেয়ে কাছাকাছি বিকল্প। কম খরচের European host-গুলো সাধারণত managed database বিক্রি করে না। সেক্ষেত্রে replication এবং পরীক্ষিত failover-সহ PostgreSQL বা MySQL নিজেকেই চালাতে হবে। এটি বাস্তব প্রশাসনিক কাজ। সস্তা server নেওয়ার আগে হিসাব করুন, managed 1 GiB instance-এর মাসিক $15.15 খরচের তুলনায় এতে সত্যিই কতটা সাশ্রয় হবে।

Downtime ছাড়া চলমান site-কে নতুন provider-এ কীভাবে স্থানান্তর করব?

স্থানান্তরের অন্তত 48 ঘণ্টা আগে DNS TTL কমিয়ে 300 seconds করুন। কারণ resolver-গুলো আগের TTL অনুযায়ী পুরোনো IP পরিবেশন করতে থাকে। পুরোনো host traffic পরিবেশন করার সময়ই নতুন host তৈরি ও পরীক্ষা করুন। নিজের machine-এ /etc/hosts override ব্যবহার করুন, যাতে অন্য কেউ এটি দেখতে না পারে। এরপর কয়েক মিনিটের জন্য write বন্ধ রাখুন, শেষ rsync delta এবং শেষ database sync চালান, A ও AAAA record পরিবর্তন করুন, এবং resolver কোনো কারণে সংক্ষিপ্ত TTL উপেক্ষা করলে ব্যবহারের জন্য পুরোনো server এক সপ্তাহ চালু রাখুন।

সস্তা VPS কি ধীর disk বোঝায়?

নিজে থেকে নয়। গুরুত্বপূর্ণ বিষয় হলো virtual disk host-এর local storage-এ আছে, নাকি network storage cluster-এ। Panel-এ এটি প্রায়ই স্পষ্টভাবে লেখা থাকে না। উভয় disk-ই non-rotational হওয়ায় lsblk -o NAME,ROTA দুটির জন্যই 0 দেখায়। তাই নিজে মাপুন: --iodepth=1 --bs=4k --direct=1 সহ fio চালান এবং 99th percentile completion latency দেখুন। Network volume প্রতিটি read-এর জন্য datacentre network-এর একটি round trip যোগ করে। তাই deep-queue throughput একই রকম দেখালেও এর latency floor local NVMe-এর চেয়ে বেশি থাকে।

নতুন server থেকে পাঠানো email কি এখনও delivery হবে?

প্রথমে প্রায়ই হবে না। নতুন IP address-এর কোনো sending history থাকে না। তাই receiver-রা সেখান থেকে আসা mail-কে সন্দেহজনক মনে করে এবং তা spam-এ পাঠায় অথবা সরাসরি reject করে। SPF ও DKIM record-ও update না করা পর্যন্ত পুরোনো host-কে নির্দেশ করে। এমন relay বা email service ব্যবহার করে application mail পাঠান যার আগে থেকেই ভালো reputation আছে। Cutover-এর পরে নয়, তার আগেই mail-এর DNS record update করুন।