מה כדאי להריץ ב-self-host בשנת 2026

מה אתם בונים

לא אפליקציה אחת — אלא רשימה מצומצמת. זהו המרכז לכל שאר התכנים באתר זה: עשרים-five אפליקציות שבאמת שווה להריץ על ה-VPS האישי שלכם בשנת 2026, מקובצות לפי התפקיד שלהן. עבור כל אחת תוכלו לראות את השירות שהיא מחליפה, הערכה כנה של צריכת ה-RAM והדיסק, והדבר היחיד שיכול להכשיל אתכם אם תדלגו עליו. הקישורים מובילים למדריך המלא והשלב-אחר-שלב במידה וקיים כזה.

אני מפעיל VPS host במשך חמש-עשרה שנים, ומריץ את רוב האפליקציות הללו על השרתים שלי. לכן, מספרי המשאבים המופיעים להלן הם מה שהאפליקציה משתמשת בהם בפועל תחת עומס אמיתי קטן, ולא ה-"minimum" מדף שיווקי. התייחסו אליהם כאל תקציב, ואז הוסיפו מרווח ביטחון (headroom).

דרישות קדם והמציאות הכנה

כל אפליקציה כאן רצה על Ubuntu 24.04 KVM VPS חדש עם root או sudo. כמעט כולן מגיעות כ-Docker containers, לכן התקינו את Docker פעם אחת ותהיו מוכנים לכל הרשימה:

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, דילגתם על שלב ה-group או שלא פתחתם shell חדש — התנתקו והתחברו מחדש. אם docker compose מחזיר את docker: 'compose' is not a docker command, יש לכם את ה-standalone binary הישן; הסקריפט לעיל מתקין את ה-Compose plugin המודרני, שנקרא באמצעות docker compose (רווח, לא מקף).

שלוש מציאותות קובעות את המבנה של כל מה שמופיע להלן. ראשית, ה-RAM הוא המגבלה, לא הדיסק או ה-CPU. VPS עם 1 GB מריץ אפליקציה קטנה אחת ולא יותר. 4 GB הם ה-sweet spot האמיתי עבור שרת "self-host לכמה דברים". 2 GB הם המצב הבעייתי שבו מתחילים מוסיפים שירות שלישי, נתקלים ב-Out-Of-Memory kill שקט ולא מבינים מדוע ה-container פשוט נעלם — sudo dmesg מראה את שורת ה-Out of memory: Killed process שנבלעה על ידי ה-daemon. שנית, כל דבר ציבורי זקוק לשם ולתעודה (certificate) — כתובת IP בלבד עובדת לבדיקות, אך נכשלת ברגע שתרצו לאפליקציה בטלפון או לדפדפן לבטוח בה. שלישית, שני פורטים קובעים חצי מהאפליקציות: פורטים 80 ו-443 חייבים להגיע לשרת עבור TLS אוטומטי, ופורט 25 יוצא (outbound) חסום על ידי רוב הספקים, וזו הסיבה שאימייל נמצא ברשימת ה-"do not" בסוף.

קבצים ותמונות

• Nextcloud מחליפה את Google Drive, Dropbox ו-Google Calendar בחבילה אחת. תקציב: 1–2 GB RAM בנוסף לנפח הקבצים שלכם. הבעיה המרכזית: SQLite מתאים לדמו בלבד ומהווה מלכודת בייצור (production) — התקינו אותה על PostgreSQL כבר מההפעלה הראשונה, מכיוון שמיגור בסיס הנתונים לאחר שהמידע כבר בפנים הוא הדרך הנפוצה ביותר להרוס Nextcloud. המדריך המלא Nextcloud on a VPS with Docker, TLS and backups מגדיר אותה נכון בפעם הראשונה.
• Immich מחליפה את Google Photos, כולל אפליקציית הטלפון שמבצעת auto-upload לגלריה, וחיפוש לפי פנים וחפצים. תקציב: 6 GB RAM — התיעוד של Immich קורא לזה ה-minimum, 8 GB הם נוחים, ו-container ה-machine-learning הוא החלק שצורב משאבים — והדיסק צריך להיות שווה לנפח הספרייה שלכם פלוס כ-20% עבור thumbnails. הבעיה: Immich עדיין כוללת שינויים שוברים (breaking changes) בין גרסאות, לכן לעולם אל תבצעו pull עיוור של latest; קבעו גרסה (pin a version) וקראו את ה-release notes לפני כל שדרוג. המדריך self-hosted Immich photo library מכסה את נתיב השדרוג הבטוח.
• Seafile מחליפה את Dropbox עם מנוע הסנכרון המהיר ביותר מבין השלושה. תקציב: כ-1 GB RAM. הבעיה: Seafile שומרת את הקבצים שלכם כ-content-addressed blocks, ולא כקבצים רגילים בדיסק, לכן לא תוכלו לגלוש בנתונים באמצעות ls ועליכם לגבות דרך הכלים של Seafile עצמה, ולא על ידי העתקת תיקייה.

