אפשר לארח אפליקציית Base44 בעצמכם? התשובה המלאה

מה אחסון עצמי של אפליקציית Base44 צריך לכלול

במונח "אחסון עצמי" (self-hosting) משתמשים בצורה די חופשית, אז כדאי לדייק. כדי שאפליקציית Base44 תרוץ בלי Base44, כל אחד מהחלקים האלה צריך להתקיים במקום שבשליטתכם:

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

מה אפשר להריץ בעצמכם עם הכלים של Base44 עצמה

Base44 לא מציעה גרסה לאחסון עצמי או להתקנה בשרתי הארגון (on-premises), ולא מתעדת גרסה כזו. היא כן נותנת שלושה כלים שלפעמים מתבלבלים בינם לבין גרסה כזו.

אחסון צד הלקוח במקום אחר. אפשר להשתמש ב-⁠Base44 כשירות צד שרת (backend) מאחורי צד לקוח משלכם. הסקירה של כלי המפתחים של Base44 אומרת שכשעולים לאוויר, אפשר להמשיך לארח את צד הלקוח במקום אחר, או לפרוס את הקבצים הבנויים שלו לאחסון של Base44. כשהוא מאוחסן במקום אחר, הדפים נטענים מהשרת שלכם, בזמן שהנתונים, ההתחברות, הפונקציות והאינטגרציות עדיין רצים ב-⁠Base44. זה מבנה לגיטימי, אבל הוא מעביר את החלק הכי פחות חשוב.

שרת הפיתוח המקומי. base44 dev מריץ צד שרת על המחשב שלכם לצורכי פיתוח. הפונקציות רצות מקומית על Deno, הרשומות נשמרות במסד נתונים בזיכרון שמתרוקן כשעוצרים אותו, וההעלאות נשמרות בתיקייה זמנית. התחברות OAuth ואינטגרציות מובנות כמו אימייל ו-⁠AI מועברות ל-⁠Base44, ואוטומציות לא רצות מקומית (פיתוח מקומי). הוא בנוי כדי לבדוק שינויים בבטחה, לא כדי לשרת משתמשים.

הפקודה eject. base44 eject מעתיק אפליקציה לפרויקט Base44 חדש ונפרד, עם מזהה אפליקציה (app ID) משלו ומסד נתונים ריק (eject). העותק עדיין מאוחסן ב-⁠Base44.

החלק החסר: צד שרת שמדבר ב-⁠API של Base44

הקוד של האפליקציה שלכם נכתב מול ה-⁠SDK של Base44. צד הלקוח מבקש רשומות מה-⁠SDK, וה-⁠SDK שולח בקשת HTTP לנקודת קצה (endpoint) של Base44 עבור אותה ישות (entity), עם שאילתה שכתובה בתחביר האופרטורים של MongoDB. הפונקציות בונות client מהבקשה שנכנסת וקוראות חזרה לאותו API, לפעמים עם הרשאת service role שעוקפת את כללי האבטחה. העלאות מחזירות כתובות URL באחסון של Base44. דפים פתוחים נרשמים לשינויים דרך חיבור בזמן אמת.

לכן יש שתי דרכים לאחסון עצמי אמיתי:

1. לשכתב את האפליקציה לצד שרת אחר. מחליפים כל קריאה ל-⁠SDK בקריאות ל-⁠Supabase, ל-⁠Firebase או ל-⁠API משלכם, מתרגמים את מודל הנתונים ואת כללי האבטחה, ומעבירים את הפונקציות. זה פרויקט שנמדד בשבועות, ובסופו כל משתמש מאפס את הסיסמה שלו. המדריך שלנו ל-⁠Supabase עובר על זה צעד אחר צעד.
2. להריץ צד שרת שעונה לאותו API. אם משהו בשרת שלכם עונה ל-⁠SDK בדיוק כמו Base44, לא צריך לשכתב את האפליקציה. צד הלקוח נבנה מחדש כשהוא מכוון לשרת שלכם, והפונקציות רצות בלי שינוי.

הדרך השנייה היא זו ש-⁠Unbase44 מעביר אתכם אליה.

איך נראית אפליקציה באחסון עצמי עם Unbase44

אחרי ההעברה, האפליקציה שלכם היא מאגר (repository) בחשבון ה-⁠GitHub שלכם, במבנה הזה:

