חלופות ל-DigitalOcean: השוואת מחירים וביצועים למפתחים

מה משתנה באמת בחלופות ל-DigitalOcean

רוב החלופות ל-DigitalOcean משנות את החשבונית, לא את המכונה. בכל מקרה תקבלו מכונה וירטואלית מבוססת Linux עם כתובת IP ציבורית, כונן virtio וגישת root, וה-kernel שלכם לא "יודע" איזה לוגו מופיע בלוח הבקרה. ההבדלים שקובעים את הבחירה הם המחיר לכל GB של RAM, נפח התעבורה הכלול והעלות של כל byte חורג, ממה עשוי הכונן בפועל, וכמה משכבות ה-stack שמעל מערכת ההפעלה ספק השירות ינהל עבורכם.

מדריך זה משווה את הספקים על בסיס צירים אלו, כיוון שמפתח יכול לבדוק כל אחד מהם מתוך ה-terminal או מתוך מחירון מפורסם. המדריך מציין גם מקרים שבהם DigitalOcean היא התשובה הנכונה, שכן השוואה שאינה מודה בדבר היא פרסומת.

כל מחיר המופיע להלן הוא מחיר מחירון רשמי, שנבדק ב-5 באוגוסט 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",
    "ram_gb": 4,
    "monthly_usd": "6.49",
    "usd_per_gb_ram": "1.62"
  }
]

אצל ספק יחיד, המחיר לכל GB של RAM כמעט ואינו משתנה. DigitalOcean גובה $6.00 לכל GB בתוכנית של 1 GB, ואותו סכום של $6.00 לכל GB בתוכנית של 4 GB, שמחירה הרשמי הוא $24.00 לחודש. בחירה בתוכנית גדולה יותר אצל אותו ספק אינה מעניקה הנחה, לכן גודל התוכנית אינו השיקול המכריע. הספק הוא השיקול.

Akamai, שמוכרת כעת את מה שהיה בעבר Linode, מתמחרת את התוכניות המשותפות של 2 GB ו-4 GB ב-$12 ו-$24, בדיוק כמו DigitalOcean. תוכנית הכניסה שלה זולה יותר ועומדת על $5.00. העובדה ששתי חברות מתמחרות את השירות שלהן באופן זהה היא סימן שחשוב להבין: השכבה הזו מתומחרת מול מתחרה, לא מול החומרה, והיא תמשיך לעקוב אחרי אותה מתחרה.

הפער נפתח אצל ספקים שבונים מרכזי נתונים משלהם ומוכרים באירו. שרת Hetzner CX23 מספק 4 GB של RAM תמורת כ-$6.49 לחודש, כלומר $1.62 לכל GB, קרוב לרבע מהתעריף של DigitalOcean. נתון הדולר הזה מומר ממחיר רשמי באירו, לכן הוא משתנה בהתאם לשער החליפין. Hetzner גם העלתה את מחירי הענן במהלך 2026, כך שפוסטים ישנים יותר להשוואת מחירים מצטטים מספרים שכבר אינם קיימים.

המחיר לכל GB של RAM אינו מעיד דבר על ה-CPU שתקבלו. vCPU משותף אומר שה-hypervisor מתזמן את הליבה שלכם מול דיירים אחרים, והבדיקה האמינה ביותר מתבצעת על השרת ששכרתם בפועל:

vmstat 1 10