סיסמאות

• Vaultwarden מחליפה את המסלול בתשלום של Bitwarden, את LastPass ואת 1Password באמצעות שרת Rust קטן שמדבר ב-Bitwarden protocol, כך שכל אפליקציה רשמית של Bitwarden ותוסף דפדפן פשוט יעבדו. תקציב: 100–200 MB RAM וכמעט ללא שימוש בדיסק. הבעיה: השרת הזה מחזיק כל סיסמה שבבעלותכם, לכן TLS וגיבויים אינם אופציונליים כאן, הם המטרה כולה — והגדירו את ADMIN_TOKEN כ-Argon2 hash, מכיוון ש-plaintext token בקובץ ה-compose שלכם הוא מפתח מאסטר שיושב בטקסט גלוי. המדריך Vaultwarden password manager הוא ה-self-host הראשון הטוב ביותר האפשרי.

מדיה

• Jellyfin מחליפה את Plex ועבור הספרייה שלכם, את Netflix — פתוחה לחלוטין, ללא חשבון וללא תשלום עבור streaming מרחוק. תקציב: 1–2 GB RAM במצב idle, אך ה-CPU מזנק ב-transcode. הבעיה: software transcoding של 4K stream יתחמם VPS קטן; או שתתנו לשרת hardware acceleration או שתשאירו את הקבצים בפורמט שהלקוחות שלכם יכולים להפעיל ישירות (Direct Play), כך שהשרת רק יעביר bytes. המדריך Jellyfin media server on a VPS מסביר מה זה מה.
• Navidrome מחליפה את Spotify עבור המוזיקה שלכם, עם streaming לכל אפליקציה תואמת Subsonic. תקציב: 150–300 MB RAM — היא כתובה ב-Go וכמעט לא ניכרת בשימוש. הבעיה: סריקת הספרייה הראשונה קוראת את ה-tags של כל קובץ ויכולה לקחת שעה באוסף גדול, ו-ID3 tags גרועים יוצרים חווית גילוף גרועה.
• Audiobookshelf מחליפה את Audible ואת אפליקציית הפודקאסטים שלכם, תוך שמירה על מיקום ההשמעה בין מכשירים. תקציב: 200–500 MB RAM. הבעיה: היא מצפה למבנה תיקיות קשיח של תיקייה לכל ספר, ותיקיית import מבולגנת תייצר ספרייה מבולגנת וחצי-זוהה שקשה מאוד לתקן בדיעבד.

אוטומציה ו-AI

• n8n מחליפה את Zapier ו-Make עם בונה workflow ויזואלי שבבעלותכם, ללא חיוב לפי משימה. תקציב: 400 MB–1 GB RAM. הבעיה: n8n מצפינה credentials שמורים עם מפתח שהיא מייצרת בהפעלה הראשונה, ואם תאבדו את המפתח הזה — או תשכחו להגדיר את N8N_ENCRYPTION_KEY ותתנו לה לייצר מחדש — כל ה-credentials השמורים יהיו בלתי ניתנים לקריאה ותצטרכו להזין את כולם מחדש. המדריך self-hosted n8n with HTTPS מקבע את המפתח ומציב תעודה אמיתית לפני כתובות ה-webhook.
• Ollama מחליפה מנוי ChatGPT עבור inference מקומי ופרטי של LLM. התקציב תלוי במודל: מודל 7–8B דורש כ-8 GB RAM, וכל מודל תופס 4–8 GB בדיסק. הבעיה: ב-VPS עם CPU בלבד, ה-inference איטי — חשבו על מילים לשנייה, לא על תגובות מיידיות כמו ב-API מאויית, לכן קבעו ציפיות, או שכרו שרת עם GPU. המדריך run Ollama to self-host an LLM מספק מספרים ריאליים.

