איך לארח כמה אתרים על VPS אחד — מדריך מלא

כדי לארח כמה אתרים על VPS אחד, כל אתר צריך לקבל חמישה דברים משלו: משתמש לינוקס, תיקיית שורש בתוך תיקיית הבית של אותו משתמש, PHP-FPM pool שרץ בזהות של אותו משתמש עם socket נפרד, server block ב‑Nginx, ומסד נתונים עם משתמש ייעודי בעל הרשאות מינימליות. בונים את התבנית הזו פעם אחת, כותבים סקריפט, ומאותו רגע הוספת האתר השנים‑עשר לוקחת ארבע דקות.

החלק שכמעט כל מדריך מדלג עליו הוא ההפרדה, והוא בדיוק החלק שקובע אם יום רע יישאר קטן. אם כל האתרים רצים בתור www-data מתוך /var/www, תוסף אחד לא מעודכן באתר הכי פחות חשוב שלכם יכול לקרוא את wp-config.php של כל שאר האתרים — ולכן גם את סיסמאות מסדי הנתונים שלהם. פריצה אחת הופכת לשתים‑עשרה.

נקודות מפתח

• יחידת ההפרדה היא משתמש לינוקס, לא תיקייה. משתמש אחד לכל אתר, pool אחד לכל משתמש, socket אחד לכל pool.
• שימוש משותף ב‑www-data הוא הכשל הנפוץ ביותר בשרתי סוכנויות. הוא הופך כל חולשה בתוסף לדליפת סיסמאות של כל השרת.
• ה‑server blocks ב‑Nginx הם החלק הקל. הבעלות על הקבצים, ההרשאות וזהות ה‑pool הם המקום שבו מדריכים משתתקים.
• pm.max_children לכל pool הוא הבלם שמונע מאתר עמוס לזלול את כל הזיכרון. מגבלות systemd על שירות ה‑FPM הן רשת הביטחון מתחתיו.
• גיבויים חייבים לאפשר שחזור של אתר בודד. "נחזיר את כל השרת ליום שלישי" זו לא תשובה כשלקוח אחד שבר אתר אחד.
• לקוח עם דרישות רגולציה, תנועה חריגה או סיכוי סביר לעבור לספק אחר — צריך VPS משלו.

קודם כל להחליט: VPS אחד עם הפרדה, או VPS לכל לקוח

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

תנו VPS נפרד ל:

• לקוח שאולי תעבירו הלאה. אם יש סיכוי שהקשר יסתיים והם ייקחו את האתר לסוכנות אחרת, מכונה ייעודית הופכת חילוץ מכאיב לשינוי DNS.
• כל דבר עם מחויבות רגולטורית. לקוח שצריך למלא שאלון אבטחה, לחתום על הסכם עיבוד מידע, או להוכיח שהנתונים שלו לא יושבים לצד דיירים אחרים. אתם לא רוצים שהתשובה הכנה לשאלה "מי עוד על השרת הזה" תהיה רשימה של אחד‑עשר עסקים.
• האתר היחיד עם תנועה אמיתית. אם דייר אחד צורך את רוב המעבד, כל השאר משלמים על הקפיצות שלו.
• כל מי שצריך מוניטין IP משלו. בעיקר דואר יוצא. אם כתובת אחת נכנסת לרשימה שחורה, כל האתרים על אותה כתובת יורשים את הבעיה.
• אתרים על סטאק שונה לחלוטין. אפליקציה ישנה שנעולה על גרסת PHP עתיקה יכולה להחזיק את כל מסלול השדרוגים שלכם כבן ערובה.

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

למה ההפרדה היא כל הסיפור

שווה לפרט את הכשל במלואו. המדריך הסטנדרטי שם את כל האתרים תחת /var/www ומריץ pool אחד בתור www-data. לכל תהליך PHP על המכונה יש אותה זהות ואותן הרשאות קריאה.

