جایگزین‌های DigitalOcean برای توسعه‌دهندگان

تفاوت واقعی جایگزین‌های DigitalOcean

بیشتر جایگزین‌های DigitalOcean صورت‌حساب را تغییر می‌دهند، نه ماشین را. در هر دو حالت، یک ماشین مجازی Linux با IP عمومی، دیسک virtio و دسترسی root دریافت می‌کنید و kernel شما اهمیتی نمی‌دهد چه لوگویی روی control panel قرار دارد. عواملی که انتخاب را تعیین می‌کنند عبارت‌اند از قیمت هر GB از RAM، اندازه سهمیه انتقال داده included و هزینه هر byte اضافه بر آن، ساختار واقعی دیسک، و این‌که چه مقدار از لایه‌های بالاتر از سیستم‌عامل را شخص دیگری برای شما اجرا خواهد کرد.

این راهنما گزینه‌ها را بر اساس همین معیارها مقایسه می‌کند، زیرا یک توسعه‌دهنده می‌تواند تک‌تک آن‌ها را از طریق terminal یا فهرست قیمت منتشرشده بررسی کند. همچنین مواردی را بیان می‌کند که در آن‌ها DigitalOcean انتخاب مناسبی است؛ زیرا مقایسه‌ای که هیچ امتیازی به یک گزینه ندهد، تبلیغ محسوب می‌شود.

تمام قیمت‌های زیر، قیمت‌های فهرست منتشرشده هستند که در 5 August 2026 بررسی شده‌اند. ارقام DigitalOcean در 21 October 2026 دوباره بررسی شدند و تغییری نکرده بودند. قیمت‌ها تغییر می‌کنند و بیش از یک ارائه‌دهنده در این فهرست، قیمت‌های خود را در طول 2026 تغییر داده است. ساختار قیمت‌گذاری بسیار آهسته‌تر تغییر می‌کند؛ بنابراین ابتدا نسبت‌ها و مدل صورت‌حساب را بررسی کنید و سپس پیش از تعهد، عدد امروز را در صفحه خود ارائه‌دهنده تأیید کنید.

قیمت هر 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 (unavailable Oct 2026)",
    "ram_gb": 4,
    "monthly_usd": "6.49",
    "usd_per_gb_ram": "1.62"
  }
]

در یک ارائه‌دهنده، قیمت هر GB از RAM تقریباً ثابت می‌ماند. DigitalOcean در پلن 1 GB برای هر GB مبلغ $6.00 دریافت می‌کند و در پلن 4 GB نیز همان مبلغ $6.00 برای هر GB را دریافت می‌کند؛ این پلن ماهانه با قیمت $24.00 عرضه می‌شود. انتخاب پلن بزرگ‌تر نزد همان ارائه‌دهنده تخفیفی ایجاد نمی‌کند، بنابراین اندازه پلن عامل تصمیم‌گیری نیست. ارائه‌دهنده عامل تصمیم‌گیری است.

Akamai، که اکنون چیزی را عرضه می‌کند که پیش‌تر Linode بود، پلن‌های shared با 2 GB و 4 GB را به‌ترتیب با قیمت‌های $12 و $24 عرضه می‌کند؛ این قیمت‌ها تا آخرین دلار با DigitalOcean یکسان‌اند. پلن ورودی آن با قیمت $5.00 ارزان‌تر است. یکسان بودن دقیق قیمت دو شرکت، نشانه‌ای است که باید به آن توجه کرد: قیمت این رده بر اساس قیمت رقیب تعیین شده است، نه سخت‌افزار، و همچنان قیمت رقیب را دنبال خواهد کرد.