עיינו בעמודה st. היא מודדת את אחוז הזמן שבו ה-vCPU שלכם היה מוכן לפעולה, אך ה-hypervisor העביר את הליבה הפיזית למישהו אחר. אחוזים בודדים תחת עומס הם תקינים. מספר דו-ספרתי מתמשך אומר שהמארח (host) עמוס מדי, ושום מחיר לכל GB לא יפצה על ליבה שאינכם יכולים לנצל. הריצו את הבדיקה בשעה העמוסה שלכם, כיוון שזמן גזול (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 TB של תעבורה יוצאת בתוכנית הבסיס ומחייבת על חריגה לפי GiB, מה שמתרגם לעלות של כ-10.00 דולר לכל TB נוסף. Akamai כוללת את אותו נפח TB ומחייבת בערך במחצית מהסכום, כ-5.00 דולר לכל TB. Vultr כוללת 2 TB בתעריף חריגה דומה. Hetzner כוללת 20 TB וגובה כ-1.20 דולר לכל TB מעבר לכך, פער של סדר גודל בהשוואה לאחרות.

שלושה פרטים מבניים חשובים יותר מהמספרים המוצהרים. תעבורה נכנסת היא בחינם אצל כל ארבע הספקיות, לכן רק מה שאתם שולחים החוצה נספר. DigitalOcean ו-Vultr מאחדות את המכסה לכל השרתים בחשבון, כך שמכונה עמוסה אחת צורכת את המכסה של מכונה אחרת, וצי של שרתים קטנים חולק מאגר אחד גדול. תעבורה בין שרתים ברשת פרטית או ב-VPC לרוב אינה נספרת כלל; זו הסיבה שהצבת מסד הנתונים על ממשק פרטי היא החלטה כלכלית לא פחות מאשר החלטה אבטחתית.

כל זה לא משנה אם אתם רחוקים מהמכסה. בלוג, API עם תגובות JSON או SaaS קטן לא יגיעו ל-1 TB בחודש. וידאו, גלריות תמונות, שרתי משחקים, מראות (mirrors) של חבילות ויעדי גיבוי מרוחקים יגיעו גם יגיעו. מדדו לפני שתניחו הנחות:

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

vnstat -m מציג את התעבורה לפי חודש, מחולקת לנכנסת ויוצאת. רק עמודת התעבורה היוצאת מחויבת בתשלום. מסד הנתונים מתחיל ריק, לכן הקריאה השימושית הראשונה תתקבל יום לאחר ההתקנה, והחודש המלא הראשון יתקבל כעבור חודש. עד אז, גרף רוחב הפס של הספק הוא התיעוד היחיד שעומד לרשותכם.

שאלו שאלה נוספת שאף מחירון לא עונה עליה: כאשר עוברים את המכסה, האם הספק מחייב אתכם בתשלום או מגביל (throttle) את רוחב הפס של הפורט. חיוב עולה כסף. הגבלה עולה במשתמשים, בדיוק ברגע שבו יש לכם הכי הרבה מהם. כדאי לדעת מה קורה בעת זינוק בתעבורה.

NVMe או SATA, ואיך לבדוק מה באמת קיבלתם

לוח הבקרה מציין NVMe. זוהי טענה לגבי הכוננים במארח, אך ייתכן שהמכונה הווירטואלית שלכם אינה יושבת עליהם. אחסון מקומי מציב את הדיסק הווירטואלי שלכם על כוננים בתוך אותה מכונה פיזית. אחסון רשתי מציב אותו על אשכול אחסון נפרד אליו מגיעים דרך רשת מרכז הנתונים, וזה מה שמאפשר שינוי גודל מיידי, העברה חיה (live migration) וצילומי מצב (snapshots) במקום.

בתוך המערכת האורחת, שניהם נראים זהים:

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

הפקודות ROTA ו-rotational מדווחות על 0 עבור כל מה שהמארח מצהיר עליו כלא-מסתובב (non-rotational), לכן נפח רשתי המגובה ב-NVMe מדווח בדיוק על מה ש-NVMe מקומי מדווח. הערך אומר לכם שהדיסק אינו פלטה מסתובבת. הוא אינו יכול לומר לכם היכן הדיסק נמצא. אימות דיסק NVMe בלינוקס עובר על שמות ההתקנים ועל המשמעות של כל אחד מהם.

הבדיקה שמבדילה ביניהם היא השהיה (latency) בעומק תור 1, מכיוון שלקריאה קטנה בודדת אין מה להסתיר מאחוריו. NVMe מקומי משיב מאותו מארז. נפח רשתי מוסיף הלוך-חזור דרך רשת מרכז הנתונים לכל קריאה בודדת, לכן רצפת ההשהיה שלו גבוהה יותר, גם כאשר קצב ההעברה שלו בעומק תור גבוה נראה דומה.

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 במקום את הממוצע, מכיוון שהממוצע מסתיר את העיכובים שהמשתמשים מרגישים. ההרצה השנייה מדפיסה IOPS= בשורת הסיכום שלה. הריצו את שניהם אצל הספק הנוכחי שלכם ועל מופע ניסיון של הספק שאתם שוקלים, באותו היום, והשוו בין שני המספרים שלכם. נתון שפורסם על ידי ספק כלשהו נמדד על מכונה שאינכם יכולים לראות. הריצו זאת שלוש פעמים בשעות שונות, מכיוון שמארח שקט ומארח עמוס נותנים תשובות שונות באותה תוכנית. ביצוע Benchmarking תקין ל-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 ms בין שתי תחנות מצביעה על הקישור הבעייתי במקום להאשים את היעד. הריצו את הבדיקה ממכונה שנמצאת ברשת של המשתמשים שלכם. נתיבים בין מרכזי נתונים הם הנתיבים הטובים ביותר באינטרנט, והם מציגים את כל הספקיות באור חיובי במידה שווה.

נקודה מבנית אחת נותרת רלוונטית ללא קשר לשינויי מחיר. ספקית עם אזור אחד בלבד ביבשת שלכם משמעותה שתוכנית ההתאוששות מאסון (disaster recovery) שלכם היא תוכנית למעבר יבשות, על כל השיהוי המשתמע מכך. ספרו את האזורים שבאמת תוכלו לבצע אליהם failover, לא את האזורים שמופיעים בדף השיווקי.

צילומי מצב (Snapshots) וגיבויים הם חיוב נפרד

תוספי אחסון הם המקום שבו תוכנית זולה הופכת ליקרה. DigitalOcean גובה 0.06$ לכל GiB בחודש עבור צילומי מצב, ומתמחרת את הגיבויים האוטומטיים שלה כחלק יחסי מהשרת: 20% ממחיר התוכנית עבור גיבויים שבועיים, 30% עבור יומיים, עם אפשרות מבוססת שימוש המחויבת לפי GiB. שני המודלים ניתנים להצדקה, אך הם נכשלים בכיוונים מנוגדים. מחיר באחוזים גדל עם גודל השרת, כך ששרת גדול שמחזיק מאגר נתונים קטן משלם יותר מדי. מחיר לכל GiB גדל עם כמות הנתונים שלך, כך ששרת קטן המחובר לנפח אחסון גדול משלם יותר מדי.

בררו מה העלות של שחזור וכמה זמן הוא לוקח, כיוון שהמחיר של החזקת גיבוי הוא החצי המשעמם של השאלה. בדקו האם מחיקת השרת מוחקת גם את צילומי המצב שלו.

לאחר מכן, שמרו עותק שהספק אינו שולט בו. צילומי מצב של הספק חיים בתוך חשבון הספק, כך שאובדן גישה לחשבון, כשל בתשלום או חשבון מושעה לוקחים איתם את השרת ואת הגיבויים שלו באותו רגע. גיבויי restic לאחסון שבבעלותך עולים דולרים בודדים של אחסון אובייקטים (object storage), מאפשרים שחזור לכל ספק, והם הדבר שהופך הגירה להפיכה במקום לסופית.

כמה משכבות ה-stack אתם רוצים לנהל בעצמכם

ספקי שירותים נמצאים על רצף. בקצה אחד אתם שוכרים מכונה ומריצים עליה הכל בעצמכם. בקצה השני אתם דוחפים branch של git ולעולם לא רואים שרת. השוואת מחיר ל-GB של RAM רלוונטית רק לקצה הראשון, כיוון שבקצה השני אתם קונים עבודה ולא זיכרון, ולעבודה אין מחיר לפי GB.

היו כנים לגבי המיקום שלכם על הרצף לפני שאתם משווים משהו. מסד נתונים מנוהל בעלות של $15.15 לחודש נראה יקר ליד שרת של $6, עד שמתמחרים את השעות שמאחוריו: שכפול (replication), התאוששות מכשל (failover), שחזור לנקודת זמן (point in time restore), שדרוגי גרסאות משניות, וההתראה שמעירה מישהו ב-03:00. אם העבודה הזו היא התפקיד שלכם, הריצו אותה בעצמכם וחסכו את ההפרש. אם התפקיד שלכם הוא היישום, קניית השירות בחזרה היא זולה. ההפרדה בין מנוהל ללא-מנוהל קובעת איזו עמודה במחירון אתם בכלל צריכים לקרוא. אם התשובה הכנה היא שאתם רוצים את כל המכונה והדיסקים שלה לעצמכם, זו שאלה של VPS לעומת שרת ייעודי ולא שאלה של ספק. אותה שאלה עולה בשאר החשבון החודשי של מפתח, שבו השוואה בין תוכניות Claude ל-ChatGPT תלויה בכמה מהעבודה אתם רוצים להעביר הלאה, ולא במחיר המוצהר.

מתי DigitalOcean היא הבחירה הנכונה

DigitalOcean מנצחת כאשר אתם קונים את הפלטפורמה במקום את המכונה הווירטואלית.

• מסדי נתונים מנוהלים. מסדי נתונים מנוהלים מסוג PostgreSQL ו-MySQL מתחילים ב-$15.15 לחודש עבור 1 GiB של RAM ו-10 GiB של אחסון, כאשר אחסון נוסף מחויב לפי GiB וצמתים במצב המתנה (standby nodes) מתומחרים לפי צומת. בנייה עצמית של אותה רמת אמינות דורשת שימוש ב-Patroni או ב-repmgr, מאגר קונסנזוס, proxy לחיבורים ותרגול failover שבאמת ביצעתם. צוות של שני אנשים לא יכול לתחזק מערכת כזו ובמקביל לפתח פיצ'רים.
• App Platform. דחיפת branch מובילה לביצוע build, הנפקת תעודה והרצת שירות, ללא צורך בעדכון מערכת הפעלה. הגרסה הזולה של מוצר זה ב-VPS היא אתם, ביום שבת.
• אחסון אובייקטים ו-load balancers הנתמכים על ידי ספק Terraform בוגר. לצי שרתים שניתן להשמיד ולבנות מחדש מתוך קוד יש ערך רב יותר מאשר למחיר יחידה נמוך יותר.
• החברה שמאחורי המוצר. רמות תמיכה מפורסמות, דף סטטוס עם היסטוריה, וארגון שיענה על שאלון אבטחה של לקוח. אם אתם משווקים שירותי אירוח, זה שווה הרבה יותר מכמה דולרים לכל GB.

הנקודה שבה DigitalOcean הופכת ליקרה היא המכונה הווירטואלית הפשוטה, בכמויות גדולות, עם תעבורה יוצאת משמעותית. זהו בדיוק המקרה שחלופה אחרת פותרת, וזהו רוב מה שמפתח שמבצע אירוח עצמי קונה.

מעבר לספק חדש ללא השבתה

השבתה במהלך הגירה נובעת מגורם אחד: תעבורה שמגיעה לכתובת ה־IP הישנה לאחר שהנתונים כבר הועברו לחדשה. כל שלב להלן נועד להפוך את חלון הזמן הזה לקצר וצפוי.

התחילו ב־DNS, לפחות 48 שעות לפני המעבר. שרתי DNS שומרים ב־cache את רשומת ה־A שלכם למשך זמן ה־TTL (זמן חיים) שלה. לכן, רשומה עם TTL של 24 שעות תמשיך להפנות משתמשים לשרת הישן עד יום שלם לאחר שתשנו אותה. הנמכת ה־TTL ברגע המעבר אינה עוזרת, כיוון שהשרתים כבר מחזיקים בערך הישן עם תאריך התפוגה המקורי שלו. הנמיכו אותו מראש, המתינו עד שיפוג הערך הישן, ורק אז בצעו את ההגירה.

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

הפקודה הראשונה מדפיסה את ה־TTL הנוכחי בעמודה השנייה של התשובה. הגדירו אותו ל-300 אצל ספק ה־DNS שלכם, והמתינו זמן רב יותר מהערך שהחלפתם.

לאחר מכן פעלו לפי הסדר הבא:

1. הקימו את השרת החדש ובצעו לו הקשחה (hardening) לפני שכל דבר אחר מועלה אליו. המדריך עשר הדקות הראשונות ב-VPS חדש מכסה את החלק שאנשים מדלגים עליו כשהם ממהרים.
2. התקינו את ה-stack של היישום ובצעו העתקה ראשונית של הנתונים בעזרת rsync, בזמן שהשרת הישן ממשיך לעבוד כרגיל.
3. הנפיקו את תעודת ה-TLS במארח החדש כעת, באמצעות אתגר DNS-01, כיוון שאתגר HTTP-01 מאמת מול ה-IP שאליו ה-DNS מצביע כרגע, שהוא עדיין השרת הישן. אתגר DNS-01 פותר את בעיית הסדר הזו לחלוטין.
4. בדקו את המארח החדש לפני כל שינוי פומבי על ידי דריסת ה-DNS במחשב האישי שלכם. הוסיפו את 203.0.113.20 example.com ל-/etc/hosts, גלשו לאתר האמיתי, ואז מחקו את השורה. אף משתמש לא יושפע מבדיקה זו.
5. טפלו בשאלת גודל מסד הנתונים. בנפח של כמה GB בודדים, גיבוי ושחזור נכנסים בתוך חלון הקפאת הכתיבה. מעבר לכך, הגדירו שכפול (replication) ממסד הנתונים הישן לחדש ימים מראש ותנו לו להסתנכרן, כך שההקפאה תכסה רק את שלב הקידום (promotion).
6. הקפיאו כתיבה. העבירו את היישום למצב תחזוקה או לקריאה בלבד. זהו החלק היחיד שהמשתמשים יכולים לראות, והוא אמור להימשך דקות ספורות.
7. בצעו את ה-delta הסופי: שוב את אותו rsync, ולאחר מכן את סנכרון מסד הנתונים האחרון.
8. שנו את רשומות ה-A וה-AAAA ל-IP החדש. עם TTL של 300 שניות, רוב שרתי ה-DNS יתעדכנו תוך כחמש דקות.
9. השאירו את השרת הישן פועל ונגיש למשך יום לפחות, כיוון שחלק מהשרתים מתעלמים מ-TTL קצר. אם היישום הישן עדיין מאפשר כתיבה, פניות מאוחרות יכתבו למסד הנתונים הלא נכון; לכן, הפנו את המארח הישן למסד הנתונים החדש או הציגו ממנו דף תחזוקה.
10. עקבו אחר שיעור השגיאות של השרת החדש במשך יום, החזירו את ה-TTL לערכו הרגיל, והשמידו את השרת הישן לאחר שבוע ולא באותו ערב.

ההעתקה עצמה מורכבת משתי פקודות, שכל אחת מהן מורצת פעמיים. סנכרון הקבצים:

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

-a שומר על בעלות, הרשאות וחותמות זמן, -H שומר על hard links, -AX שומר על ACLs ומאפיינים מורחבים, ו---numeric-ids מונע מ-rsync למפות מחדש מזהי משתמשים דרך שמות ששונים בין שתי המכונות. הריצו זאת ימים מראש, ואז שוב במהלך ההקפאה, אז יועברו רק השינויים.

עבור 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, כך שהתוצאה עקבית והיישום ממשיך לכתוב בזמן שהתהליך רץ. ללא דגל זה, mysqldump נועל את הטבלאות, מה שאומר שהקפאת הכתיבה שלכם התחילה מוקדם מהמתוכנן ולא אתם בחרתם מתי.

שני דברים עלולים להשתבש מחוץ לשרתים שלכם. לכתובת IP חדשה אין מוניטין דואר, לכן דואר שנשלח ישירות מהשרת החדש יסונן כ-spam: שלחו דרך relay שכבר מחזיק במוניטין. כמו כן, כל שותף שמבצע allowlist ל-IP היוצא שלכם, כגון שער תשלומים או firewall של לקוח, חייב להתעדכן לפני המעבר, אחרת הקריאות יתחילו להיכשל ברגע שהתעבורה תעבור.

מה לבדוק לפני התחייבות

• האם המחיר הוא מחיר מבצע ומהו המחיר בחידוש. הנחה לתקופה ראשונה שמוכפלת בחידוש היא עלות אמיתית, פשוט נדחית.
• האם התקופה משולמת מראש. תוכניות רב-שנתיות בתשלום מראש, כפי ש-SSD Nodes מוכרת, מאפשרות לרכוש מחיר נמוך משמעותית לכל GB של RAM תמורת תשלום מראש. העסקה היא שלא ניתן לעזוב בחודש הבא, לכן התאימו את התקופה לרמת הוודאות שלכם.
• מהי העלות החודשית של snapshot, ומהי העלות של שחזור בכסף ובדקות.
• האם חריגה מהמכסה מחויבת בתשלום או מוגבלת ברוחב פס (throttled).
• האם IPv6 מנותב כראוי או שמדובר בכתובת בודדת שמחוברת בצורה מאולתרת.
• האם קיים API עם ספק Terraform מתוחזק, אם בכוונתכם לבנות מחדש מתוך קוד ולא ידנית.
• כיצד יוצרים קשר עם התמיכה, ומהו יעד המענה המפורסם עבור שרת שנפל, להבדיל משאלות מכירה.

בחרו לפי הציר שמהווה את החלק המשמעותי ביותר בחשבונית שלכם. אם זה זיכרון, המחיר ל-GB של RAM יכריע. אם זה תעבורה יוצאת, נפח התעבורה הכלול יכריע. אם זה הזמן שלכם, הפלטפורמה המנוהלת תכריע, וזו של DigitalOcean היא החזקה ביותר מבין הארבע המושוות כאן.

FAQ

האם Hetzner תמיד זולה יותר מ-DigitalOcean?

עבור שרת וירטואלי בסיסי, המחיר ל-GB של RAM נמוך משמעותית: כ-1.62$ לעומת 6.00$ בתוכניות שיתופיות בסיסיות, נכון ל-5 באוגוסט 2026. ההשוואה משתנה כאשר נכנסים לתמונה שירותים מנוהלים. Hetzner מוכרת שרתים ותשתית רשת, לכן ניהול מסד נתונים או פלטפורמת push-to-deploy דורשים עבודה עצמית או שימוש בצד שלישי, ולשעות עבודה אלו יש עלות. Hetzner העלתה את מחירי הענן במהלך 2026, לכן יש לבדוק את המחיר העדכני באירו ולא להסתמך על מאמרים ישנים.

באיזו חלופה ל-DigitalOcean כדאי לבחור אם אני זקוק למסד נתונים מנוהל?

Vultr ו-Akamai מציעות שתיהן מסדי נתונים מנוהלים, ולכן הן התחליפים הקרובים ביותר אם מסד הנתונים המנוהל הוא הסיבה העיקרית לשימוש ב-DigitalOcean. ספקיות אירוח אירופאיות זולות לרוב אינן מציעות שירות כזה, מה שאומר שתצטרכו להריץ PostgreSQL או MySQL בעצמכם, כולל הגדרת שכפול (replication) ופתרון failover שנבדק. זו עבודה לכל דבר. שקללו זאת מול העלות של 15.15$ לחודש עבור מופע מנוהל של 1 GiB לפני שתחליטו שהשרת הזול אכן חסך לכם כסף.

איך מעבירים אתר פעיל לספק חדש ללא זמן השבתה?

הנמיכו את ה-TTL של ה-DNS ל-300 שניות לפחות 48 שעות לפני המעבר, כיוון ששרתי DNS ממשיכים להגיש את ה-IP הישן לפי ה-TTL הקודם. בנו ובדקו את השרת החדש בזמן שהישן עדיין משרת תעבורה, תוך שימוש ב-/etc/hosts כדי לעקוף את ה-DNS במחשב האישי שלכם מבלי להשפיע על משתמשים אחרים. לאחר מכן, עצרו כתיבות למסד הנתונים לכמה דקות, בצעו rsync סופי של הקבצים וסנכרון אחרון של מסד הנתונים, עדכנו את רשומות ה-A וה-AAAA, והשאירו את השרת הישן פעיל למשך שבוע למקרה ששרת DNS כלשהו התעלם מה-TTL הקצר.

האם VPS זול יותר אומר דיסקים איטיים יותר?

לא בהכרח. מה שקובע הוא האם הדיסק הווירטואלי מקומי לשרת המארח או נמצא על אשכול אחסון רשתי, ומידע זה לרוב אינו מופיע בלוח הבקרה. lsblk -o NAME,ROTA מדווח על 0 עבור שניהם, כיוון ששניהם מבוססים על זיכרון פלאש. במקום זאת, בצעו מדידה: הריצו את fio עם --iodepth=1 --bs=4k --direct=1 ובדקו את זמן האחזור (latency) באחוזון ה-99. נפח אחסון רשתי מוסיף זמן הלוך-חזור ברשת מרכז הנתונים לכל פעולת קריאה, לכן רצפת זמן האחזור שלו גבוהה יותר מאשר NVMe מקומי, גם כאשר ביצועי ה-throughput בתור עמוק נראים דומים.

האם המיילים שלי עדיין יישלחו מהשרת החדש?

לרוב לא, לפחות בהתחלה. לכתובת IP חדשה אין היסטוריית שליחה, לכן שרתי דואר יתייחסו להודעות ממנה כחשודות והן יגיעו לתיקיית ה-spam או יידחו לחלוטין. רשומות SPF ו-DKIM גם הן יצביעו על השרת הישן עד שתעדכנו אותן. שלחו מיילים מהיישום דרך relay או שירות דואר שכבר מחזיק במוניטין, ועדכנו את רשומות ה-DNS עבור הדואר לפני המעבר ולא אחריו.