איך להתקין Cloudron על VPS עם Ubuntu

התקנת Cloudron ב־VPS: הגרסה המקוצרת

כדי להתקין את Cloudron ב־VPS דרוש שרת Ubuntu חדש, לפחות 2 GB של RAM ודומיין שאת רשומות ה־DNS שלו ניתן לערוך. ההתקנה עצמה כוללת שלוש פקודות ואתחול אחד. כמעט כל התקלה מתרחשת לפני שלב זה (image בסיס שגוי או סוג וירטואליזציה שגוי) או אחריו (DNS, דואר וגיבויים).

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

Cloudron מתקין, מעדכן ומגבה יישומים באירוח עצמי, ומנפיק עבורם תעודות TLS (אבטחת שכבת התעבורה). כל יישום פועל ב־Docker, ‏nginx יושב לפני כולם, וכל יישום מקבל תת־דומיין משלו בדומיין שלך. זו הסיבה שעבודת ה־DNS מתבצעת כאן תחילה.

מדוע Cloudron מקפיד על מערכת ההפעלה הבסיסית

סקריפט ההתקנה בודק את השרת לפני שהוא מתקין דבר. כישלון בבדיקה פירושו שתצטרכו להזמין שרת חדש. קראו את הדרישות לפני שתבחרו image.

• Ubuntu בלבד, ורק שלוש מהדורות. כל אפשרות אחרת מסתיימת ב־Cloudron requires Ubuntu 20.04, 22.04, 24.04. Debian, Rocky ו־Alpine אינם נתמכים. Ubuntu 24.04 דורש Cloudron 8 ואילך, והסקריפט בודק זאת עבורכם.
• מעבד Intel או AMD בעל 64 סיביות בלבד: Error: Cloudron only supports amd64/x86_64. VPS מבוסס ARM אינו יכול להריץ את המערכת.
• וירטואליזציה מלאה של החומרה בלבד. ב־VPS המבוסס על מכולות הסקריפט נעצר עם Error: Cloudron does not support lxc, only runs on bare metal or with full hardware virtualization, משום שהוא מזהה את המכולה באמצעות systemd-detect-virt --container. KVM נתמך. OpenVZ ו־LXC אינם נתמכים.
• מערכת הקבצים הבסיסית חייבת להיות ext4 או xfs. בכל אפשרות אחרת תקבלו Error: Cloudron requires '/' to be ext4 or xfs, וכך נכשלים images המבוססים על btrfs ו־zfs.
• נדרשים לפחות 941 MB של RAM ו־20 GB ב־/, לפי המדידה באמצעות free -m ולפי גודל מערכת הקבצים הבסיסית.
• שרת חדש לחלוטין. אם nginx, docker או node כבר מותקנים, הסקריפט מסרב להמשיך ומציג Error: Some packages like nginx/docker/nodejs are already installed..

הבדיקה האחרונה היא זו שמעוררת בדרך כלל ויכוחים, ולכן חשוב להבין את הסיבה לה. Cloudron מתקין גרסאות מקובעות של Docker, nginx, Node.js ו־MySQL, כותב את תצורת nginx עבור כל יישום שהוא מארח, ומנהל בעצמו את חוקי חומת האש של iptables. Docker שהתקנתם אתמול הוא בגרסה שגויה, וקובצי האתרים הקיימים של nginx יוחלפו. Cloudron מנהל את כל המכונה, ולכן יש להקצות לו VPS ייעודי.

קל לפספס בדיקה נוספת. במעבד ישן ללא AVX (הרחבות וקטוריות מתקדמות), הסקריפט מציג CPU has no AVX support. MongoDB will be disabled, וכל יישום שדורש MongoDB לא יהיה ניתן להתקנה. בדקו את המעבד לפני ההתחייבות באמצעות grep -m1 -o avx /proc/cpuinfo. פקודה זו מציגה avx בשרת שתומך בכך, ואינה מציגה דבר בשרת ישן.

כמה RAM דרוש ל־Cloudron?