תקשורת

• Rocket.Chat מחליפה את Slack עבור צוות, עם threads, שיחות ואינטגרציות. תקציב: 2 GB RAM ומעלה, מכיוון שהיא רצה על MongoDB וזה הרכיב הכבד. הבעיה: Rocket.Chat קובעת גרסת MongoDB major ספציפית לכל גרסה, ודילוג על גרסה במהלך שדרוג הוא הדרך שבה בסיס הנתונים שלכם נשאר תקוע — שדרגו צעד אחר צעד. המדך Rocket.Chat with Docker Compose מלווה את סולם הגרסאות.
• Matrix (Synapse) מחליפה את Slack ו-Discord ברשת מבוזרת (federated) עם הצפנה מקצה לקצה שבה אתם הבעלים של ה-homeserver. תקציב: 1–2 GB RAM שגדלים ככל שתצטרפו לחדרים ציבוריים גדולים. הבעיה: צריכת הזיכרון של Synapse גדלה משמעותית בחדרים מבוזרים גדולים, והיא חייבת לרוץ על PostgreSQL — ה-SQLite ברירת המחדל מתאים רק לבדיקה של משתמש יחיד ונכשל ברגע שמתחילים federation. אם Synapse מרגיש כבד מדי, השרתים הקלים יותר Conduit או Dendrite מדברים באותו פרוטוקול.

Networking וגישה

• WireGuard מחליפה VPN מסחרי, ומעניקה לכם מנהרה פרטית לכתובת ה-IP שלכם ולשירותים האחרים שלכם. תקציב: כמעט כלום — פחות מ-50 MB והקריפטוגרפיה רצה בתוך ה-kernel. הבעה: בווירטואליזציה מבוססת containers (כמו OpenVZ או חלק מ-LXC), המודול נכשל עם RTNETLINK answers: Operation not supported; אתם רוצים KVM. המדריך self-hosted WireGuard VPN הוא המקור, וחיבורו לשירותים שמוגדרים בתוך המנהרה הוא הדרך לשמור על הדברים מחוץ לאינטרנט הציבורי לחלוטין.
• Traefik מחליפה את הגדרות ה-virtual hosts של nginx שנכתבו ידנית ואת חידוש התעודות הידני — היא מגלה את ה-containers שלכם לפי ה-Docker labels שלהם ומשיגה תעודות Let's Encrypt באופן אוטומטי. תקציב: כ-100 MB RAM. הבעיה: מודל הקונפיגורציה מבוסס ה-labels הוא מבלבל מאוד בהתחלה, ותגית אחת שגויה תשאיר אפליקציה ללא ניתוב ללא שגיאה ברורה. המדריך Traefik reverse proxy for multiple Docker apps נבנה בדיוק עבור הרצת מספר אפליקציות מהרשימה הזו מאחורי נקודת כניסה אחת.
• AdGuard Home מחליפה מכשיר Pi-hole וסינון DNS בתשלום, וחוסמת פרסומות ועוקבים עבור כל מכשיר ברשת שלכם בשכבת ה-DNS. תקציב: 100–150 MB RAM. הבעיה: הוא זקוק לבעלות על פורט 53, שמתנגש עם systemd-resolved ב-Ubuntu — הוא נכשל בהפעלה עם listen udp 0.0.0.0:53: bind: address already in use עד שתשחררו את הפורט תחילה.

Monitoring