תוקף מוצא חולשת קריאת קבצים או העלאת קבצים בתוסף באתר השביעי — בדרך כלל בונה טפסים שלא עודכן שנתיים. עכשיו יש לו הרצת קוד בתור www-data, והפקודה הראשונה שלו היא לא אקספלויט אלא cat /var/www/*/wp-config.php. זה מחזיר שם מסד נתונים, משתמש וסיסמה של כל התקנת וורדפרס על השרת. משם הוא מתחבר ל‑MySQL מקומית ומזריק משתמשי אדמין לכולם. לא נדרשת שום פריצה נוספת.

עם משתמש נפרד לכל אתר, אותה חדירה נותנת הרצת קוד בתור acme בלבד. המשתמש הזה קורא את /home/acme ושום דבר אחר. יש לכם אירוע אבטחה, אבל הוא של אתר אחד — ואפשר לשחזר אתר אחד.

שלב 1: משתמש לינוקס לכל אתר, ומבנה תיקיות שמחזיק

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

sudo adduser --disabled-password --gecos "" acme
sudo mkdir -p /home/acme/public_html /home/acme/logs /home/acme/tmp/sessions
sudo chown -R acme:acme /home/acme

החליטו במודע לגבי ה‑shell. אם המפתח של הלקוח צריך SFTP, השאירו shell אמיתי ונעלו אותו לתיקייה שלו עם בלוק Match User בהגדרות SSH, יחד עם ChrootDirectory ו‑ForceCommand internal-sftp. המלכודת הקלאסית: תיקיית ה‑chroot עצמה חייבת להיות בבעלות root ולא ניתנת לכתיבה על ידי המשתמש, ולכן התיקיות שאפשר לכתוב אליהן חייבות להיות רמה אחת מתחת. כמעט כל תלונה על "החיבור נסגר מיד" מגיעה משם. אם אף אחד לא מתחבר בתור המשתמש הזה, הגדירו /usr/sbin/nologin.

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

זה השלב שמתפשרים עליו, וההתפשרות הזו היא איך מגיעים ל‑chmod 777 על תיקיית העלאות באחת בלילה. הגדירו נכון פעם אחת: chmod 750 על תיקיית הבית, 750 על תיקיות בתוך public_html, 640 על קבצים, ו‑chmod 400 על wp-config.php.

ועכשיו הבעיה שאף אחד לא מזהיר עליה: Nginx רץ בתור www-data וצריך לקרוא קבצים סטטיים ולעבור דרך /home/acme. עם הרשאות 750 וקבוצה acme הוא לא יכול. הפתרון הוא להוסיף את משתמש השרת לקבוצה של כל אתר: sudo usermod -aG acme www-data ואז sudo systemctl restart nginx. ההפעלה מחדש הכרחית, כי חברות בקבוצות משניות נקראת רק כשתהליך עולה — reload לא יספיק.

היו כנים עם עצמכם לגבי ההתפשרות: תהליך ה‑Nginx יכול עכשיו לקרוא את הקבצים של כל האתרים. זו בחירה מכוונת. האיום שאתם מתגוננים מפניו הוא אפליקציית PHP פרוצה, וזה קורה כל הזמן; פריצה של תהליך Nginx נדירה בהשוואה. תהליך ה‑PHP של acme נמצא רק בקבוצה acme ולא נוגע בתיקיות של לקוח אחר — וזו התכונה שרציתם. זו גם הסיבה ש‑wp-config.php מקבל 400: רק הבעלים קורא אותו, כלומר ה‑pool של האתר, ולא Nginx.

שלב 2: PHP-FPM pool נפרד לכל אתר

pool הוא קבוצת תהליכי PHP עם זהות משלה, socket משלה והגדרות משלה. שורת ה‑user בקובץ ה‑pool היא זו שקובעת איזה חשבון יוניקס מריץ את הקוד של האתר, ולכן היא זו שנותנת משמעות לכל מה שעשינו בשלב הקודם.

בדביאן ואובונטו הקבצים יושבים ב‑/etc/php/8.3/fpm/pool.d/, ובמשפחת RHEL ב‑/etc/php-fpm.d/. קובץ acme.conf לדוגמה:

[acme]
user = acme
group = acme
listen = /run/php/acme.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
pm = ondemand
pm.max_children = 8
pm.process_idle_timeout = 20s
pm.max_requests = 500
request_terminate_timeout = 120s
slowlog = /home/acme/logs/php-slow.log
request_slowlog_timeout = 10s
security.limit_extensions = .php
php_admin_value[error_log] = /home/acme/logs/php-error.log
php_admin_flag[log_errors] = on
php_admin_value[memory_limit] = 256M
php_admin_value[session.save_path] = /home/acme/tmp/sessions
php_admin_value[upload_tmp_dir] = /home/acme/tmp
php_admin_value[open_basedir] = /home/acme/

כל ההנחיות האלה מתועדות בעמוד ההגדרות של PHP-FPM. כמה הערות: pm = ondemand מפעיל תהליכים רק כשמגיעה בקשה ומכבה אותם אחרי זמן המתנה, וזה ההבדל בין שנים‑עשר pools שתופסים מאות מגה‑בייט לבין שנים‑עשר pools שתופסים כמעט כלום. הערכים שנקבעים עם php_admin_value אינם ניתנים לדריסה בעזרת ini_set() מתוך קוד האפליקציה, כך שתוסף לא יוכל להזיז לעצמו את תיקיית ה‑sessions. ו‑open_basedir הוא מעקה בטיחות ולא גבול אבטחה — הוא לא מחליף את ההרשאות משלב 1.

מחקו או נטרלו את ה‑pool ברירת המחדל www.conf אחרי שיצרתם pools ייעודיים. אם הוא נשאר, עדיין רץ אצלכם pool בזהות www-data, ובסוף איזה server block יצביע אליו בטעות. אחרי sudo systemctl reload php8.3-fpm ודאו עם ls -l /run/php/ שכל ה‑sockets עלו.

למה הרשאות ה‑socket חשובות יותר משנדמה

socket של FastCGI הוא לא קובץ פסיבי. כל מי שיכול לכתוב אליו יכול לשלוח בקשה ל‑pool ולגרום ל‑PHP להריץ סקריפט בזהות של אותו pool. אם תגדירו listen.mode = 0666 — והרבה הגדרות מועתקות עושות בדיוק את זה כדי להיפטר משגיאת הרשאות — משתמש של אתר אחר יוכל לשלוח בקשה מזויפת ל‑pool שלכם ולהריץ קוד בזהות שלו. בעלות www-data עם 0660 מבטיחה שרק שרת הרשת מדבר עם ה‑socket.

שלב 3: server blocks ב‑Nginx

בדביאן ואובונטו שמים קובץ אחד לכל אתר ב‑/etc/nginx/sites-available/ ויוצרים קישור ל‑sites-enabled; עם חבילות מ‑nginx.org או במשפחת RHEL הקובץ נכנס ישירות ל‑/etc/nginx/conf.d/. בלוק הפורט 80 קיים רק כדי לענות לאתגרי ACME ולהפנות את כל השאר ל‑HTTPS, ולכן location /.well-known/acme-challenge/ חייב להופיע לפני שורת ההפניה. הבלוק המרכזי:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name acme.co.il www.acme.co.il;
    root /home/acme/public_html;
    index index.php index.html;
    access_log /home/acme/logs/access.log;
    error_log /home/acme/logs/error.log;
    ssl_certificate /etc/letsencrypt/live/acme.co.il/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/acme.co.il/privkey.pem;
    client_max_body_size 64m;
    location / { try_files $uri $uri/ /index.php?$args; }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/acme.sock;
    }
    location ~ /\.ht { deny all; }
}

שתי הערות תאימות: http2 on; היא הנחיה נפרדת שהופיעה ב‑nginx 1.25.1, ובגרסאות ישנות יותר כותבים listen 443 ssl http2; — התיעוד הרשמי של nginx הוא הסמכות. snippets/fastcgi-php.conf הוא נוחות של חבילות דביאן; במקומות אחרים מחליפים ב‑include fastcgi_params; יחד עם fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;.

השורה שנושאת את כל ההפרדה היא fastcgi_pass. אם תפנו ל‑socket של אתר אחר, ה‑PHP של אותו אתר ירוץ על הקבצים של האתר הזה בזהות הלא נכונה, והתוצאה תהיה שגיאת הרשאות מבלבלת ולא הודעה ברורה.

הוסיפו גם בלוק ברירת מחדל אחד שתופס שמות מארח לא מוכרים, אחרת הבלוק הראשון שנטען עונה לכל סורק שמפנה דומיין אקראי ל‑IP שלכם: listen 80 default_server;, listen 443 ssl default_server;, server_name _;, ssl_reject_handshake on; ו‑return 444;. ההנחיה ssl_reject_handshake נוספה ב‑nginx 1.19.4 ומאפשרת לדחות לחיצת יד בלי אישור דמה. תמיד הריצו sudo nginx -t לפני reload — טעות אחת מפילה את כל שנים‑עשר האתרים.

המקבילה ב‑Apache

ב‑Apache אפשר להשיג את אותה הפרדה, אבל רק עם MPM מסוג event או worker יחד עם mod_proxy_fcgi. השילוב הישן של prefork ו‑mod_php לא יכול להריץ אתרים שונים בזהויות שונות, כי mod_php רץ בתוך תהליך ה‑Apache עצמו. אחרי sudo a2enmod proxy_fcgi setenvif, בתוך ה‑VirtualHost מוסיפים בלוק FilesMatch על קבצי php עם SetHandler "proxy:unix:/run/php/acme.sock|fcgi://localhost/". הטקסט אחרי הקו האנכי הוא חלק מחייב מהתחביר, לא שם מארח שצריך להיפתר.

שלב 4: אישורי TLS להרבה דומיינים

הנפיקו אישור לכל אתר בנפרד, ולא אישור ענק אחד שמכיל את כל הדומיינים. Let's Encrypt מאפשרת עד 100 שמות באישור אחד, אבל אישור משותף שביר תפעולית: אם ה‑DNS של לקוח אחד נשבר, החידוש נכשל לכל האישור וכל האתרים עליו מתחילים להגיש שרשרת פגת תוקף.

מי שרוצה שה‑certbot יכתוב את ההגדרות בעצמו ישתמש ב‑sudo certbot --nginx -d acme.co.il -d www.acme.co.il. מי שמעדיף לשמור על הקבצים שכתב בעצמו — וזה מה שרוב מי שמנהל הרבה אתרים רוצה — ישתמש ב‑sudo certbot certonly --webroot -w /home/acme/public_html --cert-name acme.co.il -d acme.co.il -d www.acme.co.il.

החידוש בדרך כלל כבר אוטומטי דרך טיימר של systemd או משימת cron; אמתו עם systemctl list-timers ובדקו את כל המסלול עם sudo certbot renew --dry-run. דבר אחד ש‑certbot לא יעשה בשבילכם כשהשתמשתם ב‑certonly: לטעון מחדש את שרת הרשת. הוסיפו סקריפט הרצה ב‑/etc/letsencrypt/renewal-hooks/deploy/ שמכיל systemctl reload nginx. בלעדיו האישורים מתחדשים על הדיסק ו‑Nginx ממשיך להגיש את הישנים — תקלה שמתגלה 60 יום אחר כך, ביום ראשון בבוקר. sudo certbot certificates מציג את כל האישורים ותאריכי התפוגה, ו‑sudo certbot delete --cert-name מסיר לקוח שעזב יחד עם הגדרת החידוש שלו. פרטים מלאים במדריך המשתמש של certbot.

שלב 5: מסד נתונים ומשתמש נפרדים לכל אתר

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

CREATE DATABASE acme_wp CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'acme_wp'@'localhost' IDENTIFIED BY 'סיסמה ארוכה ואקראית';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER,
      CREATE TEMPORARY TABLES, LOCK TABLES, REFERENCES
      ON acme_wp.* TO 'acme_wp'@'localhost';

שימו לב למה שאין שם: אין ON *.*, אין GRANT ALL, אין תו כללי בשדה המארח ואין GRANT OPTION. FLUSH PRIVILEGES אינו נדרש אחרי GRANT. ודאו גם ש‑ss -tlnp | grep 3306 מראה 127.0.0.1 ולא 0.0.0.0; אם מפתח צריך גישה מרחוק, תנו לו מנהרת SSH ולא פורט פתוח. עוד על כך בצ'קליסט הקשחת VPS שלנו.

שלב 6: חלוקת משאבים הוגנת בין האתרים

הפרדה מונעת מאתרים לקרוא זה את זה. היא לא מונעת מאתר אחד לבלוע את כל המכונה — זו עבודה נפרדת, וה‑pm.max_children הוא הבלם המרכזי בה.

כל תהליך PHP תופס זיכרון אמיתי, ולכן סך התהליכים שאתם מרשים בכל ה‑pools כפול הזיכרון שתהליך באמת צורך חייב להיכנס ל‑RAM אחרי שמערכת ההפעלה, מסד הנתונים ו‑Nginx לקחו את חלקם. מדדו במקום לנחש: ps --no-headers -o rss,cmd -C php-fpm8.3. את החישוב המלא כתבנו במדריך כמה אתרים אפשר לארח על VPS, והשתמשו בשיטה ולא במספרים של מישהו אחר — אתר תדמית וחנות ווקומרס נבדלים פי ארבעה ויותר.

• אתרים קטנים ורדומים: pm = ondemand עם 4 עד 6 תהליכים מקסימום.
• האתר היחיד עם תנועה: pm = dynamic עם ערך שנגזר מהמדידה שלכם, כדי שלא יתחיל תהליכים מאפס תחת עומס.
• אתר עם עבודות רקע כבדות: process.priority חיובי, כדי שיפנה מעבד לבקשות אינטראקטיביות של אחרים.
• בכל מקום: request_terminate_timeout ו‑pm.max_requests, כדי שבקשה תקועה או דליפת זיכרון לא ישתלטו על תהליך לנצח.

רשת ביטחון קשיחה מתקבלת מקובץ תוספת ל‑systemd ב‑/etc/systemd/system/php8.3-fpm.service.d/limits.conf עם [Service], MemoryMax=2G ו‑CPUQuota=300%, ואחריו daemon-reload והפעלה מחדש. CPUQuota נמדד ביחס לליבה אחת, כך ש‑300% מתיר שלוש ליבות. חשוב להבין את המגבלה: זה תוחם את PHP כמכלול ומגן על מסד הנתונים ועל חיבור ה‑SSH שלכם, אבל לא תוחם אתר בודד, כי בהתקנה סטנדרטית כל ה‑pools חולקים תהליך אב אחד. תיחום אמיתי לכל אתר דורש תהליך FPM נפרד לכל אתר כיחידת systemd משלו, וזו תחזוקה שמתחת לכעשרים אתרים כמעט אף פעם לא משתלמת.

שלב 7: גיבויים שאפשר לשחזר מהם אתר אחד

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

תמונות דיסק (snapshots) מהספק הן התאוששות מאסון מצוינת וחסרות תועלת מוחלטת כאן: החזרה ליום שלישי מחזירה גם אחד‑עשר אתרים שהיו בסדר גמור. הריצו את שניהם. עבודת גיבוי לאתר בודד מייצרת שני קבצים שנשמרים יחד: ארכיון של תיקיית הבית, ו‑mysqldump --single-transaction --quick של אותו מסד נתונים בלבד. הדגל --single-transaction נותן תמונה עקבית של InnoDB בלי לנעול את האתר.

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

ידני, פאנל חינמי או cPanel

גישה	עלות	איכות ההפרדה	העברת לקוח	נטל תחזוקה
Nginx ידני עם pool לכל אתר	שום דבר מעבר ל‑VPS	הטובה ביותר, כי אתם מגדירים כל שורה ויכולים לבדוק אותה	הקשה ביותר. ארכוב, dump ושינוי DNS בסקריפט שכתבתם בעצמכם	הכול עליכם: עדכוני מערכת, שדרוגי PHP, אישורים והוספת כל אתר
פאנל חינמי (HestiaCP, CyberPanel, CloudPanel)	תוכנה חינמית על אותו VPS, דורשת קצת יותר זיכרון	טובה. הם יוצרים משתמש מערכת ו‑pool תואם לכל חשבון, אבל כדאי לוודא את שורת ה‑user בהתקנה שלכם	בינונית. גיבוי של הפאנל משוחזר נקי לפאנל זהה אחר	נמוך יותר לכל אתר, בתוספת תלות חדשה: הפאנל עצמו דורש עדכונים ולפעמים דורס עריכות ידניות
cPanel / WHM	דמי רישוי, לרוב יותר מעלות ה‑VPS עצמו	טובה, עם משתמש נפרד לכל חשבון	הקלה ביותר. העברת חשבונות בין שרתי cPanel היא בעיה פתורה	הנמוך ביותר לכל אתר, מול המחיר הגבוה ביותר וגמישות קטנה יותר

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

איזה גודל VPS לכמה אתרים

חבילות ה‑VPS של דבוסטר הן KVM לא מנוהל עם root מלא, מ‑Nano של ליבה אחת וגיגה זיכרון ועד Mega של 10 ליבות ו‑24GB, על חומרת Intel Xeon Gold עם אחסון NVMe וכתובת IPv4 אחת כלולה. גישת root היא תנאי מוקדם לכל מה שכתוב כאן — באחסון שיתופי אי אפשר ליצור משתמשי מערכת או pools.

במקום לחזור על החישוב, השתמשו בשיטה שבמדריך הקיבולת ובנקודות ההתחלה האלה: Nano ו‑Micro מתאימות לאתר קטן בודד, סטייג'ינג או כלי פנימי, לא לתיק לקוחות. Starter עם 2 ליבות ו‑4GB מחזיקה בנוחות כמה אתרי תדמית בתנועה נמוכה. Basic ו‑Advanced, עם 6 עד 8GB, הן הבית הרגיל של סוכנות עם עשרה עד עשרים אתרים קטנים. מ‑Pro ומעלה נכנסים כשיש דייר או שניים עם מסחר אמיתי.

אזהרה שתופסת סוכנויות דווקא: הדיסק הוא לרוב התקרה הראשונה, לא הזיכרון. קבצי מדיה מצטברים, ואם אתם שומרים גם עותקי גיבוי מקומיים תגמרו 100GB מהר משחשבתם. בדקו df -h לפני שאתם מניחים שהבעיה בזיכרון. ובכנות: אם אתם לא רוצים להריץ עדכונים, לקרוא לוגים ולהגיב כשמשהו נשבר, VPS לא מנוהל הוא המוצר הלא נכון בשבילכם. אחסון מנוהל או אחסון משווקים קיימים בדיוק בשביל זה. חבילות ה‑VPS שלנו מניחות שאתם רוצים את שורת הפקודה.

מתי גדלתם מעבר ל‑VPS אחד

• ה‑swap בשימוש רציף וה‑journal מראה שה‑OOM killer סוגר תהליכי PHP.
• ה‑steal time ב‑top גבוה באופן עקבי, כלומר השרת הפיזי נמכר יתר על המידה ושום הגדרה מצדכם לא תתקן זאת.
• הדרישות של דייר אחד קובעות לכולם את גרסת ה‑PHP או את לוח השדרוגים.
• שחזור של אתר בודד לוקח יותר זמן ממה שהבטחתם ללקוחות.
• לקוח שואל מי עוד נמצא על השרת, ואתם לא רוצים לענות.
• התחלתם להימנע מהפעלה מחדש. פחד מהתשתית שלכם הוא סימן קיבולת.

המהלך הבא הוא בדרך כלל לא מכונה גדולה יותר, אלא הוצאה של הדייר הגדול או הרגיש ביותר ל‑VPS משלו והשארת הזנב הארוך במקום. כך שומרים על הכדאיות הכלכלית של האיחוד עבור מי שנהנה ממנה, ונותנים הפרדה למי שבאמת צריך אותה. בסופו של דבר, לארח כמה אתרים על VPS אחד כמו שצריך זה הרגל אחד: לכל אתר משתמש משלו, pool משלו, socket משלו, משתמש מסד נתונים משלו וגיבוי שאפשר לשחזר בנפרד.

שאלות נפוצות

כמה אתרים אפשר לארח על VPS אחד?

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

אפשר לארח כמה אתרים על VPS אחד בלי cPanel?

כן, וזה מה שרוב המפתחים עושים. server blocks ב‑Nginx יחד עם pool נפרד לכל אתר נותנים הפרדה טובה יותר מכמה פאנלים ולא עולים דמי רישוי. מה שמוותרים עליו הוא ממשק ללקוחות והעברת חשבונות קלה בין שרתים.

צריך כתובת IP נפרדת לכל אתר?

לא. אירוח מבוסס שם הוא סטנדרט כבר שני עשורים, ו‑SNI מאפשר ל‑IP אחד להגיש HTTPS להרבה דומיינים. החריגים נדירים: לקוחות TLS ישנים מאוד, ומקרים שבהם אתר צריך מוניטין דואר יוצא נפרד. כתובת IPv4 אחת מספיקה לעשרות אתרים.

pool אחד לכל האתרים זה באמת כל כך גרוע?

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

אפשר להריץ גרסאות PHP שונות לאתרים שונים על אותו שרת?

כן. מתקינים כמה חבילות FPM זו לצד זו (בדביאן ובאובונטו בדרך כלל דרך מאגר Sury), נותנים לכל אתר pool תחת הגרסה שהוא צריך, ומפנים את ה‑fastcgi_pass שלו ל‑socket המתאים. זו הדרך הנקייה למנוע מלקוח ישן אחד לחסום שדרוגים לכולם.

מה הדרך המהירה להוסיף אתר חדש אחרי שהשרת מוגדר?

סקריפט. סקריפט שמקבל שם אתר ודומיין ואז יוצר משתמש ותיקיות, כותב קובץ pool מתבנית, כותב server block, יוצר מסד נתונים ומשתמש, מבקש אישור וטוען מחדש את שני השירותים — הופך עבודה של חצי שעה לחצי דקה, ומונע דילוג על שלבים שגורם לבאגים בהרשאות.

אירוח כמה אתרים על VPS אחד פוגע בקידום אורגני?

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