הסקריפט מסרב לפעול מתחת ל־941 MB, באמצעות Error: Cloudron requires atleast 1GB physical memory, וה documentation דורשת 2 GB של RAM ו־20 GB של אחסון. שני המספרים האלה הם דרישות הסף של הפלטפורמה, ולא של הפלטפורמה ושל היישומים יחד. עוד לפני התקנת יישום אחד, Cloudron כבר מפעילה את Docker, את nginx, את שירות box שלה, את מכלי מסדי הנתונים שהיא מספקת ליישומים (MySQL, PostgreSQL, MongoDB), את Redis ואת מערך הדואר. הפעילו docker ps בהתקנה חדשה וספרו אותם.

מגבלות הזיכרון של היישומים מצטרפות לדרישות הבסיס האלה. כל חבילת יישום מגיעה עם מגבלת ברירת מחדל נמוכה, ואפשר להגדיל אותה באמצעות המחוון בתצוגת Resources של היישום. כאשר יישום חורג מהמגבלה שלו, הוא מופעל מחדש ונשלחת אליכם התראת OOM (out of memory). לכן, שרת שמפעיל מחדש שוב ושוב יישום אחד סובל בדרך כלל מבעיית מגבלה ולא מבאג.

אלה מידות המשאבים שהייתי מזמין. מדובר בהמלצות לשרת שלא תצטרכו לבנות מחדש בחודש הבא. אלה אינן תוצאות מדידה של benchmark.

[
  {
    "label": "2 apps (free tier)",
    "vcpu": 2,
    "ram_gb": 4,
    "disk_gb": 60
  },
  {
    "label": "5 apps",
    "vcpu": 4,
    "ram_gb": 8,
    "disk_gb": 120
  },
  {
    "label": "10 apps",
    "vcpu": 6,
    "ram_gb": 16,
    "disk_gb": 240
  }
]

שני יישומים פועלים בנוחות עם 4 GB של RAM ו־60 GB של אחסון. כעשרה יישומים דורשים כ־16 GB וכ־240 GB, משום שדרישות הבסיס של הפלטפורמה אינן מצטמצמות, וכל יישום מוסיף image של Docker, מסד נתונים ונתונים משלו. הדיסק מתמלא מהר יותר מכפי שנהוג לצפות: images, נתוני יישומים וגיבויים מקומיים חולקים אותו volume, עד שמעבירים את הגיבויים אל מחוץ לשרת.

Cloudron מקצה לכל יישום swap ללא הגבלה, ולכן מגבלת הזיכרון שהגדרתם חלה על RAM בלבד. ב־VPS ללא קובץ swap, swapon --show לא מדפיס דבר, ולחץ זיכרון מוביל ישירות להפעלות מחדש עקב OOM במקום להאט את היישום. הוספת 2 GB של swap היא אמצעי ביטחון זול, אך היא אינה מחליפה זיכרון אמיתי. הפער בין חבילות VPS קטן ביחס לשעות שתשקיעו בכוונון המגבלות, לכן עיינו ב־כמה VPS באמת עולה ורכשו את החבילה הגדולה יותר.

DNS: רשומת ה־wildcard שמאפשרת שימוש בתת־מתחמים של יישומים

Cloudron מציב את לוח הבקרה ב־my.example.com וכל יישום בתת־מתחם משלו, לכן DNS הוא תנאי מקדים ולא שלב מאוחר יותר. הפנו את הרשומות האלה לכתובת ה־IP הציבורית של השרת לפני שתפתחו את לוח הבקרה בפעם הראשונה:

• my.example.com כרשומת A. זו כתובת לוח הבקרה.
• *.example.com כרשומת A. זו הרשומה שמאפשרת שימוש בתת־מתחמים של יישומים, לכן wiki.example.com ו־git.example.com ייפתרו מיד לאחר שתתקינו את היישומים האלה.
• example.com כרשומת A, רק אם ברצונכם להפעיל יישום במתחם החשוף.

