Cloudron מול CasaOS מול Coolify: מה עדיף לשרת VPS?

מה אתם בונים

בחירת כלי היא החלטה משמעותית לא פחות מהתקנתו. שלושה ממשקי ניהול מבטיחים להפוך שרת VPS ריק למארח יישומים מבוסס לחיצות עכבר: Cloudron, CasaOS ו-Coolify. מדריך זה מתקין כל אחד מהם על שרת Ubuntu 24.04 נקי, מתקין יישום ראשון, ולאחר מכן בוחן לעומק את ההיבטים שאינם מופיעים בצילומי המסך: TLS, גיבויים, עדכונים, צריכת זיכרון ומידת הקושי בנטישת המערכת. בסיום המדריך תדעו איזה מהם מתאים לכם, או אם התשובה הכנה היא "אף אחד מהם, פשוט השתמשו ב-Docker Compose".

אף אחד מהכלים הללו אינו קסם. מתחת לשלושתם פועל אותו Docker Engine שניתן להפעיל ידנית. מה שהממשק מוכר לכם, במחיר של כסף, זיכרון RAM או תלות בספק (lock-in), הוא ביצוע של ארבע משימות עבורכם: התקנת יישומים בלחיצה אחת, תעודות TLS אוטומטיות, גיבויים מתוזמנים וניהול משתמשים. אם ארבע המשימות הללו שוות עבורכם את התקורה (overhead) הכרוכה בהן, הממשק מצדיק את קיומו. אם אתם מריצים שירות אחד או שניים ומעדיפים לדעת בדיוק מה מותקן על השרת שלכם, קראו תחילה את הסעיף "דלגו על שלושתם" וחסכו לעצמכם את הטרחה.

דרישות קדם משותפות ומלכודות נפוצות

כל השלושה מניחים שימוש ב-VPS מסוג KVM, ולא בווירטואליזציה מבוססת מכולות. Docker זקוק לליבה (kernel) אמיתית, ו-Cloudron דוחה באופן מוחלט סביבות OpenVZ ו-LXC. בדקו זאת באמצעות systemd-detect-virt: kvm או qemu הם תקינים, בעוד openvz או lxc אינם תקינים. בתוכנית KVM הפקודה תדפיס kvm, ובשרת פיזי (bare metal) היא תדפיס none; כל אחת מהתוצאות הללו מאשרת שניתן להמשיך.

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

• RAM. CasaOS רץ היטב על 1GB; הוא פותח עבור חומרת Raspberry Pi ונשאר קל משקל. Coolify דורש 2GB ושתי ליבות CPU כרף מינימלי, כאשר כ-600 MB מתוכם משמשים את Coolify עצמו. Cloudron דורש 2GB לפחות, אך מתפקד טוב יותר עם 4GB, כיוון שהוא מריץ שרת דואר ומסד נתונים עוד לפני התקנת יישום כלשהו.
• שם מתחם (domain) ו-DNS בשליטתכם. Cloudron ו-Coolify דורשים שניהם שם מתחם אמיתי עם DNS תקין. Cloudron מעדיף גישת API לספק ה-DNS שלכם כדי שיוכל ליצור רשומות ותעודות wildcard באופן עצמאי. CasaOS ירוץ על כתובת IP בלבד, אך במקרה כזה לא תקבלו TLS כלל.
• פורטים. כל השלושה דורשים את פורטים 80 ו-443 פתוחים עבור HTTP ו-HTTPS. בנוסף, Coolify מגיש את לוח הבקרה שלו בפורט 8000, ומשתמש ב-6001 עבור ערוץ ה-realtime שלו וב-6002 עבור הטרמינל בדפדפן. השאירו את פורט 22 פתוח עבור SSH בכל אחד מהם.

