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

جایگزین‌های DigitalOcean واقعاً چه چیزی را تغییر می‌دهند

بیشتر جایگزین‌های DigitalOcean صورت‌حساب را تغییر می‌دهند، نه ماشین را. در هر صورت، شما یک ماشین مجازی لینوکس با IP عمومی، دیسک virtio و دسترسی root دریافت می‌کنید و هسته سیستم‌عامل شما اهمیتی نمی‌دهد که لوگوی چه شرکتی روی پنل مدیریت است. تفاوت‌هایی که تعیین‌کننده انتخاب هستند عبارتند از: قیمت به ازای هر گیگابایت RAM، حجم ترافیک مجاز گنجانده‌شده و هزینه هر بایت اضافه بر آن، نوع واقعی دیسک، و اینکه چه بخشی از پشته (stack) بالاتر از سیستم‌عامل را شخص دیگری برای شما مدیریت می‌کند.

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

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

قیمت به ازای هر گیگابایت رم، معیار اصلی مقایسه است

[
  {
    "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"
  }
]

در یک ارائه‌دهندهٔ واحد، قیمت به ازای هر گیگابایت رم تغییر چندانی نمی‌کند. DigitalOcean برای پلن 1 گیگابایتی مبلغ $6.00 به ازای هر گیگابایت و برای پلن 4 گیگابایتی که قیمت ماهانهٔ آن $24.00 است، همان مبلغ $6.00 را دریافت می‌کند. انتخاب پلن بزرگ‌تر در همان ارائه‌دهنده تخفیفی به همراه ندارد، بنابراین اندازهٔ پلن عامل تصمیم‌گیری نیست؛ بلکه خودِ ارائه‌دهنده است که اهمیت دارد.

شرکت Akamai که اکنون مالک سرویس‌های سابق Linode است، پلن‌های اشتراکی 2 و 4 گیگابایتی خود را با قیمت‌های 12 و 24 دلار عرضه می‌کند که دقیقاً با قیمت‌های DigitalOcean برابر است. پلن پایهٔ این شرکت با قیمت $5.00 ارزان‌تر از آن‌هاست. اینکه دو شرکت قیمت‌های خود را دقیقاً با یکدیگر هماهنگ می‌کنند، نشانه‌ای است که باید به آن توجه کرد: این سطح از قیمت‌گذاری بر اساس رقابت با رقیب تعیین شده است، نه بر اساس هزینهٔ سخت‌افزار، و این روند در آینده نیز با همان رقیب ادامه خواهد یافت.

شکاف قیمتی زمانی ایجاد می‌شود که به سراغ ارائه‌دهندگانی برویم که دیتاسنترهای اختصاصی خود را دارند و به یورو می‌فروشند. سرویس Hetzner CX23 به شما 4 گیگابایت رم با هزینهٔ تقریبی $6.49 در ماه می‌دهد که معادل $1.62 به ازای هر گیگابایت است؛ یعنی نزدیک به یک‌چهارم نرخ DigitalOcean. این رقم دلاری از قیمت لیست‌شده به یورو تبدیل شده است، بنابراین با نوسانات نرخ ارز تغییر می‌کند. همچنین Hetzner در طول سال 2026 قیمت‌های ابری خود را افزایش داد، بنابراین پست‌های مقایسه‌ای قدیمی، اعدادی را ذکر می‌کنند که دیگر معتبر نیستند.

قیمت به ازای هر گیگابایت رم، هیچ اطلاعاتی دربارهٔ CPU دریافتی به شما نمی‌دهد. vCPU اشتراکی به این معناست که هایپروایزر (hypervisor)، هستهٔ پردازشی شما را با سایر مستأجران به اشتراک می‌گذارد. برای بررسی دقیق عملکرد، باید این تست را روی سروری که اجاره کرده‌اید اجرا کنید:

vmstat 1 10