לרשומת wildcard יש קדימות נמוכה יותר מרשומה מפורשת, לכן רשומת www.example.com קיימת שמצביעה למקום אחר תמשיך לפעול.

במהלך ההגדרה תבחרו כיצד Cloudron יטפל ב־DNS מכאן ואילך:

• ספק API. Cloudron שומר אסימון עבור Cloudflare, DigitalOcean, Route53, Hetzner, Porkbun, Linode, deSEC, Gandi, Namecheap וכ־20 ספקים נוספים, ולאחר מכן כותב בעצמו את כל הרשומות, כולל רשומות דואר.
• Wildcard. אתם מוסיפים ידנית את רשומת *, ו־Cloudron אינו כותב דבר.
• Manual. Cloudron מציג לכם כל רשומה וממתין שתוסיפו אותה לפני כל התקנה של יישום.

רשומת DNS מסוג wildcard אינה תעודת wildcard. ספק התעודות המוגדר כברירת מחדל הוא Let's Encrypt Prod - Wildcard. הוא מאמת בעלות באמצעות DNS, ולכן פועל רק עם ספק API. במנגנוני Wildcard או Manual תעברו לתעודה אחת לכל יישום, המאומתת באמצעות HTTP, ולכן פורט 80 הנכנס חייב להישאר פתוח תמיד. אם הרשם או מארח ה־DNS שלכם נמצא ברשימת ה־API, השתמשו בו: גם רשומות הדואר וגם התעודות לא ידרשו מכם עוד טיפול.

אמתו את ההגדרות לפני שתמשיכו. dig +short my.example.com ו־dig +short anything.example.com אמורות להציג את כתובת ה־IP של השרת. אם שאילתת ה־wildcard אינה מציגה דבר, היישומים ייכשלו בהמשך אף שלוח הבקרה יפעל כרגיל.

אם המתחם נמצא מאחורי Cloudflare, הגדירו את הרשומות כ־DNS only. ה־proxy מעביר HTTP ו־HTTPS בלבד, ולכן פורטי הדואר יפסיקו לפעול, וכל יישום יראה כתובת של Cloudflare במקום את כתובת המבקר.

הרצת סקריפט ההתקנה

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

הריצו אותו כ־root או באמצעות sudo, משום שאחרת הדבר הראשון שהוא מדפיס הוא This script should be run as root.. ההתקנה נמשכת כמה דקות ואינה מציגה פלט בזמן הפעולה, משום שפלט הפקודות של apt וה־pulls של Docker נכתבים לקובץ לוג. עקבו אחריו מהפעלת SSH שנייה:

tail -f /var/log/cloudron-setup.log

בסיום יודפס After reboot, visit one of the following URLs and accept the self-signed certificate to finish setup. ואחריו כתובת השרת שלכם, ולאחר מכן תופיע השאלה The server has to be rebooted to apply all the settings. Reboot now ? [Y/n]. השיבו yes. הדגל --skip-reboot זמין אם עליכם לתזמן את האתחול מחדש, אך אי אפשר להשתמש ב־Cloudron עד שהשרת יחזור לפעול.

אתחול ראשון: מתחם, backend של DNS וחשבון המנהל

פתחו את https://<server-ip> ואשרו את אזהרת הדפדפן. התעודה היא בחתימה עצמית, משום ש־Cloudron עדיין אינו מכיר את המתחם שלכם ולכן אין לו פרטים שאפשר לשלוח לרשות תעודות. ב־Chrome לחצו על Advanced ולאחר מכן על Proceed to <ip> (unsafe). ב־Firefox לחצו על Advanced ולאחר מכן על Accept the Risk and Continue.

במסך הראשון תתבקשו להזין את המתחם שלכם. הזינו את example.com, ולוח הבקרה יהיה זמין ב־my.example.com. אפשר להשתמש גם בתת־מתחם, כגון cloudron.example.com, ואז לוח הבקרה יהיה זמין ב־my.cloudron.example.com. בחרו את backend של DNS, הדביקו את אסימון ה־API אם יש לכם כזה, וצרו את חשבון המנהל באמצעות כתובת דוא״ל שאתם קוראים בפועל: הרישום ל־Let's Encrypt וכל ההתראות של הפלטפורמה נשלחים לכתובת זו.

