Shared hosting או VPS: איך לבחור לאתר שלכם?

Shared hosting לעומת VPS: התשובה הקצרה

Shared hosting לעומת VPS אינו עניין של מהירות. ב־shared hosting אתם שוכרים חשבון במחשב שמישהו אחר מגדיר, מעדכן ומשתף בין מאות לקוחות. ב־VPS (שרת פרטי וירטואלי) אתם שוכרים מערכת הפעלה שלמה עם גישת root, ולכן אתם מתקינים את מה שאתם רוצים וגם מתקנים את מה שקלקלתם.

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

אם האתר שלכם כולל דפים, תמונות וטופס יצירת קשר, shared hosting הוא הבחירה הנכונה והוא עולה פחות. אם האתר שלכם זקוק לתוכנית שממשיכה לפעול גם כשאף אחד אינו מבקר בו, אתם זקוקים ל־VPS.

מה באמת מקבלים באחסון משותף

שרת Linux אחד מפעיל חשבונות של לקוחות רבים בו-זמנית. כל חשבון כולל ספריית בית עם שורש מסמכים, מסד נתונים ותיבת דואר, ושרת web יחיד, בדרך כלל Apache או LiteSpeed, משרת את כל האתרים בשרת. במקום שורת פקודה מקבלים לוח בקרה. אין לכם הרשאת root, ולכן אינכם יכולים להתקין חבילה, לפתוח פורט או להפעיל שירות רקע.

רוב ספקי האחסון המשותף מפעילים CloudLinux, שמכניס כל חשבון למכולה משלו ומגביל באופן קשיח את זמן המעבד ואת מספר התהליכים שניתן להפעיל בו-זמנית. חריגה ממגבלת התהליכים אינה מאטה את האתר. היא גורמת לשרת להחזיר דף שגיאה ובו 508 Resource Limit Is Reached. דף זה מציין שהחשבון שלכם הגיע למגבלה שלו, ולא שלקוח אחר מנצל את המשאבים שהוקצו לכם.

הוויתור הזה מכוון. אתם מוותרים על שליטה, ובתמורה ספק האחסון מעדכן את ה־kernel, מעדכן את PHP, מחדש את התעודה ומבצע גיבוי מדי לילה. עבור אתרים רבים מאוד, זו עסקה משתלמת.

מה VPS מעניק לכם בפועל

VPS הוא מכונה וירטואלית שפועלת על שרת מארח. תחת KVM, ה־hypervisor שמאחורי רוב חבילות ה־VPS ל־Linux, ה־instance שלכם מאתחל kernel משלו ומחזיק כתובת IP משלו, firewall משלו ומערכת init משלו. sudo פועל. apt install פועל. תוכנית שאתם מפעילים באמצעות systemd ממשיכה לפעול לאחר היציאה מהמערכת, מופעלת מחדש לאחר קריסה וחוזרת לפעול לאחר reboot.

אותה גישת root היא הסיבה לכך שאבטחת המכונה הופכת לאחריות שלכם. אף גורם אחר אינו מנטר אותה. מגוון הדברים שאנשים מפעילים ב־VPS רחב בדיוק מסיבה זו: השרת יכול לבצע כל פעולה ששרת Linux מסוגל לבצע.

הבדל 1: גישה ל־root ומה היא מאפשרת

root הוא ההבדל שממנו נובעים כל ההבדלים האחרים. באמצעותו אפשר להתקין כל חבילה ממאגר ההפצה, להאזין בכל פורט, לכתוב יחידת systemd, לקרוא כל log במחשב ולשנות הגדרות kernel באמצעות sysctl. בלעדיו מקבלים את רשימת האפשרויות שהפאנל מציע: בורר גרסת PHP, קבוצה קבועה של extensions וטופס ל־cron jobs.

ב־VPS אפשר תמיד לבקש מהמחשב להציג אילו שירותים מאזינים:

ss -ltnp

כל שורה מייצגת socket פתוח אחד ואת התהליך שבבעלותו. לכן שירות שלא הצליח לעלות יופיע כשורה חסרה. באחסון משותף אין לשאלה הזו תשובה, משום ש־ports 80 ו־443 שייכים ל־web server של המארח, ושום דבר שתכתבו לא יכול לתפוס אותם.

הבדל 2: זיכרון שהוקצה לעומת זיכרון מושאל

אחסון משותף נמכר מתוך ההנחה שמעט חשבונות יהיו פעילים באותו רגע. הזיכרון במכונה הוא מאגר משותף, והחלק של החשבון שלך הוא מגבלה ולא הקצאה מובטחת. כאשר החשבון חורג מהמגבלה, תהליכי PHP מופסקים והמבקרים מקבלים שגיאת 500 או 508.