הפנו את ה-DNS אל השרת לפני שתתחילו. לוח בקרה שאינו מסוגל לפתור את שם המארח (hostname) של עצמו לא יוכל לבקש תעודה, ואתם תבזבזו את השעה הראשונה בניפוי שגיאות במקום בהתקנת התוכנה. הפנו רשומת A לכתובת ה-IP של השרת, ועבור Coolify הוסיפו רשומת wildcard (*.apps.example.com) כדי שכל יישום שיופעל יקבל תת-מתחם משלו.

Cloudron: הפלטפורמה המלוטשת והמובנית

מה זה. Cloudron היא פלטפורמה מסחרית שהופכת שרת שלם למכשיר (appliance) מנוהל. היא מריצה reverse proxy, מסד נתונים ומערכת דואר משלה, בתוספת חנות אפליקציות ארוזות (Nextcloud, WordPress, Gitea, Mattermost ועוד). היא מיועדת לאנשים שרוצים שהיישומים שלהם יהיו מנוהלים, עם עדכונים אוטומטיים, תעודות אוטומטיות וגיבויים אוטומטיים, ומוכנים לשלם על כך.

התקנה. היא דורשת שרת נקי ומשתלטת עליו לחלוטין. הריצו זאת על שרת Ubuntu 24.04 (Noble) חדש בלבד:

wget https://cloudron.io/cloudron-setup
chmod +x cloudron-setup
sudo ./cloudron-setup

הסקריפט מתקין Docker, nginx, מסד נתונים ומערכת דואר, ואז מבצע אתחול. כשהשרת עולה, פתחו את https://<your-ip>, אשרו את התעודה הזמנית (self-signed) והשלימו את ההגדרה בדפדפן: הגדירו את הדומיין שלכם, בחרו את ספק ה-DNS, והמערכת תקים את לוח הבקרה שלה ב-my.example.com.

הוספת אפליקציה ראשונה. בלוח הבקרה, פתחו את חנות האפליקציות, לחצו (למשל) על Nextcloud, בחרו את תת-הדומיין files.example.com ולחצו על Install. Cloudron יוצרת את רשומת ה-DNS, מבקשת תעודת Let's Encrypt, מקימה את מסד הונים, מחברת את ה-single sign-on וקובעת לוח זמנים לגיבוי – כל זאת מבלי שתצטרכו לגעת בקובץ תצורה אחד. זהו הערך המרכזי של המערכת, והיא מספקת אותו במלואו.

TLS וגיבויים. זהו החלק החזק ביותר מבין השלושה. כל תת-דומיין של אפליקציה מקבל תעודת Let's Encrypt אוטומטית, שמתחדשת עבורכם. הגיבויים מתוזמנים ומובנים במערכת, ומכוונים לספרייה מקומית, S3 או אחסון מרוחק אחר, עם אפשרות לשחזור ברמת האפליקציה ואפילו שכפול (cloning) של אפליקציה לתת-דומיין חדש בלחיצת כפתור.

עלות ורישוי, קראו זאת לפני שתתחייבו. Cloudron הוא מוצר בתשלום עם גרסה חינמית מוגבלת: התוכנית החינמית מאפשרת שתי אפליקציות. התקנת אפליקציה שלישית תחסום אתכם; מנוי בתשלום (Pro או Max, בחיוב חודשי או שנתי, שניהם עם אפליקציות ללא הגבלה) פותח אפשרויות נוספות. זוהי העובדה החשובה ביותר לגבי Cloudron. המערכת מלוטשת בדיוק משום שהיא עסק, והגרסה החינמית קרובה יותר לניסיון מורחב מאשר לבית עבור מערך יישומים גדל.

מצב כשל, כלל השרת הנקי. אם תנסו להתקין את Cloudron על שרת שכבר מריץ משהו, ההתקנה תיעצר לפני שתבצע שינויים כלשהם:

Error: Some packages like nginx/docker/nodejs are already installed. Cloudron requires
specific versions of these packages and will install them as part of it's installation.
Please start with a fresh Ubuntu install and run this script again.