לאחר השמירה, Cloudron יבקש תעודות ויעביר את לוח הבקרה אל https://my.example.com. כתובת ה־IP תפסיק לפעול בשלב זה, לכן שמרו את הכתובת החדשה כסימנייה.

תעודות: מה מתחדש ומתי החידוש נעצר

חידוש התעודה מתבצע באופן אוטומטי לפי ACME Renewal Information (ARI) — לוח הזמנים שמפרסמת רשות התעודות. בפועל, החידוש מתבצע בדרך כלל כחודש לפני מועד הפקיעה. חידוש שנכשל שולח הודעת דוא"ל לחשבון מנהל המערכת, ותעודה שפגה מוחלפת בתעודה החתומה בעצמה המובנית במערכת. החלפה זו היא הסיבה לאזהרת הדפדפן באתר שעבד אתמול.

שתי סיבות אחראיות לרוב המקרים. אימות HTTP דורש קבלת חיבורים נכנסים בפורט 80. לכן, סגירת פורט 80 בטענה ש"הכול ממילא HTTPS" משבשת את החידוש לכל יישום שמשתמש ב־Wildcard או ב־Manual DNS backend. אימות DNS דורש אסימון API שעדיין יש לו הרשאת כתיבה. לכן, החלפת האסימון או צמצום הרשאותיו משבשים את החידוש בלי הודעה מיידית, עד שהודעת האזהרה מגיעה.

בתצוגת Domains יש לחצן Renew All שמאלץ את ניסיון החידוש באופן מיידי, וכן ספק Let's Encrypt Staging לצורכי בדיקה. תעודות Staging אינן מהימנות בעיני הדפדפנים בכוונה. זו בדיוק מטרתן: אפשר לנסות שוב ושוב בלי לצרוך את מגבלת הקצב של סביבת הייצור.

האם כדאי להשתמש בשרת הדואר המובנה?

Cloudron מספקת מחסנית דואר מלאה עם תיבות IMAP, שליחת דואר, מסנני sieve וחתימת DKIM (DomainKeys Identified Mail). מפעילים אותה לכל מתחם בנפרד, תחת Email בלוח הבקרה. האתגר העיקרי הוא להעביר את הדואר ליעדו, וקושי זה אינו נובע מ־Cloudron.

• רוב ספקי ה־VPS חוסמים את הפורט היוצא 25 כדי לצמצם דואר זבל. חלקם מסירים את החסימה לאחר פתיחת פנייה לתמיכה. בדקו מהשרת באמצעות nc -zv aspmx.l.google.com 25 (התקינו את netcat-openbsd אם הפקודה אינה קיימת). הפורטים הפתוחים מדווחים באמצעות succeeded, ופורט חסום נשאר ללא תגובה עד לפקיעת הזמן הקצוב.
• רשומת PTR (DNS הפוך) מוגדרת על ידי ספק ה־VPS, ולא על ידי ספק ה־DNS, והיא חייבת להתאים לשם המתחם של שרת הדואר. דואר מכתובת עם PTR כללי מגיע לתיקיות הספאם.
• רשומות SPF, DKIM ו־DMARC נכתבות עבורכם כאשר משתמשים ב־API DNS backend. ב־Wildcard או ב־Manual backend יש להוסיף אותן ידנית, ורשומת DKIM חסרה גורמת לכך שכל הודעה שאתם חותמים אינה ניתנת לאימות.

התצורה שמתאימה לרוב המשתמשים היא לקבל דואר ב־Cloudron ולשלוח אותו דרך relay כגון SendGrid, Postmark, Mailgun או Amazon SES, כפי שמוגדר בתצוגת Email. ה־relay חייב לאפשר שליחה מכל כתובת במתחם שלכם. אחרת, התראות יישומים משולחים שונים יידחו. אם הדואר הוא הסיבה העיקרית לרכישת השרת, הפעילו שרת דואר ייעודי כגון Mailcow על מחשב נפרד, עם כתובת IP ומוניטין משלה.