• Uptime Kuma מחליפה את Pingdom, UptimeRobot ו-StatusPage עם דשבורד נקי והתראות כמעט לכל ערוץ. תקציב: 150–300 MB RAM. הבעיה, והיא זו שאנשים תמיד מפספסים: נמנטרו את השרת שלכם משרת אחר — Uptime Kuma שרץ על אותו שרת שהוא עוקב אחריו לא יכול להגיד לכם מתי השרת הזה קורס. המדריך Uptime Kuma status monitoring מכסה מיקום חיצוני.
• Zabbix מחליפה את Datadog וערכות ניטור ארגוניות, עם מדדים עמוקים מבוססי agent, triggers והיסטוריה. תקציב: 2 GB RAM ומעלה, בנוסף לבסיס הנתונים שלו. הבעיה: Zabbix הוא עוצמתי וכבד מאוד להגדרה — הוא overkill למעקב אחרי שלושה containers, אך הכלי הנכון עבור צי של שרתים. התחילו עם Uptime Kuma; עברו ל-Zabbix monitoring server כשיהיה לכם באמת תשתית לנטר.

Prometheus ו-Grafana חסרים מרשימה זו בכוונה: הם כלי מצוינים בקנה מידה של fleet, אך הם כבדים יותר להרצה וכוונון ממה שסט אישי של שני או שלושה שרתים מצדיק, ו-Uptime Kuma פלוס Zabbix עונים על אותן שאלות בקנה מידה זה עם פחות תחזוקה.

Dashboards ולוחות בקרה

אלו משנים את המודל כולו — במקום להריץ קבצי compose ידנית, לוח בקרה מנהל את האפליקציות עבורכם.

• Cloudron מחליפה את המשפט "הלוואי שזה היה בלחיצה אחת" עם חנות אפליקציות מלוטשת, TLS אוטומטי וגיבויים מובנים. תקציב: 2 GB RAM לפחות, 4 GB בנוחות. הבעיה: הוא בעל דעה קשיחה (opinionated) ורוצה להחזיק את כל השרת, והוא חינם רק עד שתי אפליקציות — מעבר לכך זה מוצר בתשלום.
• CasaOS מחליפה דשבורד homelab מבולגן עם רשת אפליקציות ידידותית, חינם וקל משקל. תקציב: כ-150 עד 300 MB עבור CasaOS עצמו. הבעיה: הוא תוכנן לרשת ביתית מהימנה ואינו מוגן עבור האינטרנט הציבורי — אל תחשפו אותו ישירות; גשו אליו דרך WireGuard.
• Coolify מחליפה את Heroku, Vercel ו-Netlify — פריסות git-push, בסיסי נתונים ותצוגות מקדימות על השרת שלכם. תקציב: 2 GB RAM לפחות. הבעיה: זהו פרויקט צעיר שמתקדם מהר, לכן קבעו גרסאות וקראו את ה-release notes לפני שדרוג. ההשוואה Cloudron vs CasaOS vs Coolify comparison מפרטת איזה מהשלושה מתאים לכל אדם.

כלי פיתוח ופריון

• Gitea (או Forgejo) מחליפה את GitHub עבור מאגרי קוד פרטיים, issues ו-CI. תקציב: 200–500 MB RAM. הבעיה: Forgejo הוא ה-fork המנוהל על ידי הקהילה של Gitea והוא זה שרבים ממליצים עליו כעת; שניהם מצוינים, אך בחרו אחד וגבו את ה-repositories ואת בסיס הנתונים יחד — גיבוי repo ללא בסיס הנתונים מאבד כל issue וכל pull request.
• Paperless-ngx מחליפה ארון קלסרים וסורקי מסמכים בתשלום, עם OCR לכל דבר כך שהמסמכים שלכם יהיו ניתנים לחיפוש. תקציב: כ-1 GB RAM, עם קפיצות CPU במהלך ה-OCR. הבעיה: תוצאות ה-OCR טובות רק ככל שהסריקות שלכם טובות, ועיבוד מחדש של ארכיון גדול הוא איטי — כוונו זאת לפני שייבאו בכמות גדולה עשרת שנות נייר.
• Actual Budget מחליפה את YNAB ו-Mint עם תקצוב מעטפות מקומי, מהיר ופרטי. תקציב: כ-150 MB RAM. הבעיה: סנכרון בנק אוטומטי הוא תוספת נפרדת עם הגדרה משלה, לכן מתוך הקופסה מייבאים עסקאות ידנית.
• FreshRSS מחליפה את Feedly ואת Google Reader שנעלם — קורא פידים מהיר ופרטי עם אפליקציות לנייד. תקציב: כ-150 MB RAM. הבעיה: הגדירו רענון פידים מבוסס cron, אחרת הפידים יתעדכנו רק כשבמקרה תפתחו את הדף.
• BookStack מחליפה את Notion ו-Confluence עבור תיעוד, מאורגנת כמדפים, ספרים ודפים. תקת预算: כ-500 MB RAM על PHP ו-MySQL. הבעיה: היא מבנה תוכן בדרך משלה ולא כהערות חופשיות, מה שחלק מהאנשים אוהבים וחלק מוצאים נוקשה — נסו זאת לפני שתקדישו לה את כל ה-wiki שלכם.
• Home Assistant מחליפה את SmartThings ועשרות אפליקציות יצרן, ומאחדת את הבית החכם שלכם באופן מקומי. תקציב: כ-1 GB RAM. הבעיה: חלק מהקסם שלו דורש גישה לרשת המקומית למכשירים שלכם, לכן הוא חי בצורה טבעית יותר על חומרה בבית מאשר על VPS מרוחק — הריצו את הדשבורד מרחוק וצרו גשר (bridge) חזרה אם חייבים.