تفاوت قیمت با ارائه‌دهندگانی آشکار می‌شود که دیتاسنترهای خود را می‌سازند و با یورو قیمت‌گذاری می‌کنند. در 5 August 2026، یک Hetzner CX23 در ازای حدود $6.49 در ماه، 4 GB RAM در اختیار شما می‌گذاشت؛ یعنی $1.62 برای هر GB، که تقریباً یک‌چهارم نرخ DigitalOcean است. در 21 October 2026 هنوز نمی‌توانید آن را سفارش دهید. Hetzner مدل CX23 و تمام پلن‌های دیگر در خط Cost-Optimized را در حال حاضر unavailable اعلام کرده و توضیح می‌دهد که این خط روی سخت‌افزار قدیمی‌تر اجرا می‌شود؛ بنابراین تعداد سرورها محدود است. صفحه وضعیت آن از 26 June 2026 تاکنون اطلاعیه‌ای درباره availability محدود cloud instances داشته و این اطلاعیه در 21 October 2026 نیز همچنان نمایش داده می‌شد. پلنی که نمی‌توانید سفارش دهید، قیمت قابل‌مقایسه‌ای به ازای هر GB ندارد. در 6 October 2026، Hetzner مدل CPX02 را اضافه کرد؛ این مدل یک پلن Regular Performance با 1 vCPU، مقدار 1 GB RAM و 20 GB NVMe است و کوچک‌ترین shared server آن محسوب می‌شود. در 21 October 2026، صفحه خود Hetzner قیمت آن را در locationهای EU، ماهانه €6.49 بدون VAT اعلام می‌کرد؛ یعنی پیش از تبدیل به دلار، €6.49 برای هر GB از RAM، در برابر $6.00 در DigitalOcean. همان صفحه، CPX02 و تمام پلن‌های دیگر Regular Performance را در حال حاضر unavailable نشان می‌داد؛ بنابراین پیش از مقایسه بررسی کنید که بتوانید آن را در location موردنظر خود سفارش دهید. هر رقم دلاری برای Hetzner از قیمت فهرست‌شده به یورو تبدیل شده است و با نرخ ارز تغییر می‌کند. Hetzner همچنین در سال 2026 قیمت‌های cloud را افزایش داد، بنابراین اعداد درج‌شده در پست‌های مقایسه قدیمی ممکن است دیگر وجود نداشته باشند.

قیمت هر GB از RAM درباره CPU دریافتی شما چیزی نمی‌گوید. vCPU اشتراکی یعنی hypervisor زمان اجرای core شما را در کنار tenantهای دیگر زمان‌بندی می‌کند، و بررسی معتبر باید روی سروری انجام شود که واقعاً اجاره کرده‌اید:

vmstat 1 10

ستون st را بخوانید. این ستون درصد زمانی را نشان می‌دهد که vCPU شما آماده اجرا بوده اما hypervisor، core فیزیکی را به tenant دیگری تحویل داده است. چند درصد در زمان load طبیعی است. عدد دورقمیِ پایدار یعنی host بیش از ظرفیت خود tenant دارد و هیچ قیمتی به ازای هر GB نمی‌تواند نبودن core قابل‌استفاده را جبران کند. آزمون را در ساعت شلوغ خود اجرا کنید، چون steal time به همسایه‌ها مربوط است و همسایه‌ها برنامه زمانی دارند. برای بررسی گسترده‌تر هزینه واقعی یک ماه hosting پس از افزودن storage و traffic، هزینه یک VPS در هر ماه را بخوانید.

هزینه واقعی ترافیک included

