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

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

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

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

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

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

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

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

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

vmstat 1 10

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

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

আপনি 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-এর জন্য billing হয়। Database শুরুতে খালি থাকে। তাই এটি install করার এক দিন পরে প্রথম কার্যকর reading পাওয়া যায়, আর এক মাস পরে প্রথম পূর্ণ মাসের reading পাওয়া যায়। তার আগে provider-এর নিজস্ব bandwidth graph-ই আপনার একমাত্র record।

আরও একটি প্রশ্ন করুন, যার উত্তর কোনো price list দেয় না: allowance পার হলে provider কি billing করবে, নাকি port-এর গতি কমিয়ে দেবে? Billing করলে খরচ বাড়ে। Throttling করলে users ক্ষতিগ্রস্ত হয়, ঠিক সেই সময়ে যখন তাদের সংখ্যা সবচেয়ে বেশি থাকে। Traffic spike হলে আপনি কোন ফল কিনছেন, তা আগে থেকেই জানা দরকার।

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

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

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

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

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

এদের আলাদা করার পরীক্ষাটি হলো queue depth 1-এ latency মাপা। কারণ একটি ছোট single read-এর আড়ালে অন্য কোনো কাজ লুকিয়ে থাকে না। Local NVMe একই chassis থেকে উত্তর দেয়। Network volume-এ প্রতিটি read-এর জন্য datacentre network-এর ওপর দিয়ে একটি round trip যোগ হয়। তাই deep queue depth-এ throughput একই রকম দেখালেও network volume-এর 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-এর instance এবং যে provider বিবেচনা করছেন তার trial instance-এ একই দিনে দুটিই চালান। এরপর আপনার পাওয়া দুটি সংখ্যা তুলনা করুন। কোনো vendor-এর প্রকাশিত figure এমন একটি machine-এ মাপা হয়েছে যা আপনি দেখতে পারেন না। ভিন্ন সময়ে তিনবারও run করুন, কারণ একই plan-এ quiet host এবং busy host ভিন্ন ফল দেয়। সঠিকভাবে VPS benchmark করা অংশে পদ্ধতিটি ব্যাখ্যা করা হয়েছে, আর SSD VPS বলতে বাস্তবে কী বোঝায় অংশে এর পেছনের marketing শব্দগুলোর ব্যাখ্যা রয়েছে।

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

পরিমাপ না করা পর্যন্ত region list শুধু marketing। ব্যবহারকারী যে latency অনুভব করেন, তা হলো তাঁদের network থেকে আপনার server পর্যন্ত round trip। এটি মানচিত্রের দূরত্বের ওপর নয়, packet কোন route দিয়ে যাচ্ছে তার ওপর নির্ভর করে। 300 km দূরে থাকা congestion-যুক্ত transit link-এর পেছনের একটি server, 1,500 km দূরে থাকা পরিষ্কার path-এর 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 jump হলে destination-কে দোষ না দিয়ে কোন link সমস্যা তৈরি করছে তা শনাক্ত করা যায়। ব্যবহারকারীরা যে network ব্যবহার করেন, সেই network-এর একটি machine থেকে এটি চালান। Datacentre থেকে datacentre route-গুলো Internet-এর সেরা route। তাই এগুলো সব provider-কেই সমানভাবে ভালো দেখায়।

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

Snapshots এবং backup-এর জন্য আলাদা বিল

Storage add-on-এর খরচেই সস্তা plan ব্যয়বহুল হয়ে যায়। DigitalOcean snapshots-এর জন্য প্রতি GiB-এ প্রতি মাসে $0.06 চার্জ করে। Automatic backup-এর দাম server-এর মূল্যের অংশ হিসেবে নির্ধারণ করে: weekly backup-এর জন্য plan price-এর 20%, daily backup-এর জন্য 30%; এ ছাড়া প্রতি GiB-ভিত্তিক usage-based option-ও রয়েছে। দুটি pricing model-ই যুক্তিসঙ্গত, তবে এগুলো বিপরীত ধরনের সমস্যায় পড়ে। Percentage-based price server-এর আকারের সঙ্গে বাড়ে, তাই ছোট dataset থাকা বড় server-এর ক্ষেত্রে অতিরিক্ত খরচ হয়। Per GiB price আপনার data-এর পরিমাণের সঙ্গে বাড়ে, তাই বড় volume-এ যুক্ত ছোট server-এর ক্ষেত্রে অতিরিক্ত খরচ হয়।

