איך מריצים אפליקציית Base44 מקומית, ומה עדיין רץ ב-⁠Base44

בקצרה

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

• להריץ את הקוד המיוצא עם npm install ו-npm run dev. הממשק רץ על המחשב שלכם, אבל כל רשומה, התחברות, פונקציה וקריאה לאינטגרציה עדיין הולכות לשרתים של Base44, עם הנתונים האמיתיים שלכם.
• להריץ את שרת הפיתוח של ה-⁠CLI של Base44 עם base44 dev. פונקציות השרת, הרשומות, ההעלאות וההתחברות עם אימייל וסיסמה רצות על המחשב שלכם, והרשומות נשמרות במסד נתונים זמני בזיכרון. התחברות עם Google ועם רשתות חברתיות אחרות, שליחת מיילים וקריאות ל-⁠AI מועברות לאפליקציה שלכם ב-⁠Base44, ואוטומציות לא רצות.

שתי הדרכים הן כלים לפיתוח אפליקציית Base44. אף אחת מהן לא מריצה את האפליקציה בלי Base44, ונכון לאוקטובר 2026 התיעוד של Base44 לא מזכיר את Docker בכלל. כדי להריץ את כל האפליקציה על המחשב שלכם, כולל השרת ומסד הנתונים שלה, היא צריכה צד שרת (backend) משלה. אפליקציה שהועברה עם Unbase44 רצה מקומית בפקודה אחת, docker compose up.

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

מה רץ איפה

אפשרות 1: להריץ את הקוד המיוצא מול Base44

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

npm install
npm run dev

התיעוד של Base44 על מבנה הפרויקט נותן בדיוק את שתי הפקודות האלה. הפרויקט הוא אפליקציית React רגילה שבנויה עם Vite, ובתיקייה src/api שלו נמצא לקוח ה-⁠SDK של Base44, שמדבר עם צד השרת שלכם.

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

המדריך שלנו על ייצוא מ-⁠Base44 מסביר מה יש ב-⁠ZIP ובסנכרון ל-⁠GitHub, ומה הם משאירים מאחור.

אפשרות 2: שרת הפיתוח של Base44

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

מה צריך

• Node.js 20.19.0 ומעלה, שה-⁠CLI דורש.
• Deno, אם יש לאפליקציה פונקציות שרת. Base44 מריצה כל פונקציה כתהליך Deno נפרד, ואת Deno מתקינים בנפרד.
• עותק מקומי של האפליקציה. התיעוד של Base44 על האינטגרציה עם GitHub מתאר את ההגדרה לאפליקציה שמסונכרנת עם GitHub, וזה דורש מסלול Builder ומעלה.

השלבים לאפליקציה שמסונכרנת עם GitHub

מתוך התיעוד של Base44 על האינטגרציה עם GitHub:

git clone <your repository URL>
cd <your project>
npm install
npm install -g base44@latest
base44 login
base44 link
base44 dev

base44 login מחבר אתכם בקוד אישור (device code), ו-base44 link מקשר את העותק לאפליקציה שלו ב-⁠Base44 (כל עותק חדש צריך את השלב הזה). ‏base44 dev מפעיל צד שרת מקומי בכתובת http://localhost:4400, ולצידו את שרת הפיתוח של צד הלקוח (frontend), באותו טרמינל. ‏Ctrl-C עוצר את שניהם.

מה רץ מקומית, ומה לא

הסקירה של Base44 על פיתוח מקומי מדויקת בעניין הזה:

• פונקציות רצות על המחשב שלכם ונטענות מחדש כשעורכים אותן; הפלט שלהן מודפס בטרמינל.
• רשומות נשמרות במסד נתונים בזיכרון. הוא מתחיל ריק ומתרוקן כשעוצרים את השרת, ושינוי בסכמה של טבלה מוחק את הנתונים המקומיים של אותה טבלה.
• העלאות נשמרות בתיקייה זמנית ונמחקות כשהשרת נעצר, עד 50 MB לקובץ.
• התחברות עם אימייל וסיסמה רצה מקומית. קוד האימות של משתמש חדש מודפס בטרמינל במקום להישלח במייל, וחשבון המפתח שלכם יכול להתחבר עם כל סיסמה.
• מועברים ל-⁠Base44: התחברות עם Google ועם רשתות חברתיות אחרות, אינטגרציות מובנות כמו שליחת מיילים ויצירת תוכן עם AI, ואינטגרציות מותאמות אישית.
• אוטומציות לא רצות מקומית.

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

אפשרויות נוספות ב-⁠Base44

• base44 scaffold מכין קבצים מקומיים לצד השרת של אפליקציה (טבלאות, פונקציות, סוכנים), בזמן שצד הלקוח נשאר בעורך של Base44. ‏Base44 מציעה אותו אם אין לכם מסלול שכולל סנכרון ל-⁠GitHub.
• base44 eject מעתיק אפליקציה לפרויקט Base44 חדש ונפרד, עם מזהה אפליקציה (app ID) משלו ומסד נתונים ריק. האפליקציה המקורית לא משתנה, ומאותו רגע השתיים עצמאיות. העותק עדיין מאוחסן ב-⁠Base44.
• ה-⁠sandbox בענן מאפשר לכם, או לסוכן הקוד שלכם, לעבוד על הקוד של האפליקציה במקום שבו Base44 שומרת אותו, בלי עותק מקומי. הוא דורש מסלול Builder ומעלה.