הסיבה אינה קטנוניות. Cloudron מקבעת גרסאות ספציפיות של nginx, Docker ו-Node ומשלבת אותן לעומק, לכן היא אינה יכולה להתקיים לצד עותקים משלכם. הפתרון הוא תמונת Ubuntu 24.04 נקייה בלבד: ללא שרת אינטרנט, ללא Docker, ואפילו ללא firewall שהגדרתם ידנית. אם העליתם תמונה שגויה, ההתקנה תסרב לכל מה שאינו גרסת Ubuntu LTS נתמכת (22.04 או 24.04) על ארכיטקטורת x86-64; סביבות ARM, LXC ו-OpenVZ אינן נתמכות כלל.

מצב כשל שני, תעודות wildcard דורשות DNS API. אם תבחרו באפשרות ה-DNS ה-"ידנית" (Manual) במהלך ההתקנה במקום לספק ל-Cloudron מפתח API, היא לא תוכל ליצור רשומות או תעודת wildcard עבורכם. כל אפליקציה חדשה תחייב אתכם להוסיף רשומת DNS ידנית לפני שניתן יהיה להנפיק תעודה, ולוח הבקרה ימתין לרשומה זו. ספקו ל-Cloudron גישת API לספק DNS נתמך (כמו Cloudflare, Route 53, DigitalOcean ואחרים) וכל התהליך יהפוך ללחיצה אחת.

CasaOS: לוח הבקרה החינמי ל-home-lab

מה זה. CasaOS, מבית IceWhale, הוא לוח בקרה בקוד פתוח שמותקן על גבי Docker ומספק מסך בית, חנות אפליקציות ומנהל קבצים. הוא צמח מעולם ה-home-server, ולכן הוא מותאם לצרכים אלו: התקנה מהירה, ממשק משתמש ידידותי ומינימום הגדרות. הוא מיועד לחובבים שרוצים ממשק נוח ל-Docker מבלי לשלם על כך.

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

curl -fsSL https://get.casaos.io | sudo bash

המתקין מוסיף קבוצה של שירותי systemd (‏casaos, ‏casaos-gateway, ‏casaos-app-management ואחרים). ודאו שה-gateway עלה לפני פתיחת הדפדפן:

systemctl status casaos-gateway

כשהוא רץ, לוח הבקרה זמין ב-http://<your-ip> (‏HTTP רגיל, פורט 80). צרו חשבון מקומי ואתם בפנים.

הוספת אפליקציה ראשונה. פתחו את ה-App Store, בחרו אפליקציה ולחצו על Install. CasaOS כותב פרויקט Docker Compose מאחורי הקלעים וחושף את האפליקציה בפורט מארח, למשל http://<your-ip>:8080. החנות שלו כוללת את רשימת השירותים הנפוצים ל-home-server, כך ש-שרת המדיה Jellyfin על גבי VPS או ספריית תמונות Immich בניהול עצמי נמצאים במרחק לחיצות ספורות. אם טרם החלטתם על שרת תמונות, כדאי לקרוא תחילה על ההבדלים בצריכת ה-RAM ובאפליקציות הטלפון בין PhotoPrism ל-Immich, שכן בשרת CasaOS עם 1GB של זיכרון, בחירה זו תקבע אם האפליקציה בכלל תרוץ. ניתן גם לייבא כל docker-compose.yaml שתרצו, וזו נקודת החוזק האמיתית: האפליקציות הן מכולות רגילות, לא פורמט קנייני.

TLS וגיבויים, נקודת התורפה. כאן ניכר הגבול של ה"חינם". CasaOS מגיש הכל ב-HTTP רגיל כברירת מחדל, כולל לוח הבקרה עצמו. אין תמיכה מובנית ב-Let's Encrypt ואין גיבוי מתוזמן מובנה. הנתונים שלכם נמצאים ב-Docker volumes תחת /DATA, והגיבוי הוא באחריותכם (באמצעות restic או tar מתוזמנים ב-cron).