your-app/
├─ src/              your original React frontend
├─ base44/           entities, functions, agents, workflows, config
├─ server/           the Base44-compatible backend (Deno + TypeScript)
├─ docs/             architecture, local development, deployment
├─ Dockerfile
├─ docker-compose.yml
├─ README.md, AGENTS.md, CLAUDE.md

צד השרת פתוח ומתועד, והוא רץ על MongoDB, אותו סוג של מסד נתונים מבוסס מסמכים ש-⁠Base44 משתמשת בו, כך שהרשומות עוברות בלי תרגום ושומרות על המזהים שלהן. הוא מגיש את צד הלקוח, את ה-⁠API, את דפי ההתחברות ואת העדכונים בזמן אמת מכתובת אחת.

אתם בוחרים איפה הוא רץ:

ב-⁠Railway, כל push ל-main פורס מחדש את האפליקציה. לפיתוח מקומי, הגדרת ה-⁠Docker מפעילה את האפליקציה ואת מסד הנתונים שלה על המחשב הנייד שלכם בפקודה אחת. המשתמשים שומרים על הסיסמאות שלהם: ההתחברות הראשונה של כל אדם נבדקת מול Base44 פעם אחת, ומאז הסיסמה נשמרת כ-⁠hash של האפליקציה שלכם עצמה. לכן משאירים את אפליקציית ה-⁠Base44 מפורסמת עד שהמשתמשים הפעילים שלכם התחברו.

Vercel ו-⁠Netlify: למה ספק אחסון לצד הלקוח לבד לא מספיק

החיפושים "Base44 to Vercel" ו-"Base44 on Netlify" מתכוונים בדרך כלל לאחד משני דברים, והתשובות שונות.

צד הלקוח ב-⁠Vercel, ו-⁠Base44 עדיין כצד השרת. זה עובד, ו-⁠Base44 מתעדת את זה: אפשר להמשיך לארח את צד הלקוח במקום אחר ולהשתמש ב-⁠Base44 כצד השרת (כלי המפתחים). האפליקציה המיוצאת היא build רגיל של Vite, כך ששני הספקים יכולים להגיש אותה. ההתחברויות, הרשומות, הפונקציות והאינטגרציות עדיין הולכות ל-⁠Base44, יחד עם המסלול והקרדיטים שלה. העברתם את החלק שאף פעם לא היה הבעיה.

כל האפליקציה ב-⁠Vercel או ב-⁠Netlify, בלי Base44. לא עם השירותים האלה לבדם. הם בנויים להגיש צד לקוח ולהריץ פונקציות קצרות, וצד השרת של אפליקציית Base44 צריך דברים שנשארים במקום:

• מסד נתונים ואחסון קבצים. אף אחד משני הספקים לא מספק אותם. תצטרכו להוסיף שירותים נפרדים לשניהם.
• תהליך שנשאר ער. אוטומציות ותהליכי עבודה צריכים לפעול לפי לוח זמנים ובשינויים בנתונים, ודפים פתוחים מחזיקים חיבורי זמן אמת. מגבלות הפונקציות של Netlify הן 60 שניות לפונקציה רגילה, 30 שניות לפונקציה מתוזמנת ו-⁠15 דקות לפונקציית רקע. פונקציות ב-⁠Vercel רצות לכל היותר 5 דקות במסלול Hobby ו-⁠800 שניות במסלול Pro, ו-⁠30 דקות בבטא (מגבלות).
• קונטיינרים שממשיכים לרוץ. נכון לאוקטובר 2026, ‏Vercel יכולה להריץ Docker image, אבל כפונקציה בלי מצב (stateless). ההשוואה של Vercel עצמה ל-⁠Render אומרת שכל מופע לא שומר כלום בין בקשות, מצטמצם (scale down) אחרי חמש דקות בלי תעבורה, ולא רץ כ-⁠worker ברקע או כ-⁠cron job. התמיכה שלה ב-⁠WebSocket נמצאת בבטא ציבורית, וכל חיבור נסגר כשהפונקציה מגיעה למגבלת הזמן שלה (Vercel).