ב־VPS הזיכרון הכלול בתוכנית שלך שייך למופע שלך. free -m מדווח עליו, ושום תהליך מחוץ למכונה הווירטואלית שלך אינו יכול לקחת אותו.

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

vmstat 1 5

העמודה st היא זמן steal: שיעור הזמן שבו המעבד הווירטואלי שלך היה מוכן להריץ תהליך, אך הליבה הפיזית הוקצתה לאורח אחר. ערך יציב של כמה אחוזים הוא תקין. ערך דו־ספרתי שנמשך לאורך זמן מצביע על הקצאת יתר של משאבי המארח, וזה נתון שאפשר לציין בפנייה לתמיכה. באחסון משותף אין מדידה מקבילה, משום שכל כלי שיכול להציג אותה דורש הרשאות root. האחסון מתנהג באותו אופן. לכן סוג הדיסק שמאחורי תוכנית VPS חשוב, ומומלץ למדוד VPS חדש בעצמך במהלך השבוע הראשון במקום להסתמך על דף המכירות.

הבדל 3: מי אחראי כאשר משהו מתקלקל

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

ב־VPS ללא ניהול, הספק אחראי על ה־hypervisor, על הרשת ועל אספקת החשמל. כל מה שמעל ל־kernel נמצא באחריותכם. עדכוני אבטחה, ה־firewall, גיבויים, חידוש תעודות וניטור הם כולם באחריותכם, וצוות התמיכה לא יתחבר כדי לאתר תקלות בתצורת שרת האינטרנט שלכם. תכננו זאת כבר מהיום הראשון: עשר הדקות הראשונות ב־VPS חדש, לאחר מכן firewall שאתם מבינים, עדכוני אבטחה אוטומטיים ו־גיבויים ששחזרתם לפחות פעם אחת.

כאשר אחסון משותף הוא הבחירה הנכונה

אתר תדמית הוא המקרה הברור ביותר: כמה עמודים, תמונות, טופס יצירת קשר, אולי WordPress עם תוסף caching, וכמה אלפי ביקורים ביום. אין משימות רקע. אין סביבת ריצה חריגה. אין דבר שצריך להישאר בזיכרון בין בקשות. אחסון משותף מתאים היטב לאתר כזה, עולה פחות מכל VPS, ומעביר את התחזוקה לאנשים שעוסקים בכך במשרה מלאה. העברה שלו ל־VPS לא תועיל, ותוסיף משימה שלא הייתה לכם.

יש מקרה נוסף שזוכה לפחות תשומת לב. אם לאף אחד בצד שלכם אין רצון לקרוא קובץ לוג או להריץ apt upgrade, אחסון משותף הוא הבחירה הבטוחה יותר. VPS שלא הותקנו בו עדכוני אבטחה, עם פורט מסד נתונים פתוח, הוא תוצאה גרועה יותר מחשבון אחסון משותף שמתוחזק ומעודכן על ידי אנשי מקצוע. שליטה היא יתרון רק כאשר מישהו משתמש בה.

סימן 1: דרושה תוכנית שפועלת ברציפות

Daemon הוא תוכנית שנשארת בזיכרון וממתינה לעבודה: API, בוט צ'אט, worker של תור או שרת משחק. באחסון משותף הקוד שלכם מופעל רק כאשר מגיעה בקשה, וכל תוכנית שתשאירו פועלת מתוך הפעלת SSH (secure shell) תופסק, משום שתהליך ארוך־טווח נכלל במגבלת התהליכים של החשבון.

ב־VPS אותה תוכנית הופכת ליחידת systemd:

sudo systemctl enable --now myapp
systemctl status myapp

systemctl status אמור להציג Active: active (running) עם מזהה תהליך. אם הוא מציג Active: failed (Result: exit-code), הסיבה נמצאת ב־journalctl -u myapp -n 50, שמציג את הפלט של התוכנית עצמה ברגע שבו היא הופסקה. Restart=always בקובץ היחידה מפעיל אותה מחדש לאחר קריסה, ו־enable מפעיל אותה מחדש לאחר אתחול. כתיבת שירותים וטיימרים של systemd היא מיומנות ה־VPS הראשונה שכדאי ללמוד כראוי.

סימן 2: נדרשת סביבת הרצה שהפאנל אינו מציע