מצב כשל, היעדר TLS ושתיקה. שום דבר לא מציג שגיאה. אתם מתקינים אפליקציה, פותחים את http://<your-ip>:8080, והיא עובדת על גבי חיבור לא מוצפן שהדפדפן מסמן כ-"Not Secure". סיסמאות ו-session cookies עוברים ברשת בטקסט גלוי. גרוע מכך, ב-CasaOS התגלו בעבר פגיעויות של הרצת קוד מרחוק (RCE) בלוח הבקרה (CVE-2023-37265 ו-CVE-2023-37266, עקיפת אימות שהובילה להשתלטות מלאה על המארח), כך שחשיפת פורט ה-HTTP ישירות לאינטרנט היא סיכון ממשי, לא רק עניין של סגנון. הפתרון הוא לעולם לא לחשוף את CasaOS ישירות. הציבו לפניו reverse proxy שמבצע TLS termination, כגון nginx עם תעודת Let's Encrypt מ-Certbot, Caddy או Cloudflare Tunnel, ונתבו אליו רק מהרשת המקומית. שימו לב ש-CasaOS כבר מאזין בפורט 80, לכן ה-proxy שלכם ו-CasaOS יתנגשו אלא אם תעבירו את CasaOS לפורט אחר תחילה.

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

Coolify: פלטפורמת PaaS לאירוח עצמי

מה זה. Coolify היא פלטפורמת PaaS (Platform-as-a-Service) בקוד פתוח לאירוח עצמי, בסגנון Heroku או Vercel, שרצה על השרת שלך. יחידת העבודה הבסיסית שלה אינה "התקנת אפליקציה ארוזה" אלא "פריסת מאגר Git": מחברים מאגר, ו-Coolify בונה אותו (באמצעות Nixpacks או Dockerfile משלך) ומפיצה אותו, תוך ביצוע פריסה מחדש בכל push. היא כוללת גם מסדי נתונים ושירותים בלחיצת כפתור. היא מיועדת למפתחים שפורסים קוד משלהם ומחפשים יכולת push-to-deploy ללא צורך בשכירת שירות PaaS חיצוני.

התקנה.

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

הסקריפט מתקין Docker ומעלה את ערימת המכולות של Coolify. ודאו שהן תקינות לפני שתמשיכו:

docker ps --format 'table {{.Names}}\t{{.Status}}'

עליכם לראות את coolify, coolify-db, coolify-redis, coolify-realtime ו-coolify-proxy מדווחים כולם על Up. לוח הבקרה נמצא ב-http://<your-ip>:8000. צרו את חשבון הניהול שלכם מיד, כיוון שדף ההרשמה פתוח עד ליצירת החשבון הראשון, וכל מי שיגיע אליו ראשון ישלוט בשרת. לאחר מכן הגדירו את שם המתחם של המופע (instance) והצביעו עם רשומת DNS מסוג wildcard (*.example.com או *.apps.example.com) אל השרת, כדי ש-Coolify תוכל להקצות לכל אפליקציה פרוסה תת-מתחם משלה.

הוספת אפליקציה ראשונה. חברו מקור Git (GitHub, GitLab או כתובת מאגר רגילה), בחרו ענף (branch), הגדירו את שם המתחם ופרוסו. ה-proxy מסוג Traefik המובנה ב-Coolify מנתב את תת-המתחם ומבקש את התעודה. עבור תוכנות מוכנות, קטלוג השירותים מאפשר פריסה בכמה לחיצות: אותו מערך אוטומציית תהליכי עבודה n8n שאולי הייתם מחברים ידנית הוא פריט אחד, וכך גם Uptime Kuma לניטור דפי סטטוס.