התקנה מייצגת

כדי להפוך זאת לממשי, הנה המבנה המלא של self-host: קובץ 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-stopped

docker compose up -d
docker compose logs -f

שימו לב ל-127.0.0.1: — האפליקציה מאזינה רק ל-localhost, ו-reverse proxy כגון Traefik או nginx מסתיים ב-TLS לפניها. קישור ישיר ל-0.0.0.0:3001 הוא הדרך שבה אנשים מפרסמים בטעות פאנל ניהול לא מוצפן לכל האינטרנט.

מה אסור לעשות self-host (עדיין)

• Email. זהו החלק הכנה. פורט 25 יוצא חסום על ידי רוב ספקי ה-VPS — תראו את Connection timed out מ-telnet aspmx.l.google.com 25 ואין מה לתקן, זו מדיניות. גם עם פורט 25 פתוח, כתובת IP חדשה ללא מוניטין, רשומת PTR, SPF, DKIM ו-DMARC תשלח את המייל שלכם לספאם או תגרום לו להידחות לחלוטין. זו עבודה אמיתית ומתמשכת, לא משימת סוף שבוע. אם אתם נחושים בכך, גשו לכך בעיניים פקוחות באמצעות המדריך self-hosted email with Mailcow, וצפו לעבוד עם ה-deliverability במשך חודשים.
• כל דבר שלא ניתן לגבות ולשחזר באופן אמין. אם מעולם לא ביצעתם בדיקת שחזור, אין לכם גיבוי, יש לכם תקווה. אל תשימו נתונים בלתי ניתנים להחלפה — העתק היחיד של התמונות שלכם, החשבונות שלכם — בשירות עד ששחזורו הוכח.
• העותק היחיד של תלות קריטית. שרת DNS עצמאי שכשקורס, לוקח איתו את האינטרנט של כל הרשת שלכם, הוא פרויקט ראשון גרוע. שמרו fallback ב-upstream.
• מערכות בטיחות בזמן אמת. אזעקות ביתיות, התראות רפואיות, כל דבר שבו חמישה דקות של downtime הן בעיה אמיתית, לא שייך לשרת תחביב שאתם משדרגים בימי ראשון בלילה.

איך לבחור את הראשון שלכם, ושני הדברים הבלתי-מתפשרים

בחרו את האפליקציה שמסירה חשבון שאתם מתעצבים עליו או דאגה לפרטיות שאתם באמת מרגישים. בפועל, ההתקנות הראשונות הטובות ביותר הן Vaultwarden ו-Uptime Kuma: שניהם קטנים, שניהם שימושיים מיידית, ושניהם סלחניים אם אתם טועים. דברו את כל התהליך מקצה לקצה — התקנה, תעודה, גיבוי, בדיקת שחזור — לפני שתוסיפו שנייה. המיומנות שאתם בונים היא תפעול (operations), לא לחיצה על התקנה.

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