אם אינכם משתמשים כלל ב־Cloudron Email, חסמו את הפורטים 25, 465, 587, 993 ו־4190 בחומת האש של הספק. בצעו זאת שם ולא בשרת, משום ש־Cloudron כותבת בעצמה את כללי ה־iptables ומצפה לנהל אותם. זה ההפך מ־VPS רגיל, שבו אתם מנהלים בעצמכם את כללי ufw.

הגדירו את יעד הגיבוי לפני שתזדקקו לו

כברירת מחדל, הגיבויים נשמרים במערכת הקבצים המקומית ב־/var/backups, באותו דיסק שבו נמצא כל השאר. התיעוד מציין זאת במפורש: "שמירת הגיבויים באותו דיסק פיזי שבו נמצא שרת הפלטפורמה היא מסוכנת." כשל בדיסק אחד משבית יחד את היישומים ואת הגיבויים.

פתחו את Backups ולאחר מכן את Backup Sites, והפנו אותם ליעד אחר כבר ביום הראשון. אחסון אובייקטים תואם־S3 הוא הבחירה המקובלת (Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces, או מכל MinIO בשרת שני). נתמכים גם SSHFS, NFS, CIFS ויעדים רגילים של מערכת הקבצים.

שלוש הגדרות קובעות אם כדאי להסתמך על הגיבוי:

• Format. tgz יוצר ארכיון דחוס אחד לכל יישום ומעלה מחדש את כולו בכל הרצה. rsync מעלה רק קבצים שהשתנו, ולכן הוא זול בהרבה עבור Nextcloud גדול, אך גורם למספר רב יותר של בקשות מול ממשק ה־API של האחסון.
• Encryption. הצפנת AES-256 אופציונלית, המכסה הן את תוכן הקבצים והן את שמות הקבצים. Cloudron אינו שומר עותק של הסיסמה, ולכן אם תאבדו אותה, איש לא יוכל לפענח את הגיבויים, גם לא אתם. שמרו אותה ב־מנהל סיסמאות באירוח עצמי לפני שתלחצו על שמירה.
• Retention. הערך נכתב כמספרים, למשל 7 גיבויים יומיים ו־4 גיבויים שבועיים. שמירת גיבויים לאורך זמן באחסון אובייקטים תחייב אתכם בתשלום חודשי, לכן בחרו מספר שאתם מוכנים להמשיך לשלם עבורו.

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

מגבלות התוכנית החינמית

נכון ל־August 2026, התוכנית החינמית מוגבלת ל־2 יישומים מותקנים. כל שאר הרכיבים כלולים בה: עדכוני יישומים, גיבויים נפרדים לכל יישום, ה־firewall, שרת הדואר ו־single sign-on. היישום השלישי הוא הנקודה שבה נדרש רישיון. התוכניות בתשלום מסירות את מגבלת מספר היישומים, והתוכנית היקרה יותר מוסיפה קבוצות ותפקידים של משתמשים, שרת directory וכמה אתרי גיבוי. המחירים משתנים, לכן בדקו את דף התמחור של Cloudron במקום להסתמך על מספר שמופיע במדריך.

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

כאשר משהו מתקלקל

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

sudo cloudron-support --troubleshoot

לאחר מכן השתמשו בכלים הרגילים של systemd (מנהל המערכת והשירותים). systemctl status box מציג את מצב שירות Cloudron עצמו, journalctl -u box -n 100 מציג את הלוגים האחרונים שלו, ו־journalctl -u docker בודק את סביבת הרצת המכולות שמתחתיו. כל תקלה שאירעה במהלך ההתקנה נשמרת ב־/var/log/cloudron-setup.log.