TLS וגיבויים. Let's Encrypt מופעל אוטומטית לכל אפליקציה דרך Traefik המצורף, כך שכל תת-מתחם פרוס מקבל תעודה. הגיבויים מתמקדים במסדי נתונים: ניתן לתזמן dumps של Postgres ו-MySQL לאחסון תואם S3. גיבוי של המופע כולו (הגדרות Coolify עצמן, שנמצאות תחת /data/coolify) הוא ידני יותר, לכן עליכם לייצא ולשמור אותו בעצמכם.

עלות ורישוי. מהדורת האירוח העצמי היא בקוד פתוח מלא ובחינם, ללא הגבלה על מספר האפליקציות. קיימת אפשרות ל-Coolify Cloud (בתשלום), המארחת עבורכם את מישור הבקרה (control plane) בעוד האפליקציות שלכם ממשיכות לרוץ על השרתים שלכם; זה נוח אך לא חובה.

מצב כשל: האפליקציה נפרסת אך שם המתחם שלה לא נטען. לוח הבקרה עובד היטב ב-http://<ip>:8000, תהליך הבנייה מסתיים בהצלחה (ירוק), אך כתובת ה-URL של האפליקציה מחזירה שגיאת חיבור או שגיאת 404 page not found של Traefik. זה מצביע על ה-proxy או על ה-DNS, לא על האפליקציה שלכם. שתי סיבות נפוצות: ראשית, פורטים 80 או 443 היו תפוסים כבר כאשר ה-proxy ניסה לעלות, ולכן המכולה שלו קרסה עם שגיאת Docker:

Error response from daemon: driver failed programming external connectivity on endpoint coolify-proxy: Bind for 0.0.0.0:443 failed: port is already allocated

שנית, רשומת ה-DNS מסוג wildcard חסרה, ולכן Traefik לעולם לא מקבל בקשה עבור שם המארח הזה. אם במקום זאת כרטיס השרת ב-Coolify מציג "Server is not reachable", מדובר בתקלה אחרת: Coolify אינה מצליחה לתקשר כלל עם ה-socket של Docker בשרת, בדרך כלל בגלל שירות Docker שעצר או מפתח SSH פגום. קראו את הסיבה האמיתית בלוגים לפני שתנחשו:

docker logs coolify-proxy --tail 100

תקנו זאת מדף ה-Proxy: לחצו על Restart Proxy, או אפסו את תצורת ה-proxy לברירת המחדל והפעילו אותו מחדש, ולאחר מכן המתינו כשתי דקות עד להתייצבותו. שמרו על פורט 8000 נגיש מה-IP שלכם בלבד (או פתחו אותו זמנית כאשר ה-proxy מתנהג בצורה לא תקינה) במקום להשאיר אותו פתוח לכל העולם; הוא מגיש את לוח הבקרה ב-HTTP רגיל, והתיעוד של Coolify מציין שניתן לסגור את פורטים 8000, 6001 ו-6002 ברגע שלוח הבקרה מוגש דרך שם המתחם שלו.

צריכת משאבים על אותו VPS

הנתונים נמדדו במצב המתנה (idle) על אותו שרת 4GB, לפני פריסת עומס עבודה ממשי. בדקו את הנתונים שלכם באמצעות free -m ו-docker stats --no-stream במקום להסתמך על מספר בודד, כיוון שהצריכה הכוללת משתנה בהתאם לתמהיל היישומים שלכם.

• CasaOS הוא הקל ביותר. לוח הבקרה מורכב מקבוצה קטנה של שירותי Go; צפו לצריכה של כ-150 עד 300 MB מעבר לכל מכולה שתריצו.
• Coolify מריץ כמה מכולות תמיכה משלו (היישום, Postgres, Redis, שירות בזמן אמת ו-Traefik), לכן הצריכה שלו במצב המתנה נעה בין 600 MB ל-1 GB לפני פריסת יישומים כלשהם.
• Cloudron הוא הכבד ביותר במצב מנוחה, כיוון שהוא מריץ nginx, מסד נתונים, מערך דואר וניטור משלו, בין אם אתם משתמשים בהם ובין אם לא; הקצו 1 עד 1.5 GB במצב המתנה. זו הסיבה שהוא דורש מינימום 2GB ומתפקד בצורה טובה יותר עם 4GB.