הפאנל מספק רשימה. אם היישום שלך דורש גרסת שפה שאינה מופיעה ברשימה, ספרייה שיש להדר, ffmpeg, דפדפן ללא ממשק גרפי או מסד נתונים שאינו MySQL, באירוח משותף אין מקום להתקין אותם. התקנת תוכנה דורשת הרשאת root, ולחשבון אין מהדר או קובצי כותרת לפיתוח. לכן תהליך הבנייה נכשל לפני שהוא מפיק תוצר כלשהו.

ב־VPS מתקינים את התוכנה באמצעות apt install, או מפעילים אותה במכולה ומשאירים את המארח נקי. Docker Compose ב־VPS הוא הנתיב המקובל כאשר ליישום יש יותר מרכיב פעיל אחד.

סימן 3: משימת ה־cron שלך חייבת לפעול בזמן

שירותי אירוח משותף מקבלים משימות cron באמצעות טופס ומגדירים מרווח מינימלי, בדרך כלל חמש או חמש עשרה דקות. משימה שחורגת ממגבלת המעבד של החשבון מופסקת באמצע, והכשל מתרחש בשקט, משום ששום דבר אינו כותב ליומן שמותר לך לקרוא.

ב־VPS crontab -e מקבל כל לוח זמנים שתכתוב, וטיימר של systemd עדיף אפילו יותר:

systemctl list-timers
journalctl -u cron -n 20

list-timers מציג את ההפעלה הבאה ואת התוצאה האחרונה של כל טיימר, ויומן ה־cron מציג כל פקודה ברגע שהיא מופעלת. כאשר משימה אינה מתבצעת, אפשר לדעת אם היא כלל לא התחילה או שהתחילה ונכשלה. ההבחנה הזאת מהווה את עיקר תהליך ניפוי השגיאות של משימה מתוזמנת.

סימן 4: השכנים שלכם מאריכים את זמן התגובה

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

for i in $(seq 1 20); do curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/; sleep 5; done

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

העלות האמיתית של המעבר

אלה המחירים המפורסמים האופייניים נכון ל־August 2026 עבור התוכנית הקטנה ביותר בכל קטגוריה. ראו בהם סדר גודל ולא הצעת מחיר, ובדקו את המחיר העדכני לפני הרכישה.

[
  {
    "plan": "Shared hosting",
    "first_term_usd": 3,
    "renewal_usd": 12
  },
  {
    "plan": "VPS, 1 vCPU 1 GB",
    "first_term_usd": 5,
    "renewal_usd": 6
  },
  {
    "plan": "VPS, 2 vCPU 4 GB",
    "first_term_usd": 12,
    "renewal_usd": 15
  },
  {
    "plan": "Managed VPS, 2 vCPU 4 GB",
    "first_term_usd": 25,
    "renewal_usd": 30
  }
]

הפער בכותרת נע בין 3 ל־5 דולר ארה״ב לחודש, אך זה אינו הנתון שמכריע. אחסון משותף מציג בדרך כלל מחיר לתקופה הראשונה שמחייב תשלום מראש עבור שנה עד שלוש שנים, ולאחר מכן מתחדש במחיר של כ־12 דולר. השוו מחיר חידוש למחיר חידוש, והתמונה משתנה: 12 דולר עבור חשבון האחסון המשותף, לעומת 6 דולר עבור VPS התחלתי.

יש להיזהר מההשוואה הזו, משום שהגדלים אינם זהים. VPS עם 1 vCPU ו־1 GB מריץ את שרת האינטרנט ואת מסד הנתונים על שרת קטן אחד. לאחר שהאתר מתחיל לקבל תעבורה אמיתית, הדבר מגביל עבור WordPress. ההשוואה ההוגנת לתוכנית אחסון משותף לאחר חידוש היא המסלול עם 2 vCPU ו־4 GB, שמחירו כ־15 דולר. לכן הפרמיה האמיתית היא כמה דולרים בחודש, ולא מכפלה של המחיר.

העלות הגדולה יותר לעולם אינה מופיעה בחשבונית. VPS מוסיף כשעה של הגדרה, כמה דקות בכל חודש לעדכונים, ואת הערב שתשקיעו בפעם הראשונה שמשהו יתקלקל. חשבו על כך לפי התעריף השעתי שלכם, והפער מצטמצם במהירות. כמה עולה VPS בפועל מפרט את גדלי התוכניות ביתר פירוט.

העברת אתר מאירוח משותף בלי לאבד תעבורה