לוח מחוונים שאינו נטען נובע בדרך כלל מבעיית DNS או מ־firewall של ספק התשתית, ולא מ־Cloudron. הפעילו את dig +short my.example.com מהמחשב הנייד שלכם ואשרו ש־ports 80 ו־443 פתוחים ב־firewall של הרשת אצל הספק. זהו מנגנון בקרה נפרד מהכללים של השרת עצמו. אם אתם מתחילים מחדש, הסקריפט מסרב לריצה שנייה באמצעות Error: Cloudron is already installed. To reinstall, start afresh, והפתרון הנקי הוא לבנות את השרת מחדש.

כאשר Cloudron אינו מתאים

Cloudron מתאים כאשר אתם רוצים להפעיל יישומים ולא לנהל תשתית. הוא מתאים פחות כאשר אתם רוצים להפעיל את המכולות שלכם בדרך שלכם, משום שהוא מנהל את nginx, את Docker ואת ה־firewall, ועלול להחליף את ההגדרות שתציבו שם. אם התוכנית שלכם היא תיקייה עם קובצי compose, Traefik לפני מחסניות Docker Compose שלכם מספק את אותו TLS אוטומטי ואת אותו ניתוב לפי תת־דומיין, ללא פלטפורמה נוספת מעליהם. אם עדיין לא בחרתם, השוואה בין Cloudron, CasaOS ו־Coolify מציגה אותם זה לצד זה, ו־הרשימה הרחבה יותר של דברים לאירוח עצמי היא נקודת פתיחה טובה יותר ממדריך התקנה.

FAQ

כמה RAM דורש Cloudron ב־VPS?

סקריפט ההתקנה מסרב לפעול עם פחות מ־941 MB, והתיעוד דורש 2 GB, אך זו רק דרישת הסף לפלטפורמה ללא יישומים. Cloudron מפעיל Docker, את nginx, את שירות box שלו, מכולות מסד נתונים ואת מערך הדואר כבר מהאתחול הראשון. הקצו 4 GB עבור שני יישומים ו־16 GB עבור כ־10 יישומים, והוסיפו קובץ swap, משום ש־Cloudron מאפשר ליישומים שימוש בלתי מוגבל ב־swap, ומערכת ללא swap הופכת לחץ זיכרון לאתחולים מחדש.

האם אפשר להתקין Cloudron על Debian או על שרת שכבר מריץ Docker?

לא. אף אחת מהאפשרויות אינה נתמכת. הסקריפט בודק את גרסת ההפצה ונעצר עם Cloudron requires Ubuntu 20.04, 22.04, 24.04, ולכן Debian, Rocky ו־Alpine אינן מתאימות. הוא נעצר גם כאשר nginx, docker או node כבר קיימים, משום שהוא מתקין גרסאות מקובעות של כולם וכותב בעצמו את תצורת nginx ואת כללי iptables. התחילו מתמונת Ubuntu חדשה על VPS מבוסס KVM.

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

רשומת ה־DNS הכללית חסרה. ההתקנה יוצרת או דורשת רשומת A עבור my.example.com, ולכן לוח הבקרה נפתר, בעוד wiki.example.com מחזיר NXDOMAIN והדפדפן מדווח שהאתר לא נמצא. הוסיפו רשומת A עבור *.example.com, המפנה לכתובת ה־IP של השרת, ולאחר מכן אמתו באמצעות dig +short wiki.example.com לפני התקנת היישום.

האם חייבים להשתמש בשרת הדואר של Cloudron?

לא. אפשר להשבית דואר נכנס ולשלוח באמצעות ממסר חיצוני, כגון Postmark, Mailgun או Amazon SES. זו הבחירה הבטוחה יותר כאשר הספק חוסם את פורט 25 היוצא או כאשר לכתובת ה־IP אין מוניטין דואר. אם אינכם משתמשים כלל ב־Cloudron Email, סגרו את הפורטים 25, 465, 587, 993 ו־4190 ב־firewall של הספק, ולא בשרת עצמו.

מה קורה כאשר מגיעים למגבלה של שני יישומים במסלול החינמי?

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