על שרת VPS קטן של 2GB, ל-CasaOS נותר המרחב הגדול ביותר עבור יישומים ממשיים, בעוד ל-Cloudron נותר המרחב המצומצם ביותר. אם התוכנית שלכם היא להשתמש ב-2GB ואתם מעוניינים להריץ את Cloudron יחד עם שרת הדואר שלו, תכננו לשדרג את השרת.

עדכונים, גיבויים והשוואת תלות בספק (Lock-in)

עדכונים. Cloudron מעדכנת עבורך את הפלטפורמה ואת כל היישומים לפי לוח זמנים שנבדק מראש: זהו הפתרון שדורש את המאמץ המינימלי ומספק את מירב התמיכה. Coolify מתעדכנת בעצמה מתוך לוח הבקרה שלה בלחיצת כפתור. CasaOS מעדכנת את הפאנל דרך סקריפט ההתקנה שלה או באמצעות apt, אך האחריות על משיכת (pull) והפעלת היישומים מחדש מוטלת עליך.

תלות בספק (Lock-in), החלק שמורגש בשנה השנייה. CasaOS היא הפחות תלויה בספק: היישומים שלה הם פרויקטי Compose רגילים, כך שניתן להעתיק את ה-docker-compose.yaml ואת ה-volumes תחת /DATA לכל מארח אחר ולהמשיך לעבוד. Coolify נמצאת באמצע: הפריסות שלך מבוססות על Dockerfiles ומאגרים (repos) שבבעלותך, אך התצורה שלהם שמורה בבסיס הנתונים של Coolify, לכן מעבר מארחים מחייב יצירה מחדש של הפרויקטים בצד השני. Cloudron היא התלויה ביותר בספק: היישומים ארוזים בפורמט של Cloudron, ואף על פי שהנתונים שלך יוצאים בצורה נקייה דרך מערכת הגיבויים המצוינת שלה, שיטת האריזה אינה ניידת, ולכן תצטרך לפרוס מחדש בפלטפורמת היעד. נתונים ניידים, תשתית לא ניידת.

באיזו אפשרות כדאי לבחור

גרסה מקוצרת, ולאחריה דרך היציאה. בחרו ב-Cloudron אם אתם מחפשים את השרת עם מינימום התערבות ידנית מבין השלושה, אם תריצו כמה יישומים ארוזים, ואם אתם מוכנים לשלם תשלום שנתי עבור ניהול TLS, גיבויים ועדכונים. בחרו ב-CasaOS אם מדובר במעבדה ביתית (home lab) מאחורי הרשת שלכם או מאחורי reverse proxy, אם אתם רוצים ממשק ידידותי ל-Docker, ואם אתם מסרבים לשלם על כך. בחרו ב-Coolify אם אתם פורסים קוד משלכם מ-Git ורוצים יכולת push-to-deploy עם TLS אוטומטי, ללא העלות של שירות PaaS מנוהל. אם אף אחת משלוש האפשרויות הללו לא מתאימה לכם, הסעיף הבא הוא התשובה הכנה.

דלגו על שלושתם אם...

היו כנים לגבי קנה המידה שלכם. אם אתם מריצים רק יישום אחד או שניים, או שאתם רוצים להבין ולשלוט בדיוק במה שמותקן על השרת שלכם, דלגו על לוחות הניהול. התקורה והתלות בספק (lock-in) אינן משתלמות עבור מערך קטן ויציב. הדרך של "עשה זאת בעצמך" היא שימוש ב-reverse proxy לפני קובצי ה-Compose שלכם: Traefik עם TLS אוטומטי לפני כמה יישומי Docker Compose מעניק לכם HTTPS ברמה של לחיצה אחת ללא המשקל של לוח ניהול, ואתם מבצעים גיבוי באמצעות משימת restic מתוזמנת ב-cron שאתם באמת מבינים.