אין בזה פגם; הפלטפורמות האלה תוכננו לעבודה אחרת. אפליקציית Base44 על תשתית שבבעלותכם צריכה שרת שרץ ברציפות, ולכן אפשרויות האחסון של Unbase44 הן Railway ושרתי Linux, ולא ספקי אחסון לצד לקוח. אם במקום זה משכתבים את האפליקציה ל-⁠Supabase, ‏Vercel או Netlify יכולים להגיש את צד הלקוח שנבנה מחדש, בזמן ש-⁠Supabase עושה את העבודה של צד השרת.

שרת ב-⁠AWS, ב-⁠Azure או VPS

"כל שרת Linux עם SSH" כולל הרבה יותר ממחשב מתחת לשולחן:

• AWS. מופע EC2 או Lightsail שמריץ Linux הוא שרת שמתחברים אליו ב-⁠SSH (AWS: חיבור ב-⁠SSH). AWS כאפשרות אחסון מובנית, כולל הגדרה שמוכנה ל-⁠HIPAA, תגיע בקרוב.
• Azure. מכונה וירטואלית עם Linux עובדת באותה צורה (Azure: יצירת מכונה וירטואלית עם Linux).
• כל VPS. ‏Hetzner, ‏DigitalOcean, ‏OVH או ספק מקומי: אם אפשר להתחבר ב-⁠SSH, האפליקציה יכולה לרוץ שם.

Unbase44 מתחבר ב-⁠SSH, מתקין את האפליקציה ואת מסד הנתונים שלה עם Docker, ומגדיר HTTPS אוטומטית. אצל ספק ענן, בודקים קודם את חומת האש: ב-⁠AWS קוראים לה security group, וב-⁠Azure ‏network security group. היא צריכה לאפשר SSH ותעבורת ווב בפורטים 80 ו-⁠443, אחרת אי אפשר להנפיק את התעודה, והמבקרים לא יכולים להגיע לאפליקציה.

שרת משלכם אומר גם שהמשימות שמפורטות בהמשך (עדכונים, גיבויים, ניטור) עליכם. אם זה יותר ממה שאתם רוצים, Railway מטפלת במכונה בשבילכם.

כמה זה עולה

המסלול החודשי ב-⁠Base44 נעלם. המחירים של Base44 נעים מ-⁠$16 לחודש (Starter) ועד $160 לחודש (Elite) בחיוב שנתי, או $20 עד $200 בחיוב חודשי, והמסלול קובע גם את הקרדיטים החודשיים שלכם.

במקום זה, משלמים לספקים על מה שמשתמשים בו:

• אחסון ומסד נתונים. ב-⁠Railway, מסלול Hobby עולה $5 לחודש וכולל שימוש בשווי $5 (המחירים של Railway, נכון לאוקטובר 2026); אפליקציות עמוסות יותר עולות יותר, ביחס לתעבורה ולנתונים שלהן. בשרת משלכם, העלות היא מה שהשרת עולה. במהלך ההגדרה רואים כמה כל אפשרות צפויה לעלות לפני שבוחרים.
• AI. הקריאות הולכות לחשבון ספק ה-⁠AI שאתם מחברים, ומחויבות לפי שימוש על ידי אותו ספק.
• אימייל. קודי התחברות ומיילים של האפליקציה עוברים דרך ספק האימייל שלכם, במסלול שלו.

ההעברה עצמה היא מחיר חד-פעמי לכל אפליקציה, וחינמית בתקופת הבטא.

מה לוקחים על עצמכם באחסון עצמי

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

• עדכונים. בפלטפורמה מנוהלת כמו Railway, מערכת ההפעלה ומנוע מסד הנתונים מטופלים בשבילכם. בשרת משלכם, העדכונים שלהם עליכם.
• גיבויים. מפעילים גיבויים אוטומטיים למסד הנתונים (גם Atlas וגם Railway מציעים אותם) ובודקים שחזור פעם אחת. ב-⁠Base44, מתחת למסלול Elite, לא היו לכם גיבויים אוטומטיים בכלל, כך שלא פעם זה שיפור.
• ניטור. מגדירים בדיקות זמינות (uptime) ומסתכלים בלוגים כשמשהו מרגיש איטי.
• אבטחה. שומרים את המפתחות הסודיים בהגדרות הייעודיות להם אצל ספק האחסון, מגבילים את הגישה לחשבונות שלכם, ובודקים את הרשאות הגישה של האפליקציה.
• קיבולת. אם התעבורה גדלה, מגדילים את השרת או את מסד הנתונים. זו הגדרה, לא פנייה לתמיכה.

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