[
  {
    "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 حافظه RAM حدود 1 TB (1,000 GiB) ترافیک خروجی included ارائه می‌کند و بابت مصرف مازاد، به‌ازای هر GiB مبلغ $0.01 دریافت می‌کند؛ این مبلغ برای هر TB اضافی تقریباً برابر با $10.00 است. پلن پایه واقعی آن، یعنی 512 MiB حافظه RAM با هزینه ماهانه $4.00، فقط 500 GiB included دارد. این سهمیه سپس متناسب با اندازه پلن افزایش می‌یابد و در پلن‌های Basic بزرگ‌تر به 6,000 GiB می‌رسد؛ بنابراین عدد مربوط به همان پلنی را بخوانید که واقعاً انتخاب می‌کنید. Akamai در Nanode خود همان مقدار TB را included ارائه می‌کند و هزینه مازاد آن تقریباً نصف این مقدار، یعنی حدود $5.00 برای هر TB است. Vultr مقدار 2 TB را included ارائه می‌کند و نرخ مصرف مازاد آن تقریباً مشابه است. در 5 August 2026، پلن Hetzner CX23 مقدار 20 TB را included داشت و پس از آن، حدود $1.20 برای هر TB دریافت می‌کرد؛ این اختلاف با سایر ارائه‌دهندگان حدود یک مرتبه بزرگی است. در 21 October 2026، صفحه Hetzner همچنان 20 TB ترافیک included را برای locationهای آن در EU، از جمله CPX02، نشان می‌داد؛ هرچند این مقدار در locationهای Singapore و US بسیار کمتر بود و CPX02 در Singapore فقط 0.5 TB دریافت می‌کرد.

سه جزئیات ساختاری از اعداد اصلی مهم‌تر هستند. ترافیک ورودی در هر چهار ارائه‌دهنده رایگان است؛ بنابراین فقط داده‌ای که ارسال می‌کنید محاسبه می‌شود. DigitalOcean، Akamai و Vultr این سهمیه را میان تمام سرورهای حساب تجمیع می‌کنند. در نتیجه، یک ماشین پرترافیک می‌تواند سهمیه ماشین دیگری را مصرف کند و مجموعه‌ای از سرورهای کوچک از یک pool بزرگ مشترک استفاده می‌کند. همچنین ترافیک میان سرورها از طریق private network یا VPC معمولاً اصلاً محاسبه نمی‌شود. به همین دلیل، قرار دادن database روی interface خصوصی علاوه بر تصمیم امنیتی، یک تصمیم مربوط به صورتحساب نیز هست.

اگر حتی به سقف سهمیه نزدیک نباشید، هیچ‌کدام از این موارد اهمیت ندارد. یک blog، یک API با پاسخ‌های JSON یا یک SaaS کوچک در یک ماه به 1 TB نمی‌رسد. Video، galleryهای تصویر، game serverها، mirrorهای package و مقصدهای backup خارج از سایت به این مقدار می‌رسند. پیش از فرض‌کردن، اندازه‌گیری کنید:

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

vnstat -m ترافیک را به‌صورت ماهانه و در دو بخش received و transmitted چاپ می‌کند. فقط ستون transmitted صورتحساب دارد. database در ابتدا خالی است؛ بنابراین نخستین خوانش مفید یک روز پس از نصب آن به دست می‌آید و نخستین ماه کامل نیز یک ماه بعد ثبت می‌شود. تا آن زمان، graph پهنای‌باند خود provider تنها سابقه‌ای است که در اختیار دارید.

یک پرسش دیگر را مطرح کنید که هیچ price listی به آن پاسخ نمی‌دهد: پس از عبور از سهمیه، provider برای شما صورتحساب صادر می‌کند یا port را throttle می‌کند؟ صورتحساب هزینه مالی دارد. Throttling به کاربران آسیب می‌زند؛ دقیقاً در زمانی که بیشترین تعداد کاربر را دارید. باید بدانید یک spike ترافیکی، کدام‌یک از این دو پیامد را برای شما ایجاد می‌کند.

NVMe یا SATA، و نحوه بررسی آنچه واقعاً در اختیار دارید

پنل کاربری عبارت NVMe را نمایش می‌دهد. این ادعایی درباره دیسک‌های موجود در میزبان (host) است و ممکن است ماشین مجازی شما لزوماً روی آن‌ها قرار نداشته باشد. فضای ذخیره‌سازی محلی (Local storage)، دیسک مجازی شما را روی درایوهای داخل همان ماشین فیزیکی قرار می‌دهد. فضای ذخیره‌سازی شبکه‌ای (Network storage)، آن را روی یک کلاستر ذخیره‌سازی مجزا قرار می‌دهد که از طریق شبکه دیتاسنتر در دسترس است؛ همین ویژگی است که تغییر اندازه آنی، مهاجرت زنده (live migration) و اسنپ‌شات در محل را ممکن می‌سازد.

در داخل سیستم‌عامل مهمان (guest)، هر دو یکسان به نظر می‌رسند:

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

دستورات ROTA و rotational برای هر چیزی که میزبان آن را غیرچرخشی (non-rotational) اعلام کند، مقدار 0 را گزارش می‌دهند؛ بنابراین یک حجم شبکه‌ای که توسط NVMe پشتیبانی می‌شود، دقیقاً همان چیزی را گزارش می‌دهد که یک NVMe محلی گزارش می‌دهد. این مقدار فقط به شما می‌گوید که دیسک از نوع دیسک‌های چرخان (HDD) نیست. این مقدار نمی‌تواند به شما بگوید که دیسک در کجا قرار دارد. تأیید دیسک NVMe در لینوکس نام دستگاه‌ها و معنای هر کدام را بررسی می‌کند.

آزمونی که این دو را از هم متمایز می‌کند، تأخیر (latency) در عمق صف (queue depth) 1 است، زیرا یک عملیات خواندن کوچک و تکی، چیزی برای پنهان کردن ندارد. NVMe محلی از داخل همان شاسی پاسخ می‌دهد. یک حجم شبکه‌ای، یک رفت‌وبرگشت در شبکه دیتاسنتر را به هر عملیات خواندن اضافه می‌کند، بنابراین کف تأخیر آن بالاتر است، حتی اگر نرخ انتقال داده (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

اجرای اول یک بلوک clat چاپ می‌کند که نشان‌دهنده تأخیر تکمیل عملیات است. به جای میانگین، خط مربوط به صدک 99 (99th percentile) را بخوانید، زیرا میانگین، وقفه‌هایی که کاربران حس می‌کنند را پنهان می‌کند. اجرای دوم در خط خلاصه خود IOPS= را چاپ می‌کند. هر دو آزمون را روی ارائه‌دهنده‌ای که دارید و روی یک نمونه آزمایشی از ارائه‌دهنده‌ای که در نظر دارید، در همان روز اجرا کنید و دو عدد به‌دست‌آمده را با هم مقایسه کنید. ارقام منتشرشده توسط هر فروشنده، روی ماشینی اندازه‌گیری شده است که شما به آن دسترسی ندارید. همچنین آزمون را سه بار در ساعات مختلف اجرا کنید، زیرا یک میزبان خلوت و یک میزبان شلوغ در همان پلن، پاسخ‌های متفاوتی می‌دهند. بنچمارک صحیح یک VPS روش انجام این کار را پوشش می‌دهد و معنای واقعی SSD VPS به بررسی اصطلاحات بازاریابی پشت این عبارت می‌پردازد.

مناطق: تأخیر را اندازه بگیرید، به نقشه نگاه نکنید

فهرست مناطق تا زمانی که آن را اندازه‌گیری نکنید، صرفاً یک ابزار بازاریابی است. آنچه کاربر حس می‌کند، زمان رفت و برگشت (round trip) از شبکه خود به سرور شماست و این موضوع به مسیری که بسته‌ها طی می‌کنند بستگی دارد، نه به فاصله روی نقشه. سروری که در فاصله 300 کیلومتری قرار دارد اما پشت یک لینک ترانزیت پرترافیک است، عملکرد ضعیف‌تری نسبت به سروری در فاصله 1,500 کیلومتری با یک مسیر خلوت دارد.

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) را به همراه میزان اتلاف و تأخیر آن چاپ می‌کند؛ بنابراین یک پرش 60 میلی‌ثانیه‌ای بین دو گام، به جای مقصر دانستن مقصد، لینکی که باعث مشکل شده است را مشخص می‌کند. این دستور را از ماشینی در همان شبکه‌ای که کاربران شما در آن هستند اجرا کنید. مسیرهای بین دیتاسنترها بهترین مسیرهای اینترنت هستند و عملکرد همه ارائه‌دهندگان را به یک اندازه مطلوب نشان می‌دهند.

یک نکته ساختاری وجود دارد که از هر تغییر قیمتی مهم‌تر است. ارائه‌دهنده‌ای که تنها یک منطقه در قاره شما دارد، به این معناست که طرح بازیابی فاجعه (disaster recovery) شما، طرحی برای جابه‌جایی بین قاره‌هاست که تأخیرهای خاص خود را به همراه دارد. مناطقی را بشمارید که واقعاً می‌توانید به آن‌ها failover کنید، نه مناطقی که در صفحه وب لیست شده‌اند.

اسنپ‌شات‌ها و بک‌آپ‌ها هزینه‌ای جداگانه دارند

افزونه‌های ذخیره‌سازی همان بخشی هستند که یک پلن ارزان را گران می‌کنند. DigitalOcean برای اسنپ‌شات‌ها ماهانه 0.06 دلار به ازای هر GiB دریافت می‌کند و قیمت بک‌آپ‌های خودکار را به صورت درصدی از قیمت سرور محاسبه می‌کند: 20 درصد قیمت پلن برای بک‌آپ‌های هفتگی، 30 درصد برای روزانه، و یک گزینه مبتنی بر مصرف که بر اساس GiB صورت‌حساب می‌شود. هر دو مدل قابل دفاع هستند اما در جهت‌های مخالف شکست می‌خورند. قیمت درصدی با اندازه سرور مقیاس می‌شود، بنابراین یک سرور بزرگ که داده‌های کمی را نگهداری می‌کند، هزینه اضافی می‌پردازد. قیمت به ازای GiB با حجم داده‌های شما مقیاس می‌شود، بنابراین یک سرور کوچک که به یک Volume بزرگ متصل است، هزینه اضافی می‌پردازد.

بپرسید که بازیابی (restore) چقدر هزینه دارد و چقدر زمان می‌برد، زیرا هزینه نگهداری بک‌آپ، نیمه خسته‌کننده ماجراست. بپرسید که آیا حذف سرور باعث حذف اسنپ‌شات‌های آن نیز می‌شود یا خیر.

سپس یک نسخه کپی نزد خود نگه دارید که ارائه‌دهنده کنترلی روی آن ندارد. اسنپ‌شات‌های ارائه‌دهنده درون حساب کاربری همان ارائه‌دهنده قرار دارند، بنابراین از دست رفتن دسترسی به حساب، عدم پرداخت صورت‌حساب یا تعلیق حساب، سرور و بک‌آپ‌های آن را هم‌زمان از بین می‌برد. بک‌آپ‌های restic در فضای ذخیره‌سازی تحت مالکیت شما تنها چند دلار هزینه فضای ذخیره‌سازی شیء (object storage) دارند، روی هر ارائه‌دهنده‌ای قابل بازیابی هستند و همان چیزی هستند که مهاجرت را به جای یک اقدام نهایی، به یک فرآیند برگشت‌پذیر تبدیل می‌کنند.

چه بخشی از پشته (stack) را می‌خواهید اجرا کنید

ارائه‌دهندگان خدمات در یک طیف قرار دارند. در یک سوی این طیف، شما یک ماشین اجاره می‌کنید و همه چیز را خودتان روی آن اجرا می‌کنید. در سوی دیگر، شما یک branch از git را push می‌کنید و هرگز سروری را نمی‌بینید. مقایسه قیمت به ازای هر GB رم فقط در انتهای اول طیف منطقی است، زیرا در انتهای دوم، شما در حال خرید «نیروی کار» هستید نه «حافظه»، و نیروی کار قیمت مشخصی به ازای هر GB ندارد.

پیش از هرگونه مقایسه‌ای، صادقانه مشخص کنید که در کدام سوی این طیف قرار دارید. یک دیتابیس مدیریت‌شده با قیمت 15.15 دلار در ماه، در مقایسه با یک سرور 6 دلاری گران به نظر می‌رسد، مگر اینکه هزینه‌ ساعت‌های کاری پشت آن را محاسبه کنید: replication، failover، بازیابی در لحظه (point in time restore)، ارتقای نسخه‌های جزئی و هشداری که ساعت 03:00 صبح کسی را بیدار می‌کند. اگر انجام این کارها شغل شماست، آن را خودتان اجرا کنید و مابه‌التفاوت هزینه را حفظ کنید. اگر شغل شما توسعهٔ اپلیکیشن است، خرید این خدمات ارزان تمام می‌شود. تفکیک خدمات مدیریت‌شده و مدیریت‌نشده تعیین می‌کند که اصلاً باید کدام ستون از لیست قیمت‌ها را بخوانید. اگر پاسخ صادقانه این است که می‌خواهید کل ماشین و دیسک‌های آن را در اختیار خود داشته باشید، این یک پرسش در مورد تفاوت VPS و سرور اختصاصی است تا پرسشی درباره انتخاب ارائه‌دهنده. همین پرسش در سایر بخش‌های صورت‌حساب ماهانه یک توسعه‌دهنده نیز مطرح می‌شود؛ جایی که مقایسه پلن‌های Claude و ChatGPT بیش از آنکه به قیمت اسمی وابسته باشد، به این بستگی دارد که چه مقدار از کار را می‌خواهید به سرویس‌دهنده واگذار کنید.

چه زمانی DigitalOcean انتخاب درستی است

DigitalOcean زمانی برنده است که شما در حال خرید یک پلتفرم هستید، نه صرفاً یک ماشین مجازی.

• پایگاه‌داده‌های مدیریت‌شده. سرویس‌های مدیریت‌شده PostgreSQL و MySQL با قیمت پایه 15.15 دلار در ماه برای 1 GiB رم و 10 GiB فضای ذخیره‌سازی ارائه می‌شوند؛ فضای ذخیره‌سازی اضافی بر اساس هر GiB و گره‌های آماده‌به‌کار (standby nodes) بر اساس هر گره محاسبه می‌شوند. پیاده‌سازی چنین پایداری توسط خودتان، مستلزم استفاده از Patroni یا repmgr، یک consensus store، یک connection proxy و تمرین‌های failover است که واقعاً آن‌ها را تست کرده باشید. یک تیم دونفره نمی‌تواند هم‌زمان این زیرساخت را نگهداری کند و قابلیت‌های جدید ارائه دهد.
• App Platform. یک branch را push کنید تا بیلد، گواهی و سرویس در حال اجرا دریافت کنید؛ بدون آنکه نیاز باشد سیستم‌عاملی را وصله (patch) کنید. نسخه ارزان‌قیمت VPS برای این کار، خودِ شما هستید که باید روز شنبه وقت بگذارید.
• ذخیره‌سازی شیء (Object storage) و لود بالانسرهایی که توسط یک Terraform provider بالغ پشتیبانی می‌شوند. مجموعه‌ای که بتوانید آن را از طریق کد تخریب و بازسازی کنید، ارزشمندتر از قیمت واحد پایین‌تر است.
• شرکت پشتیبان محصول. سطوح پشتیبانی مشخص، صفحه وضعیت (status page) با تاریخچه، و سازمانی که به پرسشنامه‌های امنیتی مشتریان پاسخ می‌دهد. اگر خدمات میزبانی را بازفروش می‌کنید، این موارد بسیار ارزشمندتر از چند دلار اختلاف قیمت به ازای هر GB هستند.

جایی که DigitalOcean گران می‌شود، استفاده از ماشین مجازی ساده (plain virtual machine) در تعداد بالا و با ترافیک خروجی واقعی است. این دقیقاً همان موردی است که جایگزین‌ها آن را حل می‌کنند و بخش عمده‌ای از چیزی است که یک توسعه‌دهنده self-hosting خریداری می‌کند.

مهاجرت به ارائه‌دهنده جدید بدون قطعی سرویس

قطعی سرویس در طول مهاجرت تنها یک دلیل دارد: رسیدن ترافیک به IP قدیمی پس از انتقال داده‌ها به سرور جدید. تمام مراحل زیر برای کوتاه و قابل‌پیش‌بینی کردن این بازه زمانی طراحی شده‌اند.

کار را با DNS، حداقل 48 ساعت پیش از جابه‌جایی شروع کنید. Resolverها رکورد A شما را به اندازه مقدار TTL (زمان زنده ماندن) کش می‌کنند؛ بنابراین رکوردی با TTL 24 ساعته، کاربران را تا یک روز پس از تغییر، همچنان به سرور قدیمی هدایت می‌کند. کاهش TTL در لحظه تغییر (cutover) کمکی نمی‌کند، زیرا Resolverها مقدار قدیمی را با تاریخ انقضای قبلی در حافظه دارند. ابتدا TTL را کاهش دهید، منتظر بمانید تا مقدار قبلی منقضی شود، سپس مهاجرت کنید.

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

دستور اول، TTL فعلی را در ستون دوم پاسخ چاپ می‌کند. آن را در پنل ارائه‌دهنده DNS خود روی 300 تنظیم کنید و سپس بیش از عددی که جایگزین کردید، منتظر بمانید.

سپس به این ترتیب عمل کنید:

1. سرور جدید را آماده‌سازی و پیش از قرار دادن هر چیزی روی آن، ایمن‌سازی (harden) کنید. ده دقیقه اول روی یک VPS جدید به بخش‌هایی می‌پردازد که افراد هنگام عجله از آن غافل می‌شوند.
2. پشته نرم‌افزاری (application stack) را نصب کنید و اولین مرحله کپی داده‌ها را با rsync انجام دهید، در حالی که سرور قدیمی همچنان به سرویس‌دهی عادی خود ادامه می‌دهد.
3. گواهی TLS را اکنون روی میزبان جدید صادر کنید. از چالش DNS-01 استفاده کنید، زیرا چالش HTTP-01 بر اساس IP که DNS در حال حاضر به آن اشاره می‌کند (یعنی همان سرور قدیمی) اعتبارسنجی می‌شود. چالش DNS-01 این مشکل ترتیب را به‌طور کامل برطرف می‌کند.
4. پیش از هر تغییر عمومی، میزبان جدید را با override کردن DNS در لپ‌تاپ خود تست کنید. خطی را به 203.0.113.20 example.com اضافه کنید که به /etc/hosts اشاره کند، سایت را مرور کنید و سپس آن خط را حذف کنید. هیچ کاربری تحت تأثیر این تست قرار نمی‌گیرد.
5. مسئله حجم دیتابیس را مدیریت کنید. برای حجم‌های زیر چند گیگابایت، dump و restore در بازه زمانی توقف نوشتن (write freeze) جای می‌گیرد. برای حجم‌های بالاتر، از چند روز قبل replication را از دیتابیس قدیمی به جدید راه‌اندازی کنید تا همگام‌سازی شود و توقف نوشتن فقط محدود به مرحله نهایی (promotion) باشد.
6. نوشتن را متوقف کنید. برنامه را در حالت maintenance یا read-only قرار دهید. این تنها بخشی است که کاربران می‌بینند و باید فقط چند دقیقه طول بکشد.
7. آخرین delta را اجرا کنید: دوباره همان rsync و سپس همگام‌سازی نهایی دیتابیس.
8. رکوردهای A و AAAA را به IP جدید تغییر دهید. با TTL 300 ثانیه‌ای، اکثر Resolverها ظرف حدود پنج دقیقه تغییر را اعمال می‌کنند.
9. سرور قدیمی را حداقل تا یک روز روشن و در دسترس نگه دارید، زیرا برخی Resolverها TTLهای کوتاه را نادیده می‌گیرند. اگر برنامه قدیمی همچنان قابلیت نوشتن داشته باشد، درخواست‌های دیرهنگام در دیتابیس اشتباه نوشته می‌شوند؛ بنابراین میزبان قدیمی را به دیتابیس جدید متصل کنید یا یک صفحه maintenance از آن نمایش دهید.
10. نرخ خطای سرور جدید را برای یک روز زیر نظر بگیرید، TTL را به مقدار عادی بازگردانید و سرور قدیمی را پس از یک هفته (به‌جای همان شب) حذف کنید.

عملیات کپی شامل دو دستور است که هر کدام دو بار اجرا می‌شوند. همگام‌سازی فایل‌ها:

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

-a مالکیت، مجوزها و زمان‌بندی‌ها را حفظ می‌کند، -H لینک‌های سخت (hard links) را نگه می‌دارد، -AX ویژگی‌های ACL و extended attributes را حفظ می‌کند و --numeric-ids از نگاشت مجدد IDهای کاربری بر اساس نام‌هایی که بین دو ماشین متفاوت هستند، جلوگیری می‌کند. این دستور را از چند روز قبل اجرا کنید و سپس در طول توقف نوشتن دوباره تکرار کنید تا فقط موارد تغییریافته منتقل شوند.

برای PostgreSQL که حجم آن برای 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 انجام می‌دهد، بنابراین نتیجه یکپارچه است و برنامه در حین اجرا همچنان می‌تواند بنویسد. بدون این فلگ، mysqldump جداول را قفل می‌کند، به این معنی که توقف نوشتن شما زودتر از برنامه‌ریزی شروع شده و شما زمان آن را انتخاب نکرده‌اید.

دو مورد خارج از سرورهای شما ممکن است مشکل‌ساز شوند. یک IP جدید هیچ اعتبار ایمیلی (reputation) ندارد، بنابراین ایمیل‌هایی که مستقیماً از سرور جدید ارسال می‌شوند به عنوان اسپم فیلتر می‌شوند: از طریق یک relay که اعتبار دارد ارسال کنید. همچنین، هر شریکی که IP خروجی شما را در لیست سفید (allowlist) قرار داده است، مانند درگاه پرداخت یا فایروال مشتری، باید پیش از تغییر نهایی به‌روزرسانی شود، در غیر این صورت به محض جابه‌جایی ترافیک، آن ارتباطات با شکست مواجه می‌شوند.

مواردی که باید پیش از نهایی‌کردن خرید بررسی کنید

• آیا طرح مورد نظر در موقعیت جغرافیایی دلخواه شما، همین امروز قابل سفارش است یا خیر. طرحی که در لیست قیمت‌ها به عنوان «غیرقابل دسترس» علامت‌گذاری شده، حتی اگر قیمت هر گیگابایت آن بسیار جذاب باشد، گزینه‌ای برای انتخاب نیست.
• آیا قیمت ارائه شده تبلیغاتی است و پس از پایان دوره با چه نرخی تمدید می‌شود. تخفیف‌های دوره اول که در زمان تمدید دوبرابر می‌شوند، در واقع همان هزینه اصلی هستند که فقط به تعویق افتاده‌اند.
• آیا هزینه دوره به صورت پیش‌پرداخت است. طرح‌های پیش‌پرداخت چندساله، که روش فروش SSD Nodes است، قیمت بسیار پایین‌تری به ازای هر گیگابایت رم در ازای پرداخت نقدی اولیه ارائه می‌دهند. نکته اینجاست که شما نمی‌توانید ماه بعد سرویس را رها کنید، بنابراین طول دوره را با میزان اطمینان خود از پایداری نیازتان هماهنگ کنید.
• هزینه ماهانه هر snapshot چقدر است و بازیابی آن چقدر هزینه و زمان می‌برد.
• آیا مصرف بیش از حد (overage) شامل هزینه اضافی می‌شود یا سرعت شما محدود (throttle) خواهد شد.
• آیا IPv6 به درستی مسیریابی شده است یا صرفاً یک آدرس منفرد است که به سرور متصل شده است.
• اگر قصد دارید زیرساخت را به جای تنظیم دستی، از طریق کد بازسازی کنید، آیا API با یک Terraform provider به‌روز وجود دارد یا خیر.
• نحوه دسترسی به پشتیبانی چگونه است و زمان پاسخ‌گویی اعلام‌شده برای سروری که از دسترس خارج شده (نه برای سوالات فروش) چقدر است.

بر اساس فاکتوری که بیشترین سهم را در صورت‌حساب شما دارد، تصمیم بگیرید. اگر این فاکتور حافظه است، قیمت هر گیگابایت رم تعیین‌کننده است. اگر ترافیک خروجی است، حجم انتقال داده گنجانده‌شده در طرح تعیین‌کننده است. اگر زمان شما ارزشمندتر است، پلتفرم‌های مدیریت‌شده (managed) اولویت دارند و در مقایسه چهار سرویس‌دهنده اینجا، DigitalOcean قوی‌ترین عملکرد را دارد.

FAQ

آیا Hetzner همیشه ارزان‌تر از DigitalOcean است؟

برای یک ماشین مجازی ساده، قیمت هر GB از RAM در آن بسیار کمتر بود: در پلن‌های اشتراکی کوچک، در تاریخ 5 August 2026 حدود $1.62 در برابر $6.00. این رقم مربوط به CX23 بود که Hetzner در تاریخ 21 October 2026 آن را، همراه با باقی خط Cost-Optimized و CPX02 جدید، در وضعیت unavailable فهرست کرده بود؛ بنابراین مقایسه را با پلنی انجام دهید که امروز واقعاً بتوانید سفارش دهید. وقتی managed services را هم وارد مقایسه می‌کنید، نتیجه تغییر می‌کند. Hetzner سرور و networking ارائه می‌دهد؛ بنابراین managed database یا پلتفرم push-to-deploy باید توسط خودتان یا یک شخص ثالث فراهم شود و هزینه این ساعت‌ها نیز باید در نظر گرفته شود. Hetzner همچنین در طول 2026 قیمت‌های cloud را افزایش داد؛ بنابراین به‌جای اعتماد به مقاله‌ای قدیمی، رقم فعلی به یورو را بررسی کنید.

اگر به managed database نیاز داشته باشم، کدام جایگزین DigitalOcean را انتخاب کنم؟

Vultr و Akamai هر دو managed database ارائه می‌دهند؛ بنابراین اگر دلیل اصلی استفاده شما از DigitalOcean داشتن managed database است، این دو نزدیک‌ترین جایگزین‌ها هستند. میزبان‌های کم‌هزینه اروپایی معمولاً چنین سرویسی ارائه نمی‌دهند. در نتیجه باید PostgreSQL یا MySQL را خودتان اجرا کنید و replication و failover آزمایش‌شده را نیز مدیریت کنید. این کار واقعاً زمان‌بر است. پیش از آن‌که نتیجه بگیرید سرور ارزان‌تر هزینه‌ای برای شما ذخیره کرده است، هزینه آن را با $15.15 در ماه برای یک instance مدیریت‌شده 1 GiB مقایسه کنید.

چگونه یک سایت فعال را بدون downtime به provider جدید منتقل کنم؟

حداقل 48 ساعت پیش از انتقال، DNS TTL را به 300 ثانیه کاهش دهید؛ زیرا resolverها تا مدتی که TTL قبلی تعیین کرده است، IP قدیمی را ارائه می‌کنند. تا زمانی که سرور قدیمی همچنان traffic را ارائه می‌دهد، host جدید را راه‌اندازی و آزمایش کنید. برای این کار روی ماشین خودتان از override نوع /etc/hosts استفاده کنید تا افراد دیگر آن را نبینند. سپس برای چند دقیقه writeها را متوقف کنید، delta نهایی را با rsync اجرا کنید و sync نهایی database را انجام دهید، رکوردهای A و AAAA را تغییر دهید و سرور قدیمی را به‌مدت یک هفته روشن نگه دارید؛ چون ممکن است یک resolver کوتاه‌شدن TTL را نادیده گرفته باشد.

آیا VPS ارزان‌تر به معنی دیسک‌های کندتر است؟

نه، لزوماً. عامل مهم این است که virtual disk شما روی خود host قرار دارد یا روی یک network storage cluster؛ panel نیز به‌ندرت این موضوع را اعلام می‌کند. lsblk -o NAME,ROTA برای هر دو مورد 0 را گزارش می‌کند، زیرا هر دو non-rotational هستند. در عوض اندازه‌گیری کنید: fio را با --iodepth=1 --bs=4k --direct=1 اجرا کنید و latency تکمیل در صدک 99 را بخوانید. یک network volume برای هر read، یک رفت‌وبرگشت در شبکه datacentre اضافه می‌کند؛ بنابراین حتی اگر throughput در صف‌های عمیق مشابه به نظر برسد، کف latency آن از NVMe محلی بالاتر است.

آیا email من همچنان از سرور جدید تحویل داده می‌شود؟

اغلب در ابتدا نه. IP جدید سابقه ارسال ندارد؛ بنابراین گیرنده‌ها email ارسالی از آن را مشکوک تلقی می‌کنند و پیام در spam قرار می‌گیرد یا مستقیماً رد می‌شود. رکوردهای SPF و DKIM نیز تا زمانی که آن‌ها را به‌روزرسانی نکنید، به host قدیمی اشاره می‌کنند. email برنامه را از طریق یک relay یا email serviceای ارسال کنید که از قبل reputation دارد و رکوردهای DNS مربوط به mail را پیش از cutover به‌روزرسانی کنید، نه پس از آن.