services:
  whoami:
    image: traefik/whoami
    labels:
      - traefik.enable=true
      - traefik.http.routers.whoami.rule=Host(`whoami.example.com`)
      - traefik.http.routers.whoami.tls.certresolver=le
    networks: [web]
networks:
  web:
    external: true

עבור יישום דגל יחיד, המקרה ברור עוד יותר: התקנת Nextcloud על Docker עם TLS ושגרת גיבוי עצמאית היא קובץ Compose אחד ותעודה אחת. הקמת מערכת שלמה כדי להריץ אותו תהיה כרוכה רק בעלויות ללא כל תועלת. אם אתם עדיין מחליטים מה להריץ לפני שאתם מחליטים איך, ה-מדריך למה כדאי לארח באופן עצמאי בשנת 2026 הוא נקודת התחלה טובה יותר.

FAQ

האם אני באמת זקוק ללוח ניהול עבור אירוח עצמי?

רק אם יש ערך עבורך בארבע הפעולות שלוח ניהול מבצע אוטומטית עבור כמה יישומים: התקנה בלחיצה אחת, TLS אוטומטי, גיבויים מתוזמנים וניהול משתמשים. עבור שירות אחד או שניים, Docker Compose פשוט מאחורי Traefik מבצע את אותה עבודה של TLS עם הרבה פחות תקורה וללא תלות בספק (lock-in). לוחות ניהול משתלמים כאשר מריצים יישומים רבים והזמן שלך יקר יותר מה־RAM שהם צורכים.

איזה לוח ניהול הוא הטוב ביותר למתחילים?

עבור מעבדה ביתית שבה שום דבר אינו חשוף לאינטרנט העוין, CasaOS הוא נקודת ההתחלה הנוחה ביותר: פקודה אחת וממשק משתמש ידידותי, ללא עלות. עם זאת, חובה להציב reverse proxy עם TLS termination לפני שחושפים משהו, כיוון שהוא מופץ עם HTTP בלתי מוצפן. אם ברצונך בניהול TLS וגיבויים אוטומטיים ואתה מוכן לשלם על כך, Cloudron הוא השירות שמספק את מירב התמיכה, במסגרת המגבלה החינמית של שני יישומים.

האם Cloudron הוא בחינם?

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

האם ניתן להריץ את לוחות הניהול האלו לצד היישומים הקיימים שלי?

Cloudron: לא. הוא דורש שרת Ubuntu נקי ומבטל את ההתקנה אם Nginx, Docker או Node כבר מותקנים, כיוון שהוא מנהל את המכונה כולה. CasaOS ו־Coolify ידידותיים יותר, כיוון שהם מתקינים את ה־Docker stack שלהם ויכולים עקרונית לחלוק מכונה, אך שניהם דורשים את פורטים 80 ו־443, ולכן הם יתנגשו עם כל שרת אינטרנט או proxy שכבר מותקן. על מכונה שכבר מארחת שירותים, לוח ניהול הוא בדרך כלל הכלי הלא נכון; עדיף להשתמש ב־Traefik וב־Compose.

איך עוברים מלוח ניהול מאוחר יותר?

תכנן את היציאה לפני שתזדקק לה. מ־CasaOS, העתק את ה־docker-compose.yaml של היישום ואת ה־volumes שלו ב־/DATA למארח החדש והפעל אותם שוב. מ־Coolify, ייצא את התצורה של כל פרויקט והפנה אותה לאותם מאגרים (repos) ביעד. מ־Cloudron, שחזר נתונים מהגיבויים שלו לתוך יישומים שהותקנו מחדש בפלטפורמה החדשה, כיוון שהאריזה של Cloudron אינה ניידת, רק הנתונים הם כאלו. בכל מקרה, בדוק את השחזור על מכונה זמנית לפני שתסגור את הישנה.