SSD Nodes Learn Hosting plans →
מדריכים Matt Connorמאת Matt Connor · עודכן 2026-08-31

25 אפליקציות מומלצות ל-Self-hosting בשנת 2026

מחפשים מה להריץ על השרת הפרטי שלכם? ריכזנו 25 אפליקציות מומלצות ל-2026 עם דרישות RAM אמיתיות, פירוט השירותים שהן מחליפות וטיפים קריטיים למניעת תקלות בהתקנת Docker.

מה אתם בונים

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

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

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

כל יישום כאן רץ על שרת VPS מסוג KVM עם Ubuntu 24.04 נקי, בגישת root או sudo. אותה רשימה תעבוד באותה מידה על שרת פיזי בארון שלכם, ואם אתם שוקלים עלות חודשית מול רכישת זיכרון RAM, המדריך Proxmox בבית לעומת VPS מושכר מפרט את חישובי החומרה והחשמל. כמעט כל היישומים מופצים כמכולות Docker, לכן התקינו 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, דילגתם על שלב הוספת המשתמש לקבוצה או שלא פתחתם 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 kill שקט, ולא מבינים מדוע המכולה נעלמה; sudo dmesg יציג את שורת ה-Out of memory: Killed process שה-daemon בלע. שנית, כל שירות ציבורי זקוק לשם מתחם ולתעודה; כתובת IP חשופה עובדת לבדיקות, אך נכשלת ברגע שרוצים שאפליקציה בטלפון או דפדפן יבטחו בחיבור. שלישית, שני פורטים קובעים חצי מהאפשרויות שלכם: פורטים 80 ו-443 חייבים להיות נגישים לשרת עבור TLS אוטומטי, ופורט 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) היא החלק התובעני ביותר, ונדרש שטח דיסק השווה לספריית התמונות שלכם בתוספת כעשרים אחוז עבור תמונות ממוזערות. המוקש: Immich עדיין מפיץ שינויים שוברים (breaking changes) בין גרסאות, לכן לעולם אל תבצעו pull עיוור ל-latest; קבעו גרסה ספציפית וקראו את הערות השחרור לפני כל שדרוג. המדריך ספריית תמונות 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, שכן אסימון (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, וכל מודל תופס 4–8 GB בדיסק. המכשול: בשרת VPS מבוסס CPU בלבד, ההסקה תקינה אך איטית – צפו לקצב של מילים לשנייה, ולא לתגובות המיידיות של API מאוחסן. תאמו ציפיות או שכרו שרת עם GPU. המדריך הרצת Ollama לאירוח עצמי של LLM מספק נתונים ריאליים.

תקשורת

  • Rocket.Chat מחליפה את Slack עבור צוות, עם שרשורים, שיחות ואינטגרציות. הקצו 2 GB RAM ומעלה, כיוון שהיא רצה על MongoDB וזהו הרכיב הכבד ביותר. המוקש: Rocket.Chat מחייבת גרסה ראשית ספציפית של MongoDB לכל release, ודילוג על גרסה במהלך שדרוג יוביל להשבתת מסד הנתונים; יש לשדרג צעד אחר צעד. המדריך Rocket.Chat with 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 לעבודה נוחה. המגבלה: המערכת דורשת שליטה מלאה על השרת, והיא חינמית רק עבור שני יישומים; מעבר לכך מדובר במוצר בתשלום.
  • CasaOS מחליף לוחות בקרה מורכבים בממשק רשת ידידותי וקל משקל. הקצו כ-150 עד 300 MB עבור CasaOS עצמו. המגבלה: המערכת מיועדת לרשת ביתית מהימנה ואינה מוקשחת לחשיפה לאינטרנט הציבורי; אין לחשוף אותה ישירות, אלא לגשת אליה דרך WireGuard.
  • Coolify מהווה חלופה ל-Heroku, Vercel ו-Netlify, ומאפשר פריסה באמצעות git-push, ניהול מסדי נתונים וסביבות תצוגה מקדימה על השרת שלכם. הקצו לפחות 2 GB RAM. המגבלה: מדובר בפרויקט צעיר שמתפתח במהירות, לכן מומלץ לקבע גרסאות ולקרוא את הערות ה-release לפני שדרוג. ה-השוואה בין Cloudron ל-CasaOS ו-Coolify מפרטת איזו מהמערכות מתאימה לצרכים שלכם.

כלי פיתוח ופרודוקטיביות

  • Gitea (או Forgejo) מחליף את GitHub עבור מאגרים פרטיים, ניהול משימות (issues) ו־CI. הקצו 200–500 MB RAM. נקודה למחשבה: Forgejo הוא הפיצול (fork) המנוהל על ידי הקהילה של Gitea, והוא המומלץ כיום על ידי רבים; שניהם מצוינים, אך בחרו אחד ובצעו גיבוי למאגרים ולמסד הנתונים יחד. גיבוי מאגר ללא מסד הנתונים יגרום לאובדן כל המשימות ובקשות המיזוג (pull requests).
  • Paperless-ngx מחליף ארונות תיוק וסורקי מסמכים בתשלום, ומבצע OCR לכל מסמך כדי להפוך אותו לניתן לחיפוש. הקצו כ־1 GB RAM, עם קפיצות בשימוש ב־CPU בזמן פעולת ה־OCR. נקודה למחשבה: איכות תוצאות ה־OCR תלויה באיכות הסריקה שלכם, ועיבוד מחדש של ארכיון גדול הוא תהליך איטי; כוונו את ההגדרות לפני שתבצעו ייבוא מרוכז של עשר שנות מסמכים.
  • Actual Budget מחליף את YNAB ואת Mint ומציע ניהול תקציב מהיר, מקומי ופרטי בשיטת המעטפות. הקצו כ־150 MB RAM. נקודה למחשבה: סנכרון בנקאי אוטומטי הוא תוסף נפרד הדורש הגדרה משלו, לכן כברירת מחדל תצטרכו לייבא תנועות באופן ידני.
  • 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-stopped
docker compose up -d
docker compose logs -f

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

מה לא לארח באופן עצמי (עדיין)

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

כיצד לבחור את היישום הראשון, ושני תנאי הסף

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

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

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

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

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

FAQ

מה כדאי לארח באופן עצמי בתור התחלה?

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

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

עבור יישום קטן אחד, 1 GB של RAM מספיק. עבור שרת נוח להרצת מספר שירותים, כדאי לכוון ל-4 GB; בטווח הביניים של 2 GB משתמשים נתקלים לעיתים קרובות ב־Out-Of-Memory שגורם להריגת מכולות ללא התראה, וקשה להבין מדוע. הזיכרון (RAM) הוא כמעט תמיד המגבלה; הוסף נפח דיסק בהתאם לנתונים שאתה מתכנן לאחסן, וקח בחשבון שיישומים כמו Immich,‏ Ollama וכל מה שכולל מסד נתונים גדול ידרשו את מירב המשאבים משני הסוגים.

מה לא כדאי לארח באופן עצמי?

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

האם אני חייב להשתמש ב-Docker עבור כל זה?

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

איך שומרים על הכל מאובטח?

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