25 אפליקציות מומלצות לשרת עצמי (Self-hosting) בשנת 2026
מחפשים מה להריץ על ה-VPS שלכם? רשימה ממוקדת של 25 אפליקציות מומלצות לשנת 2026. לכל יישום מצורפים נתוני צריכת RAM ודיסק אמיתיים, השירות שהוא מחליף והמלכודות שחשוב להכיר.
מה אתם בונים
לא מדובר ביישום אחד, אלא ברשימה ממוקדת. זהו המרכז לכל מה שמופיע באתר זה: עשרים וחמישה יישומים שבאמת כדאי להריץ על ה-VPS שלכם בשנת 2026, מקובצים לפי תפקידם. עבור כל אחד מהם תקבלו את השירות שהוא מחליף, נתון אמין של צריכת RAM ודיסק, והדבר האחד שיגרום לכם לבעיות אם תדלגו עליו. הקישורים מובילים למדריך המלא צעד-אחר-צעד, היכן שקיים כזה.
אני מנהל שרת VPS במשך חמש עשרה שנים, ואני מריץ את רוב היישומים הללו על השרתים הפרטיים שלי. לכן, נתוני המשאבים להלן משקפים את מה שהיישום צורך בפועל תחת עומס עבודה קטן ואמיתי, ולא את ה"מינימום" המופיע בדפי שיווק. התייחסו אליהם כאל תקציב, ולאחר מכן הוסיפו מרווח ביטחון.
דרישות קדם והמציאות כפי שהיא
כל יישום כאן רץ על שרת VPS מסוג KVM עם Ubuntu 24.04 נקי, בגישת root או sudo. אותה רשימה תעבוד באותה מידה על שרת פיזי בארון שלכם, ואם אתם שוקלים עלות חודשית מול רכישת זיכרון RAM פעם אחת, Proxmox בבית לעומת VPS מושכר מפרט את החישובים של חומרה וצריכת חשמל. כמעט כל היישומים מופצים כמכולות Docker, לכן התקינו Docker פעם אחת ותהיו מוכנים כמעט לכל הרשימה (שני החריגים, Cloudron ו־CasaOS, מותקנים ישירות על המארח עם סקריפטים ייעודיים, ראו את סעיף לוחות הבקרה):
curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker "$USER"
newgrp docker
docker run --rm hello-worldאם פקודות docker נכשלות עם permission denied while trying to connect to the Docker daemon socket, דילגתם על שלב הקבוצה או שלא פתחתם shell חדש; התנתקו והתחברו מחדש. אם docker compose מחזיר docker: 'compose' is not a docker command, סימן שיש לכם את הקובץ הבינארי העתיק; הסקריפט לעיל מתקין את תוסף ה-Compose המודרני, אותו מפעילים באמצעות docker compose (רווח, לא מקף).
שלוש עובדות קובעות את אופי הפעילות להלן. ראשית, זיכרון ה-RAM הוא המגבלה, לא הדיסק או ה-CPU. שרת VPS עם 1 GB זיכרון יריץ יישום קטן אחד ולא יותר. 4 GB הוא הטווח האידיאלי לשרת "אירוח עצמי של כמה שירותים". 2 GB הוא טווח ביניים בעייתי שבו מתחילים מעמיסים שירות שלישי, נתקלים ב-Out-Of-Memory שקט, ולא מבינים מדוע המכולה נעלמה; sudo dmesg יציג את שורת ה-Out of memory: Killed process שה-daemon בלע. שנית, כל שירות ציבורי זקוק לשם מתחם ולתעודה; כתובת IP חשופה עובדת לבדיקות, אך נכשלת ברגע שרוצים שאפליקציה בטלפון או דפדפן יבטחו בה. שלישית, שני פורטים קובעים חצי מהאפשרויות שלכם: פורט 80 נכנס חייב להגיע לשרת עבור אתגר התעודה הסטנדרטי HTTP-01 (אתגר DNS-01 עוקף זאת על ידי הוכחת שליטה באמצעות רשומת DNS, דבר שימושי כאשר פורט 80 חסום), ופורט 25 יוצא חסום על ידי רוב ספקיות האירוח, וזו הסיבה שדואר אלקטרוני נמצא ברשימת ה"לא מומלץ" בסוף.
קבצים ותמונות
- Nextcloud מחליף את Google Drive, Dropbox ו-Google Calendar בחבילה אחת. הקצו 1–2 GB RAM בתוספת נפח הקבצים שלכם. המכשול העיקרי: SQLite מתאים להדגמה אך הוא מלכודת בסביבת production; התקינו אותו על PostgreSQL כבר מההתחלה, שכן העברת מסד הנתונים לאחר שהמידע כבר קיים היא הדרך הנפוצה ביותר להשחתת התקנת Nextcloud. המדריך המלא Nextcloud על גבי VPS עם Docker, TLS וגיבויים מגדיר זאת נכון כבר מהפעם הראשונה.
- Immich מחליף את Google Photos, כולל אפליקציה לטלפון המעלה אוטומטית את גלריית התמונות ומבצעת חיפוש פנים ועצמים. הקצו 6 GB RAM; התיעוד של Immich מגדיר זאת כמינימום, כאשר 8 GB הם נפח נוח. מכולת ה-machine-learning היא החלק התובעני ביותר, ונדרש שטח דיסק השווה לנפח הספרייה שלכם בתוספת כ-20 אחוז עבור תמונות ממוזערות. המכשול: Immich משתמש ב-semantic versioning מאז הגרסה היציבה הראשונה, v2.0.0, באוקטובר 2025, מה ששומר שינויים שוברים לגרסאות major. מאחר שהפרויקט כבר עבר ל-v3, לעולם אל תבצעו
pullעיוור ל-latest, שכן זה יוביל אתכם ישירות לגרסת ה-major הבאה; קבעו גרסה (pin) וקראו את הערות השחרור לפני כל שדרוג. המדריך ספריית תמונות Immich באירוח עצמי מכסה את נתיב השדרוג הבטוח. אם רף ה-6 GB גבוה ממה שיש לשרת שלכם, המאמר השוואה בין PhotoPrism ל-Immich משווה בין השניים מבחינת צריכת זיכרון בפועל, אפליקציות לטלפון ופקודות הגיבוי הנדרשות לכל אחד לפני שתחליטו על פלטפורמה לספרייה שלכם. - Seafile מחליף את Dropbox עם מנוע הסנכרון המהיר ביותר מבין השלושה. הקצו כ-1 GB RAM. המכשול: Seafile מאחסן את הקבצים שלכם כבלוקים מבוססי תוכן (content-addressed blocks), ולא כקבצים רגילים על הדיסק. לכן, לא ניתן לעיין במידע באמצעות
lsוחובה לבצע גיבוי באמצעות הכלים הייעודיים של Seafile, ולא על ידי העתקת תיקייה.
סיסמאות
- Vaultwarden מחליף את המנוי בתשלום של Bitwarden, את LastPass ואת 1Password באמצעות שרת Rust קטן התומך בפרוטוקול של Bitwarden, כך שכל אפליקציה רשמית או תוסף דפדפן של Bitwarden יעבדו ללא הגדרות נוספות. הקצו 100–200 MB RAM וכמעט ללא שטח דיסק. המוקש: תיבה זו מכילה את כל הסיסמאות שלכם, לכן TLS וגיבויים אינם בגדר המלצה אלא המהות של השירות. הגדירו את ה-
ADMIN_TOKENכ-Argon2 hash, כיוון ש-token בטקסט גלוי בתוך קובץ ה-compose שלכם הוא הסיסמה לפאנל הניהול של השרת, המציג את כל המשתמשים ומאפשר שינוי הגדרות שרת; השארתו בטקסט גלוי חושפת אותו לכל מי שיכול לקרוא את הקובץ. המדריך ל-מנהל הסיסמאות Vaultwarden הוא נקודת ההתחלה הטובה ביותר לאירוח עצמי.
מדיה
- Jellyfin מחליף את Plex ואת Netflix עבור הספרייה הפרטית שלכם. הוא חופשי לחלוטין, אינו דורש חשבון, ואין בו חסימות בתשלום עבור הזרמה מרחוק. הקצו לו 1–2 GB RAM במצב המתנה, אך שימו לב שצריכת ה-CPU מזנקת בעת קידוד מחדש (transcoding). המכשול: קידוד תוכנתי של זרם 4K יגרום לקריסת שרת VPS קטן; הקצו לשרת האצה חומרתית (hardware acceleration) או שמרו את הקבצים בפורמט שהלקוחות שלכם יכולים לנגן ישירות (Direct Play), כך שהשרת רק יעביר את הנתונים. המדריך Jellyfin media server on a VPS מסביר את ההבדלים. לאחר שהשירות פועל, Halcyon הופך את אותה ספרייה לחנות השכרת סרטים משנות ה-90 בתוך הדפדפן; זהו הטריק היעיל והמשעשע ביותר שאני מכיר כדי לגרום לבני הבית לעיין במדפים במקום לגלול ללא מטרה.
- Navidrome מחליף את Spotify עבור מוזיקה אישית, ומזרים אותה לכל אפליקציה התואמת ל-Subsonic. הקצו לו 150–300 MB RAM; הוא כתוב ב-Go וכמעט אינו מורגש. המכשול: סריקת הספרייה הראשונה קוראת את ה-tags של כל קובץ ועשויה להימשך שעה באוסף גדול. תגיות ID3 שגויות יובילו לחוויית גלישה לקויה.
- Audiobookshelf מחליף את Audible ואת אפליקציית הפודקאסטים שלכם, תוך שמירה על מיקום הניגון בין מכשירים שונים. הקצו לו 200–500 MB RAM. המכשול: הוא מצפה למבנה תיקיות קפדני של תיקייה לכל ספר. ייבוא מתיקייה מבולגנת יפיק ספרייה מבולגנת ומזוהה חלקית, שקשה מאוד לתקן בדיעבד.
אוטומציה ובינה מלאכותית
- n8n מחליף את Zapier ו-Make באמצעות בונה תהליכי עבודה ויזואלי שבבעלותך, ללא חיוב לפי משימה. הקצו 400 MB עד 1 GB של RAM. המוקש: n8n מצפין אישורים שמורים באמצעות מפתח שהוא מייצר בהרצה הראשונה. אם תאבדו את המפתח, או תשכחו להגדיר את
N8N_ENCRYPTION_KEYותתנו לו לייצר מפתח חדש, כל האישורים השמורים יהפכו לבלתי קריאים ותצטרכו להזין אותם מחדש. המדריך אירוח עצמי של n8n עם HTTPS מקבע את המפתח ומציב תעודה אמיתית לפני כתובות ה-webhook. - Ollama מחליף מנוי ל-ChatGPT לצורך הסקה (inference) מקומית ופרטית של מודלי שפה (LLM). תכננו את המשאבים לפי המודל: מודל של 7–8B דורש כ-8 GB של RAM. גודלו על הדיסק תלוי בקוונטיזציה (quantization): בערך 4 עד 5 GB להורדה הסטנדרטית של 4-bit, ו-13 GB ומעלה לבנייה מלאה בדיוק fp16. המוקש: בשרת VPS מבוסס CPU בלבד, ההסקה תקינה אך איטית – צפו לקצב של מילים לשנייה, לא לתגובות המיידיות של API מאוחסן. תאמו ציפיות או שכרו שרת עם GPU. המדריך הרצת Ollama לאירוח עצמי של LLM כולל נתונים ריאליים.
תקשורת
- Rocket.Chat מחליף את Slack עבור צוות, עם שרשורים, שיחות ואינטגרציות. הקצו 2 GB RAM ומעלה, כיוון שהוא רץ על MongoDB וזהו הרכיב הכבד ביותר. המכשול: כל גרסה ראשית של Rocket.Chat תומכת בטווח מצומצם של גרסאות MongoDB (גרסה 8.x דורשת MongoDB 8.0 ומעלה, בעוד 7.x רצה על 6.0 או 7.0). הנחיות השדרוג של Rocket.Chat מורות לעבור בין גרסאות ראשיות לפי הסדר; דילוג על גרסה עלול להוביל לניתוק מסד הנתונים, לכן יש לשדרג צעד אחר צעד. המדריך Rocket.Chat עם Docker Compose מפרט את תהליך השדרוג בין הגרסאות.
- Matrix (Synapse) מחליף את Slack ו-Discord ברשת פדרטיבית ומוצפנת מקצה לקצה, שבה אתם הבעלים של ה-homeserver שלכם. הקצו 1–2 GB RAM, כמות שגדלה ככל שמצטרפים לחדרים ציבוריים גדולים. המכשול: צריכת הזיכרון של Synapse מזנקת בחדרים פדרטיביים גדולים, והוא חייב לרוץ על PostgreSQL. ברירת המחדל של SQLite מתאימה רק לבדיקות של משתמש יחיד וקורסת ברגע שמפעילים פדרציה. אם Synapse מרגיש כבד מדי, השרתים הקלים יותר Conduit או Dendrite משתמשים באותו פרוטוקול.
רשת וגישה
- WireGuard מחליף VPN מסחרי ומספק מנהרה פרטית לכתובת ה-IP שלכם ולשירותים האחרים שלכם. הוא כמעט אינו צורך משאבים, תופס פחות מ-50 MB, והצפנה רצה ברמת ה-kernel. המוקש: בווירטואליזציה מבוססת מכולות (OpenVZ, חלק מ-LXC), המודול נכשל עם
RTNETLINK answers: Operation not supported; עדיף להשתמש ב-KVM. המדריך ל-הקמת WireGuard VPN בניהול עצמי הוא נקודת הייחוס, ושיוך שירותים למנהרה הוא הדרך להרחיק אותם לחלוטין מהאינטרנט הציבורי. אם אינכם מעוניינים לערוך ידנית קובץ הגדרות peer עבור כל מכשיר חדש, הרצת Tailscale subnet router על ה-VPS תפרסם את כל טווח הכתובות הפרטי לשאר המכונות שלכם, ברגע שתאשרו את הניתוב ותגדירו ש-IP forwarding יישמר לאחר reboot. - Traefik מחליף הגדרות ידניות של virtual hosts ב-nginx וחידוש תעודות ידני; הוא מזהה את המכולות שלכם לפי ה-labels של Docker ומנפיק תעודות Let's Encrypt באופן אוטומטי. צריכת הזיכרון היא כ-100 MB. המוקש: מודל ההגדרות מבוסס ה-labels מבלבל מאוד בהתחלה, ו-label אחד שגוי משאיר יישום ללא ניתוב וללא שגיאה ברורה. המדריך ל-Traefik reverse proxy עבור מספר יישומי Docker נכתב בדיוק עבור הרצת כמה מהיישומים בדף זה מאחורי נקודת כניסה אחת.
- AdGuard Home מחליף מכשיר Pi-hole וסינון DNS בתשלום, וחוסם פרסומות ומעקבים עבור כל מכשיר ברשת שלכם ברמת ה-DNS. צריכת הזיכרון היא 100–150 MB. המוקש: הוא דורש בעלות על פורט 53, שמתנגש עם
systemd-resolvedב-Ubuntu; הוא לא יופעל עםlisten udp 0.0.0.0:53: bind: address already in useעד שתפנו את הפורט תחילה.
ניטור
- Uptime Kuma מחליף את Pingdom, UptimeRobot ו-StatusPage באמצעות לוח מחוונים נקי והתראות כמעט לכל ערוץ. הקצו עבורו 150–300 MB RAM. המלכוד, שכולם תמיד מפספסים: נטרו את שרת ה-production שלכם משרת אחר. Uptime Kuma שרץ על אותו שרת שהוא מנטר לא יוכל להודיע לכם כשהשרת הזה קורס. המדריך ל-ניטור סטטוס ב-Uptime Kuma מכסה את נושא המיקום החיצוני.
- Zabbix מחליף את Datadog וחבילות ניטור ארגוניות, עם מטריקות מבוססות סוכן (agent), טריגרים והיסטוריה מעמיקה. הקצו עבורו 2 GB RAM ומעלה, בתוספת מסד נתונים משלו. המלכוד: Zabbix הוא כלי עוצמתי וכבד מאוד להגדרה; הוא מוגזם עבור ניטור של שלוש מכולות, אך הוא הכלי הנכון עבור צי שרתים. התחילו עם Uptime Kuma; עברו ל-שרת ניטור Zabbix כאשר באמת תהיה לכם תשתית לנטר.
Prometheus ו-Grafana חסרים ברשימה זו בכוונה: הם כלים מצוינים לקנה מידה של צי שרתים, אך הם כבדים יותר להרצה ולכוונון ממה שנדרש עבור stack אישי של שניים או שלושה שרתים, ו-Uptime Kuma יחד עם Zabbix עונים על אותן שאלות בקנה מידה זה עם פחות תחזוקה.
לוחות בקרה וממשקי ניהול
כלים אלו משנים את מודל העבודה; במקום להריץ קובצי compose באופן ידני, לוח בקרה מנהל עבורך את היישומים.
- Cloudron מחליף את הצורך בהתקנה ידנית בחנות יישומים מלוטשת, עם TLS אוטומטי וגיבויים מובנים. יש להקצות לפחות 2 GB RAM, ורצוי 4 GB. המגבלה: המערכת דעתנית ומבקשת שליטה מלאה על השרת. היא מותקנת על גבי שרת Ubuntu נקי באמצעות סקריפט ייעודי (
cloudron-setup) ולא כמכולה. התיעוד שלה שולל שימוש ב-ARM, LXC, Docker וסביבות OpenVZ. השימוש חינמי עבור עד שני יישומים, ומעבר לכך נדרש תשלום. - CasaOS מחליף ממשקי ניהול מסורבלים ברשת יישומים ידידותית, קלה וחינמית. הוא מותקן ישירות על המארח באמצעות סקריפט (
curl -fsSL https://get.casaos.io | sudo bash), לא כמכולה, ומריץ את היישומים שלך בתוך Docker. יש להקצות כ-150 עד 300 MB עבור CasaOS עצמו. המגבלה: המערכת תוכננה לרשת ביתית מהימנה ואינה מוקשחת לחשיפה לאינטרנט הציבורי; אין לחשוף אותה ישירות, אלא לגשת אליה דרך WireGuard. - Coolify מהווה תחליף ל-Heroku, Vercel ו-Netlify, ומאפשר פריסה מבוססת git-push, ניהול מסדי נתונים וסביבות תצוגה מקדימה על השרת שלך. יש להקצות לפחות 2 GB RAM. המגבלה: זהו פרויקט צעיר שמתפתח במהירות, לכן מומלץ לקבע גרסאות ולקרוא את הערות השחרור (release notes) לפני כל שדרוג. ה-השוואה בין Cloudron ל-CasaOS ו-Coolify מפרטת איזו מהמערכות מתאימה לצרכים של כל משתמש.
כלי פיתוח ופרודוקטיביות
- Gitea (או Forgejo) מחליף את GitHub עבור מאגרים פרטיים, ניהול משימות (issues) ו-CI. הקצו 200–500 MB RAM. המוקש: Forgejo הוא ה-fork המנוהל על ידי הקהילה של Gitea והוא המומלץ כיום על ידי רבים; שניהם מצוינים, אך בחרו אחד וגבו את המאגרים יחד עם מסד הנתונים. גיבוי מאגר ללא מסד הנתונים יגרום לאובדן כל ה-issues וה-pull requests.
- Paperless-ngx מחליף ארונות תיוק וסורקי מסמכים בתשלום, ומבצע OCR לכל מסמך כדי להפוך אותם לניתנים לחיפוש. הקצו כ-1 GB RAM, עם קפיצות בשימוש ב-CPU בזמן ביצוע ה-OCR. המוקש: תוצאות ה-OCR תלויות באיכות הסריקות שלכם, ועיבוד מחדש של ארכיון גדול הוא תהליך איטי; בצעו כוונון לפני ייבוא מרוכז של עשר שנות מסמכים.
- Actual Budget מחליף את YNAB ואת Mint שנסגר, ומציע ניהול תקציב מהיר, מקומי ופרטי בשיטת המעטפות. הקצו כ-150 MB RAM. המוקש: סנכרון בנקאי אוטומטי מובנה אך אופציונלי, והוא עובד רק לאחר הרשמה לספק אזורי כגון SimpleFIN Bridge או Enable Banking והוספת פרטי ה-API שלכם; ללא הגדרות אלו, תצטרכו לייבא עסקאות באופן ידני.
- FreshRSS מחליף את Feedly ואת Google Reader המנוח, ומציע קורא עדכונים (feed reader) מהיר ופרטי עם אפליקציות מובייל. הקצו כ-150 MB RAM. המוקש: הגדירו רענון עדכונים מבוסס cron, אחרת העדכונים יתבצעו רק כאשר תפתחו את הדף.
- BookStack מחליף את Notion ואת Confluence לתיעוד, ומארגן את התוכן במדפים, ספרים ודפים. הקצו כ-500 MB RAM עבור PHP ו-MySQL. המוקש: המערכת מבנה את התוכן בדרך משלה ולא כהערות חופשיות, דבר שחלק מהמשתמשים אוהבים ואחרים מוצאים כנוקשה; נסו אותה לפני שתעבירו אליה את כל ה-wiki שלכם.
- Home Assistant מחליף את SmartThings ותריסר אפליקציות יצרן, ומאחד את הבית החכם שלכם באופן מקומי. הקצו כ-1 GB RAM. המוקש: חלק גדול מהיכולות שלו דורש גישה לרשת המקומית למכשירים שלכם, לכן הוא פועל בצורה טבעית יותר על חומרה בבית מאשר על VPS מרוחק; הריצו את לוח הבקרה מרחוק ובצעו גישור (bridge) חזרה אם אתם חייבים.
התקנה לדוגמה
כדי להפוך את הדברים למוחשיים, להלן המבנה המלא של אירוח עצמי: קובץ compose, תעודה אמיתית וגיבוי. הדוגמה כאן היא Uptime Kuma, אך כל יישום ברשימה פועל לפי אותו דפוס.
services:
uptime-kuma:
image: louislam/uptime-kuma:2
container_name: uptime-kuma
volumes:
- ./data:/app/data
ports:
- "127.0.0.1:3001:3001"
restart: unless-stoppeddocker compose up -d
docker compose logs -fשימו לב ל-127.0.0.1:; היישום מאזין רק ל-localhost, ו-reverse proxy כגון Traefik או nginx מבצע TLS termination לפניו. קישור ישיר ל-0.0.0.0:3001 הוא הדרך שבה משתמשים חושפים בטעות לוח ניהול לא מוצפן לכל רחבי האינטרנט.
מה לא כדאי לארח עצמית (עדיין)
- דואר אלקטרוני. זו האמת הכנה. פורט 25 יוצא חסום על ידי רוב ספקי ה-VPS; אתם תראו
Connection timed outמ-telnet aspmx.l.google.com 25ואין שום דבר שניתן לתקן בצד שלכם, זו מדיניות הספק. חלק מהספקים יסירו את החסימה אם תבקשו (AWS, למשל, מאפשרת לבקש את הסרת ההגבלה), אך זו בקשה, לא מתג שניתן להפעיל. גם כשפורט 25 פתוח, כתובת IP חדשה ללא מוניטין, רשומת PTR, SPF, DKIM ו-DMARC תגרום להודעות שלכם להגיע ל-spam או להידחות על הסף. זו עבודה אמיתית ומתמשכת, לא פרויקט לסוף שבוע. אם אתם נחושים בדעתכם, עשו זאת בעיניים פקוחות בעזרת המדריך אירוח עצמי של דואר אלקטרוני עם Mailcow, והתכוננו לנטר את יכולת המסירה (deliverability) במשך חודשים. - כל מה שאינכם יכולים לגבות ולשחזר באופן אמין. אם מעולם לא ביצעתם שחזור ניסיון, אין לכם גיבוי, יש לכם תקווה. אל תשימו נתונים שאין להם תחליף, העותק היחיד של התמונות שלכם או החשבונות שלכם, על שירות שטרם הוכח תהליך השחזור שלו.
- העותק היחיד של תלות קריטית. שרת DNS מאוחסן עצמית שאם הוא קורס, הוא לוקח איתו את כל האינטרנט של הרשת שלכם, הוא פרויקט ראשון גרוע. שמרו על גיבוי (fallback) במעלה הזרם (upstream).
- מערכות בטיחות בזמן אמת. אזעקות לבית, התראות רפואיות, או כל דבר שבו חמש דקות של השבתה הן בעיה אמיתית, לא שייכים לשרת תחביבים שאתם משדרגים בערבי יום ראשון.
כיצד לבחור את היישום הראשון, ושני תנאי הסף
בחרו ביישום שמבטל חשבונית שמעיקה עליכם או פותר דאגת פרטיות שאתם חשים בפועל. בפועל, ההתקנות הראשונות הטובות ביותר הן Vaultwarden ו-Uptime Kuma: שניהם קלי משקל, שניהם שימושיים באופן מיידי, ושניהם סלחניים אם טעיתם. הביאו אחד מהם למצב עבודה מלא – התקנה, תעודה, גיבוי ובדיקת שחזור – לפני שתוסיפו יישום שני. המיומנות שאתם בונים היא תפעול, לא לחיצה על כפתור התקנה.
ישנם שני דברים שאינם נתונים למשא ומתן עבור כל יישום שצוין לעיל, ללא יוצא מן הכלל:
- TLS לכל שירות ציבורי. שירות שחשוף ב-plaintext או בכתובת IP בלבד הוא הדגמה, לא פריסה (deployment). הציבו לפניו תעודה אמיתית באמצעות Certbot ו-Let's Encrypt על nginx, או תנו ל-Traefik לבצע זאת אוטומטית. לאחר מכן, הקשיחו את נקודת הכניסה עם Fail2ban עבור SSH ב-Ubuntu 24.04.
- גיבויים ששוחזרו בפועל. בצעו אוטומציה לגיבוי לילי שכולל את מסד הנתונים ואת נפח הנתונים (data volume) יחד, שלחו אותו מחוץ לשרת, ופעם בחודש שחזרו אותו לשרת VPS זמני כדי לוודא שהוא תקין. היום שבו הדיסק שלכם יקרוס הוא היום הגרוע ביותר לגלות שהגיבוי היה ריק.
בצעו את שני אלו נכון, ואירוח עצמי יהיה תענוג. דלגו עליהם, וזה רק עניין של זמן עד לתקלה.
האפשרויות נעות בין הפרקטי לאבסורדי, החל מ-שרת Minecraft על VPS עבור המשפחה ועד ל-מרכז הנתונים הכי פחות יעיל בעולם, אם אתם נהנים מסיפורי אזהרה.
FAQ
מה כדאי לארח באופן עצמי בתור התחלה?
Vaultwarden. מנהל סיסמאות מספק ערך יומיומי, מחליף מנוי בתשלום, ומחייב אותך ללמוד את כל תהליך העבודה: Docker, reverse proxy, TLS וגיבויים, וכל זאת על יישום קטן מספיק כדי שתוכל להקים אותו מחדש בתוך עשר דקות אם תגרום לתקלה. Uptime Kuma הוא בחירה מצוינת לשירות שני, כדי שתגלה על תקלות לפני שהמשתמשים שלך יגלו.
כמה משאבי VPS אני באמת צריך?
עבור יישום קטן אחד, 1 GB של RAM מספיק. עבור שרת נוח להרצת מספר שירותים, כדאי לשאוף ל-4 GB. בטווח הביניים של 2 GB, משתמשים נתקלים לעיתים קרובות ב-Out-Of-Memory שגורם להפסקת מכולות (containers) ללא התראה, מבלי להבין את הסיבה. ה-RAM הוא כמעט תמיד המגבלה; הוסף נפח דיסק בהתאם לכמות הנתונים שאתה מתכנן לאחסן, וצפה לכך ש-Immich, Ollama וכל יישום עם מסד נתונים גדול ידרשו את מירב המשאבים משניהם.
מה לא כדאי לארח באופן עצמי?
דואר אלקטרוני, בראש ובראשונה. פורט 25 יוצא חסום אצל רוב ספקיות הענן, והבטחת הגעת הודעות ליעד היא מאבק יומיומי. מעבר לכך, כל מה שאינך יכול לגבות ולשחזר בצורה אמינה, וכל נקודת כשל יחידה שהשבתתה גורמת לנזק ממשי, כמו שרת DNS ללא גיבוי או מערכת אבטחה ביתית. כל שאר השירותים ברשימה זו הם הוגנים למשחק.
האם אני צריך Docker עבור כל זה?
לא, אבל כדאי לך. לכל יישום כאן, למעט Cloudron ו-CasaOS, יש תמונת Docker; השניים הללו מותקנים ישירות על המארח עם סקריפטים משלהם ומריצים את היישומים בתוך מכולות עבורך. עבור השאר, Docker מספק התקנות נקיות, הסרות נקיות, קיבוע גרסאות פשוט וניידות למארח חדש. כמה יישומים (כמו WireGuard או Zabbix) ניתנים להתקנה גם באופן מקורי דרך apt אם אתה מעדיף זאת. ברגע שאתה מכיר קובץ compose אחד, אתה מכיר את כולם, וזו הסיבה שהרשימה כולה הופכת לנגישה.
איך שומרים על הכל מאובטח?
ארבעה הרגלים מכסים את רוב הנושא: הצב TLS לפני הכל, נעל את SSH עם כניסה מבוססת מפתח בלבד ו-חסימת ניסיונות brute-force באמצעות Fail2ban, חשוף לציבור רק את הפורטים שאתה באמת צריך וגש לשאר דרך WireGuard VPN, ועדכן באופן קבוע תוך קריאת הערות השחרור כדי ששדרוג לעולם לא יפתיע אותך. גיבויים הם ההרגל החמישי; הם תוכנית ההתאוששות שלך כאשר טעות חומקת מעבר לארבעת הראשונים.