1. TLS על כל דבר ציבורי. שירות עם IP בלבד וטקסט גלוי הוא דמו, לא פריסה (deployment). שימו תעודה אמיתית לפניו באמצעות Certbot and Let's Encrypt on nginx, או תנו ל-Traefik לעשות זאת אוטומטית. לאחר מכן, חזקו את הדלת הקדמית עם Fail2ban for SSH on Ubuntu 24.04.
2. גיבויים שבאמת שחזרתם אותם. 자동וצבו dump יומי — בסיס הנתונים ונפח הנתונים יחד — שלחו אותו מחוץ לשרת, ופעם בחודש שחזרו אותו על VPS זמני כדי להוכיח שהוא עובד. היום שבו הדיסק שלכם מת הוא היום הלא נכון לגלות שהגיבוי היה ריק.

אם תעשו את שני אלה נכון, self-hosting הוא עונג. אם תדלגו עליהם, זוהי ספירה לאחור.

האפציות נעות מהפרקטיקה ועד לאבסורד, משרת Minecraft server on a VPS משפחתי ועד, אם אתם נהנים מסיפור אזהרה, the world's least efficient datacenter.

FAQ

מה כדאי לי לעשות self-host קודם?

Vaultwarden. מנהל סיסמאות נותן לכם ערך יומיומי, מחליף מנוי, ומאלץ אתכם ללמוד את כל זרימת העבודה — Docker, reverse proxy, TLS וגיבויים — על אפליקציה קטנה מספיק כדי לבנות אותה מחדש תוך עשר דקות אם תהרסו אותה. Uptime Kuma הוא בחירה מצוינת שנייה, כך תגלו על תקלות לפני המשתמשים שלכם.

כמה VPS אני באמת צריך?

עבור אפליקציה קטנה אחת, 1 GB RAM מספיק. עבור שרת "להריץ כמה דברים" בנוחות, כוונו ל-4 GB — ה-2 GB באמצע הוא המקום שבו אנשים נתקלים ב-Out-Of-Memory container kills שקטים ולא מצליחים להבין מדוע. ה-RAM הוא כמעט תמיד המגבלה; הוסיפו דיסק בהתאם לנפח הנתונים שאתם מתכננים לאחסן, וצפו ש-Immich, Ollama וכל דבר עם בסיס נתונים גדול ידרשו את המקסימום משניהם.

מה אסור לי לעשות self-host?

אימייל, בראש ובראשונה — פורט 25 יוצא חסום על ידי רוב הספקים ומאבק ה-deliverability הוא עבודה במשרה מלאה. אחרי זה, כל דבר שלא ניתן לגבות ולשחזר באופן אמין, וכל נקודת כשל יחידה שבה ה-downtime שלה גורם נזק ממשי, כמו שרת DNS ללא fallback או מערכת בטיחות ביתית. כל שאר הרשימה היא רלוונטית.

האם אני צריך Docker לכל זה?

לא, אבל אתם תרצו אותו. לכל אפליקציה כאן יש Docker image, ו-Docker נותן לכם התקנות נקיות, הסרות נקיות, קיבוע גרסאות קל וניידות לשרת חדש. כמה אפליקציות (WireGuard, Zabbix) מותקנות גם באופן native מ-apt אם אתם מעדיפים. ברגע שתכירו קובץ compose אחד, תכירו את כולם, וזו הסיבה שכל הרשימה הופכת לנגישה.

איך אני שומר על התיקייה מאבטחה?

ארבע הרגלים מכסות את רוב הנושא: שימו TLS לפני כל דבר, שמרו על SSH נעול עם כניסה באמצעות מפתח בלבד ו-Fail2ban banning brute-force attempts, חשפו רק את הפורטים שאתם באמת צריכים ציבורית וגשו לשאר דרך ה-WireGuard VPN שלכם, ועדכנו באופן קבוע תוך קריאת ה-release notes כדי ששדרוג לעולם לא יפתיע אתכם. גיבויים הם ההרגל החמישי — הם ההתאוששות שלכם כשהטעות חומקת מארבע ההרגלים הראשונים.