ستون st را بخوانید. این ستون درصد زمانی را نشان می‌دهد که vCPU شما آمادهٔ اجرا بوده اما هایپروایزر هستهٔ فیزیکی را به شخص دیگری اختصاص داده است. چند درصد در زمان بار کاری، طبیعی است. عدد دورقمی پایدار به این معناست که میزبان بیش از حد ظرفیت (oversubscribed) فروخته است و هیچ قیمت ارزانی برای هر گیگابایت رم، نمی‌تواند کمبود هسته‌ای که به آن دسترسی ندارید را جبران کند. این بررسی را در ساعات اوج مصرف انجام دهید، زیرا steal time مشکلی ناشی از همسایگی است و همسایه‌ها نیز برنامه‌های کاری خود را دارند. برای درک کلی از اینکه هزینهٔ واقعی یک ماه میزبانی پس از افزودن فضای ذخیره‌سازی و ترافیک چقدر است، هزینهٔ ماهانهٔ یک VPS را مطالعه کنید.

هزینه واقعی انتقال داده‌های گنجانده‌شده

[
  {
    "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 مقدار 1 ترابایت انتقال داده خروجی را در پلن پایه خود ارائه می‌دهد و برای مازاد آن بر اساس GiB هزینه دریافت می‌کند که تقریباً معادل 10.00 دلار به ازای هر ترابایت اضافه است. سرویس Akamai همین مقدار ترابایت را ارائه می‌دهد و تقریباً نصف این مبلغ، یعنی حدود 5.00 دلار به ازای هر ترابایت، هزینه دریافت می‌کند. سرویس Vultr مقدار 2 ترابایت را با نرخ مازاد مشابه ارائه می‌دهد. سرویس Hetzner مقدار 20 ترابایت را ارائه کرده و پس از آن حدود 1.20 دلار به ازای هر ترابایت هزینه دریافت می‌کند که یک مرتبه بزرگی با سایرین تفاوت دارد.

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

اگر مصرف شما به سقف تعیین‌شده نزدیک نیست، هیچ‌کدام از این موارد اهمیتی ندارد. یک وبلاگ، یک API با پاسخ‌های JSON یا یک سرویس SaaS کوچک در طول یک ماه به 1 ترابایت نمی‌رسند. اما ویدیو، گالری‌های تصاویر، سرورهای بازی، آینه‌های بسته‌های نرم‌افزاری و مقاصد پشتیبان‌گیری خارج از سایت، به این سقف می‌رسند. پیش از هرگونه فرض، اندازه‌گیری کنید:

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

vnstat -m میزان انتقال داده را به تفکیک ماه، به صورت دریافتی و ارسالی نمایش می‌دهد. تنها ستون ارسالی مشمول هزینه است. دیتابیس در ابتدا خالی است، بنابراین اولین داده مفید یک روز پس از نصب و اولین گزارش کامل یک ماه بعد در دسترس خواهد بود. تا آن زمان، نمودار پهنای باند خودِ ارائه‌دهنده، تنها سابقه موجود شماست.

یک سوال دیگر بپرسید که در هیچ لیست قیمتی پاسخ داده نشده است: وقتی از سهمیه عبور می‌کنید، آیا ارائه‌دهنده از شما هزینه دریافت می‌کند یا پورت را محدود (Throttle) می‌کند؟ صورت‌حساب هزینه مالی دارد. محدود کردن سرعت، هزینه کاربری دارد؛ دقیقاً در لحظه‌ای که بیشترین کاربر را دارید. باید بدانید که یک جهش ترافیکی، کدام‌یک از این دو نتیجه را برای شما به همراه خواهد داشت.

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 است، قیمت بسیار کمتری به ازای هر GB رم در ازای پرداخت نقدی اولیه ارائه می‌دهند. نکتهٔ منفی این است که نمی‌توانید ماه بعد سرویس را رها کنید؛ بنابراین طول دوره را با میزان اطمینان خود از پایداری نیازتان بسنجید.
• بررسی کنید هزینهٔ هر snapshot در ماه چقدر است و بازیابی آن چقدر هزینه و زمان می‌برد.
• بررسی کنید که آیا مصرف بیش از حد (overage) شامل هزینهٔ اضافی می‌شود یا سرعت شما محدود (throttle) خواهد شد.
• بررسی کنید که آیا IPv6 به‌درستی مسیریابی می‌شود یا صرفاً یک آدرس منفرد است که به سرور متصل شده است.
• اگر قصد دارید زیرساخت را به‌جای روش دستی، از طریق کد بازسازی کنید، بررسی کنید که آیا API با یک Terraform provider فعال و نگهداری‌شده وجود دارد یا خیر.
• بررسی کنید که پشتیبانی چگونه در دسترس است و زمان پاسخ‌گویی اعلام‌شده برای سروری که از دسترس خارج شده چقدر است (نه برای پرسش‌های فروش).

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

FAQ

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

برای یک ماشین مجازی ساده، هزینه به ازای هر گیگابایت رم بسیار کمتر است: حدود $1.62 در مقایسه با $6.00 در پلن‌های اشتراکی پایه تا تاریخ 5 آگوست 2026. این مقایسه با ورود سرویس‌های مدیریت‌شده تغییر می‌کند. Hetzner سرور و شبکه می‌فروشد، بنابراین یک دیتابیس مدیریت‌شده یا پلتفرم push-to-deploy باید توسط خود شما یا شخص ثالث تأمین شود و آن ساعات کاری هزینه دارند. Hetzner همچنین قیمت‌های ابری خود را در طول سال 2026 افزایش داده است، بنابراین به‌جای اعتماد به مقالات قدیمی، رقم فعلی را به یورو بررسی کنید.

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

Vultr و Akamai هر دو دیتابیس مدیریت‌شده می‌فروشند، بنابراین اگر دلیل اصلی حضور شما در DigitalOcean دیتابیس مدیریت‌شده است، این‌ها نزدیک‌ترین جایگزین‌ها هستند. میزبان‌های ارزان‌قیمت اروپایی معمولاً چنین سرویسی ندارند، که این یعنی باید PostgreSQL یا MySQL را خودتان مدیریت کنید، از جمله تنظیم replication و failover تست‌شده. این یک کار واقعی است. قبل از اینکه تصمیم بگیرید سرور ارزان‌تر برایتان صرفه اقتصادی داشته، هزینه آن را با 15.15 دلار در ماه که یک نمونه مدیریت‌شده 1 GiB هزینه دارد، مقایسه کنید.

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

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

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

لزوماً خیر. آنچه اهمیت دارد این است که دیسک مجازی شما محلی (local) است یا روی یک کلاستر ذخیره‌سازی شبکه قرار دارد، و پنل‌های مدیریتی به‌ندرت این موضوع را اعلام می‌کنند. lsblk -o NAME,ROTA برای هر دو مقدار 0 را گزارش می‌دهد، زیرا هر دو غیرچرخشی (non-rotational) هستند. در عوض اندازه‌گیری کنید: fio را با --iodepth=1 --bs=4k --direct=1 اجرا کنید و تأخیر تکمیل در صدک 99 (99th percentile) را بخوانید. یک volume شبکه برای هر خواندن، یک رفت‌وبرگشت در شبکه دیتاسنتر اضافه می‌کند، بنابراین کف تأخیر آن حتی زمانی که throughput صف‌های عمیق مشابه به نظر می‌رسد، بالاتر از NVMe محلی است.

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

اغلب در ابتدا خیر. یک آدرس IP جدید هیچ سابقه ارسالی ندارد، بنابراین گیرندگان ایمیل‌های آن را مشکوک تلقی می‌کنند و ایمیل‌ها به پوشه اسپم می‌روند یا مستقیماً رد می‌شوند. رکوردهای SPF و DKIM نیز تا زمانی که آن‌ها را به‌روزرسانی نکنید، به میزبان قدیمی اشاره می‌کنند. ایمیل‌های اپلیکیشن را از طریق یک relay یا سرویس ایمیلی که از قبل اعتبار دارد ارسال کنید و رکوردهای DNS مربوط به ایمیل را قبل از انتقال نهایی به‌روزرسانی کنید، نه بعد از آن.