אפשר להריץ אפליקציית Base44 ב-⁠Docker?

לא כאפליקציה שלמה. Base44 לא מתארת בשום מקום בתיעוד שלה Docker image או הגדרת Docker לצד השרת שלה, והיא לא מתעדת גרסה לאחסון עצמי. אפשר לשים את צד הלקוח המיוצא בקונטיינר כמו כל אפליקציית Vite אחרת, אבל הקונטיינר עדיין יפנה לשרתים של Base44 בשביל כל מה שמאחורי הממשק.

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

סביבת staging: לבדוק שינויים לפני שהמשתמשים רואים אותם

ב-⁠Base44

היכולת של Base44 שהכי קרובה לסביבת staging היא Test Data (נתוני בדיקה) (בדיקת האפליקציה עם נתוני בדיקה), במסלול Builder ומעלה:

• ההפעלה שלה יוצרת מסד נתונים נפרד לבדיקות. הוא מתחיל ריק; נתוני הפרודקשן שלכם לא מועתקים אליו.
• בלוח הבקרה (Dashboard) ובתצוגה המקדימה עוברים בין נתוני הפרודקשן לנתוני הבדיקה.
• קישור בדיקה (testing link) מאפשר לחברי צוות או ללקוחות לנסות שינויים שעוד לא פורסמו, מול נתוני הבדיקה.
• האפליקציה שפורסמה תמיד משתמשת בנתוני הפרודקשן. מצב הבדיקה משפיע רק על לוח הבקרה ועל התצוגה המקדימה.

לשינויי קוד, הסנכרון ל-⁠GitHub נותן ענפים (branches) ו-⁠pull requests. השינויים מגיעים ל-⁠Base44 כשהם ממוזגים ל-main, ועולים לאוויר כשלוחצים על Publish. שרת הפיתוח המקומי מוסיף סביבת ניסוי פרטית על המחשב שלכם.

אחרי העברה

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

אחרי המעבר המאגר בבעלותכם, וסביבת staging עובדת לפי מה שספק האחסון שלכם מציע. ב-⁠Railway, כל push לענף main של המאגר פורס את האפליקציה. הסביבות (environments) של Railway מאפשרות לפרויקט להחזיק סביבת staging נפרדת, שבדרך כלל נפרסת מענף staging, ויכולות ליצור סביבות זמניות ל-⁠pull requests. בשרת משלכם, עותק שני יכול לרוץ על מכונה שנייה.

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

כש-⁠Unbase44 מעביר אפליקציה, הכול נכנס למאגר פרטי בחשבון ה-⁠GitHub שלכם: צד הלקוח ב-⁠React שלכם, צד שרת תואם Base44 שכתוב ב-⁠Deno וב-⁠TypeScript, קובצי ה-⁠Docker, ותיעוד לאנשים ולסוכני קוד, כולל מדריך לפיתוח מקומי (docs/LOCAL_DEVELOPMENT.md), ‏README, ‏AGENTS.md ו-⁠CLAUDE.md.

כדי להריץ אותה על המחשב שלכם:

1. מתקינים Docker. ב-⁠Mac או במחשב Windows, זה בדרך כלל Docker Desktop.
2. משכפלים את המאגר.
3. בתיקייה שלו מריצים:

docker compose up

זה מפעיל את האפליקציה ואת מסד הנתונים שלה על המחשב שלכם. השרת שעונה לקריאות של האפליקציה הוא זה שבמאגר שלכם, לא של Base44, כך שאפשר לשנות פונקציה, טבלה או דף ולראות את התוצאה מקומית לפני שדוחפים (push). אימייל ו-⁠AI עוברים דרך הספקים שהגדרתם: חשבון ה-⁠Resend או שרת ה-⁠SMTP שלכם, ומפתח OpenRouter, ‏OpenAI, ‏Anthropic או Gemini משלכם.

מכיוון ש-⁠AGENTS.md ו-⁠CLAUDE.md נכתבו לסוכני קוד, Claude Code, ‏Cursor או סוכן אחר יכולים לקרוא בהם איך להפעיל את האפליקציה ולעבוד עליה. ב-⁠Railway, כל push ל-⁠main פורס אחר כך את השינוי שלכם.

מה מתאים לכם?

• אתם רוצים לשפר דפים ועיצוב, ונשארים ב-⁠Base44: מייצאים את הקוד ומריצים npm run dev, בזהירות, כי הוא עובד על הנתונים האמיתיים.
• אתם מפתחים שמשנים פונקציות שרת או טבלאות ב-⁠Base44: עובדים עם base44 dev, ועם Test Data לכל מה שהלקוח שלכם צריך לנסות.
• אתם רוצים את כל האפליקציה, כולל השרת ומסד הנתונים, על המחשב שלכם או על שרת משלכם: האפליקציה צריכה צד שרת משלה. Unbase44 מעביר אותה לצד שרת כזה; הניתוח חינמי, ומראה מה יש באפליקציה שלכם ומה המחיר לפני שמחברים משהו או משלמים.