Restore করতে কত খরচ হয় এবং কত সময় লাগে তা জিজ্ঞাসা করুন। Backup সংরক্ষণে কত খরচ হয়, প্রশ্নটির এটি শুধু সাধারণ অংশ। Server ধ্বংস করলে তার snapshots-ও ধ্বংস হয় কি না, তা জিজ্ঞাসা করুন।

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

আপনি stack-এর কতটা নিজে চালাতে চান

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

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

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 release করতে পারে না।
• App Platform। একটি branch push করুন, build, certificate এবং চালু service পান; operating system patch করার প্রয়োজন নেই। এই product-এর সস্তা VPS সংস্করণে operating system patch করার কাজটি আপনাকেই শনিবারে করতে হয়।
• Object storage এবং load balancer, যেগুলো mature Terraform provider সমর্থন করে। code থেকে যে fleet ধ্বংস করে আবার তৈরি করা যায়, তার মূল্য কম unit price-এর চেয়ে বেশি।
• Product-এর পেছনের company। প্রকাশিত support tier, history-সহ একটি status page এবং client-এর security questionnaire-এর উত্তর দেওয়ার মতো একটি organisation। আপনি যদি hosting resell করেন, তাহলে প্রতি GB-এ কয়েক ডলার সাশ্রয়ের চেয়ে এর মূল্য বেশি।

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

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

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-এর মেয়াদ শেষ হওয়া পর্যন্ত অপেক্ষা করুন, তারপর migration করুন।

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

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

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

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 এই ordering সমস্যা সম্পূর্ণ দূর করে।
4. Public পরিবর্তন করার আগে নিজের laptop-এ DNS override করে নতুন host পরীক্ষা করুন। 203.0.113.20 example.com-এ /etc/hosts যোগ করে real site browse করুন, তারপর line-টি মুছে দিন। এই test-এ কোনো user প্রভাবিত হবে না।
5. Database-এর size বিবেচনা করুন। কয়েক GB-এর কম হলে dump এবং restore write freeze-এর মধ্যেই সম্পন্ন করা যায়। এর বেশি হলে কয়েক দিন আগে পুরোনো database থেকে নতুন database-এ replication সেট up করুন এবং catch up করতে দিন, যাতে 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-এ point করুন অথবা সেখান থেকে maintenance page return করুন।
10. এক দিন নতুন server-এর error rate monitor করুন, TTL আবার স্বাভাবিক value-তে ফিরিয়ে দিন, এবং একই সন্ধ্যায় নয়—এক সপ্তাহ পরে পুরোনো server destroy করুন।

Copy করার কাজটি দুটি 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-এর মধ্যে ভিন্ন user name-এর মাধ্যমে rsync যেন user ID remap না করে তা নিশ্চিত করে। কয়েক দিন আগে এটি চালান, তারপর 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 table-এর dump একটি transaction-এর মধ্যে নেয়। ফলে result consistent থাকে এবং command চলার সময় application write চালিয়ে যেতে পারে। এই flag ছাড়া mysqldump table lock করে। এর অর্থ write freeze আপনার পরিকল্পনার আগেই শুরু হয়ে যায় এবং freeze কখন শুরু হবে তা আপনি নির্ধারণ করতে পারেন না।

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

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

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

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

FAQ

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

সাধারণ virtual machine-এর ক্ষেত্রে RAM-এর প্রতি GB হিসাবে এটি অনেক সস্তা: 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 ছাড়া live 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 report করে। বরং পরিমাপ করুন: --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 এখনও delivered হবে?

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