1. יום מראש, הנמיכו את ה־TTL (זמן החיים) של ה־DNS (מערכת שמות המתחם) עבור המתחם ל־300 שניות, כדי שהמעבר ייכנס לתוקף בתוך דקות ולא בתוך שעות.
2. הקימו את השרת החדש וודאו שהאתר פועל בכתובת ה־IP שלו לפני שתשנו את ה־DNS.
3. העתיקו את הקבצים, לאחר מכן בצעו dump למסד הנתונים ושחזרו אותו בשרת החדש.
4. בדקו באמצעות קובץ ה־hosts במחשב הנייד שלכם. קובץ זה מפנה את המתחם לכתובת ה־IP החדשה רק עבור המחשב שלכם.
5. הנפיקו את תעודת ה־TLS (אבטחת שכבת התעבורה) בשרת החדש, שנו את רשומת ה־A והשאירו את החשבון באירוח המשותף פעיל למשך שבוע.

dig example.com A +noall +answer
rsync -avz ~/public_html/ deploy@203.0.113.10:/srv/www/example.com/
mysqldump --single-transaction -u dbuser -p dbname > site.sql

dig מציג את ה־TTL בעמודה השנייה של התשובה שלו, כדי שתוכלו לוודא שהערך הנמוך כבר פעיל לפני שתבצעו שינוי כלשהו. --single-transaction יוצר snapshot עקבי בלי לנעול את הטבלאות. הדבר חשוב אם האתר הישן עדיין מקבל הזמנות בזמן העבודה. בשרת החדש, הגדירו את התעודות עוד באותו יום: Let's Encrypt ב־Ubuntu עם nginx דורש כמה דקות בלבד לאחר שרשומת ה־DNS מפנה לשרת.

משאבים ללא האחריות

אם ארבעת הסימנים מתארים את האתר שלך, אך התחזוקה אינה מתאימה לך, האפשרות שבאמצע היא VPS מנוהל. המשאבים שהוקצו לך ויכולת העבודה ברמת root נשארים ברשותך, ואילו הספק מטפל בעדכוני האבטחה, בניטור ובדרך כלל גם בלוח בקרה. התרשים שלמעלה מציג עלות של כ־30 דולר, לעומת 15 עבור VPS לא מנוהל באותו גודל. ההפרש מאפשר לקבל טיפול של גורם אחר כאשר השרת מפסיק להגיב במהלך הלילה.

הבחירה בין VPS מנוהל ל־VPS לא מנוהל היא הקריאה הבאה המתאימה אם זה המצב שלך. אם במקום זאת כבר יש לך VPS עמוס, וזמן ה־steal עדיין גבוה בשעות השיא, השלב הבא הוא שרת ייעודי ללא שכנים כלל.

FAQ

האם VPS מהיר יותר מאחסון משותף?

לא בהכרח. שרת משותף שאינו עמוס יכול להיות מהיר יותר מ־VPS עם 1 vCPU בטעינת דף WordPress יחיד. היתרון של VPS הוא עקביות: הזיכרון שהוקצה לכם שייך לכם, ולכן זמן התגובה תלוי בקוד שלכם ולא בחשבון העמוס ביותר בשרת. אם הדפים שלכם איטיים גם בשעה 3 לפנות בוקר וגם בשעה 7 בערב, הסיבה היא הקוד שלכם או שאילתות מסד הנתונים שלכם. העברת אותו קוד ל־VPS תעביר איתה גם את הבעיה.

האם אפשר להפעיל יישום Node.js או Python באחסון משותף?

לפעמים, ורק במסגרת מגבלות צרות. חלק מלוחות הבקרה מפעילים עבורכם יישום באמצעות Passenger, והוא רץ כאשר מתקבלת בקשה. אינכם יכולים להאזין בפורט משלכם, משום ששרת האינטרנט של ספק האחסון משתמש בפורטים 80 ו־443. אינכם יכולים להשאיר worker בזיכרון בין בקשות, משום שמגבלת התהליכים של החשבון מסיימת כל תהליך שרץ לאורך זמן. bot, queue worker או שרת websocket זקוקים ל־VPS.

האם צריך לדעת Linux כדי להפעיל VPS?

ב־VPS שאינו מנוהל, כן. עליכם להכיר מפתחות SSH, firewall, עדכונים וגיבויים, ולפתח הרגל של קריאת לוגים. הקצו כשעה להגדרה הראשונית ועוד כמה דקות בכל חודש לאחר מכן. אם אינכם מעוניינים בעבודה זו, תוכנית מנוהלת משאירה את המשאבים שהוקצו לכם ומעבירה את התחזוקה חזרה לספק. זהו ההבדל שנידון ב־אחסון VPS מנוהל לעומת VPS שאינו מנוהל.

האם האתר יושבת בזמן המעבר מאחסון משותף ל־VPS?

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