איך לייצא את הקוד מ-⁠Base44, ומה הייצוא משאיר בחוץ

בקצרה

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

• הורדת הפרויקט כקובץ ZIP מלשונית Code (הקוד). מקבלים את הפרויקט של צד הלקוח (frontend), כולל קובצי הפונקציות והגדרות הטבלאות.
• סנכרון דו-כיווני ל-⁠GitHub. אותו קוד, במאגר (repository) שאתם בוחרים, שמתעדכן אוטומטית.
• ה-⁠CLI של Base44, כולל הפקודה base44 eject, שמעתיקה אפליקציה לפרויקט Base44 חדש ונפרד עם מסד נתונים ריק.
• ייצוא CSV, טבלה אחת בכל פעם, מאזור "Data" (הנתונים) בלוח הבקרה.

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

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

אפשרות 1: הורדת הפרויקט כ-⁠ZIP

פותחים את האפליקציה, עוברים ל-Code, ולוחצים על הסמל Export project as ZIP (ייצוא הפרויקט כ-⁠ZIP) בפינה הימנית העליונה של תצוגת הקוד. דף כלי הפיתוח של Base44 מציין שגם הורדת ה-⁠ZIP וגם החיבור ל-⁠GitHub דורשים מסלול Builder ומעלה.

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

• src/pages, קובץ אחד לכל נתיב (Home.jsx הופך ל-/, ‏Settings.jsx הופך ל-/settings)
• src/components, כולל תיקיית ui/ עם רכיבים מוכנים
• src/api, הגדרות הלקוח של ה-⁠SDK של Base44
• src/hooks, ‏src/lib ו-src/utils
• entities/, קובץ סכמת JSON אחד לכל טבלה
• functions/, קובץ TypeScript אחד לכל פונקציית שרת
• package.json (שכולל את @base44/sdk), קובץ vite.config.js עם תוסף ה-⁠Vite של Base44, קובץ הגדרות של Tailwind ו-index.html

לפי דף מבנה הפרויקט של Base44, אפשר להריץ אותו עם npm install ו-npm run dev. מה שתראו הוא הממשק של האפליקציה, שמדבר עם צד השרת (backend) של Base44. הנתונים שמוצגים הם הנתונים האמיתיים שלכם, ו-⁠Base44 היא שמגישה אותם.

מתי ה-⁠ZIP הוא הכלי הנכון: גיבוי של הקוד, מסירה למפתח שרוצה לקרוא אותו, או תמונת מצב לפני סבב מסוכן של עריכות AI.

אפשרות 2: סנכרון דו-כיווני ל-⁠GitHub

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

• הוא דורש מסלול Builder ומעלה, ורק בעלים של האפליקציה יכולים ליצור את החיבור הראשון.
• שינויים ב-⁠Base44 נדחפים למאגר אוטומטית; אין push ידני.
• שינויים שעושים מקומית מגיעים ל-⁠Base44 כשממזגים אותם לענף בשם main. עדיין צריך ללחוץ על Publish (פרסום) ב-⁠Base44 כדי שיעלו לאוויר.
• הישויות (entities) מנוהלות ב-⁠Base44 ולא נמצאות במאגר, כך שהגדרות הטבלאות לא חלק ממה שמסתנכרן.
• אחרי החיבור, ה-⁠Version History (היסטוריית הגרסאות) לא יכול לשחזר גרסאות מלפני החיבור, כי הגרסאות האלה לא נמצאות במאגר.
• אפשר לנתק ואחר כך לחבר מחדש את אותו מאגר, חוץ מכמה מקרים ש-⁠Base44 מפרטת: גם באפליקציה וגם במאגר יש commits חדשים מאז הפעם האחרונה שהם היו מתואמים; שם המאגר שונה, הוא נמחק או שענף ברירת המחדל שלו השתנה; או שהוא חובר מסביבת עבודה אחרת. במקרים האלה מתחילים מאגר חדש.

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

אפשרות 3: ה-⁠CLI של Base44 והפקודה base44 eject

ל-⁠CLI של Base44 (npm install -g base44@latest) יש שתי פקודות שאנשים פונים אליהן כשהם רוצים לצאת.

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

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

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

אפשרות 4: ייצוא הנתונים כ-⁠CSV

בלוח הבקרה פותחים את Data, בוחרים טבלה, לוחצים על More actions (פעולות נוספות) ואז על Export (ייצוא). מקבלים את הטבלה כקובץ CSV (ניהול נתוני האפליקציה).

שלושה פרטים שכדאי להכיר לפני שסומכים על זה:

1. טבלה אחת בכל פעם. אפליקציה עם עשרים טבלאות פירושה עשרים ייצואים, והקשרים ביניהן הם רק מזהים ששמורים בשדות. שומרים על המזהים כשמעבירים את הנתונים, אחרת הקישורים האלה נשברים.
2. תצוגת הטבלה נעצרת ב-⁠5,000 שורות, ה-⁠CSV לא. לפי התיעוד של Base44, הטבלה בלוח הבקרה מציגה עד 5,000 פריטים, והתיעוד ממליץ לייצא ל-⁠CSV כדי לראות הכול.
3. משתמשים הם סיפור אחר. משתמשי האפליקציה נמצאים באזור "Users" (המשתמשים), והתיעוד של Base44 עצמה על פרטיות ואבטחה קובע שאי אפשר לייצא משתמשי אפליקציה: כשהוא מתאר שכפול של אפליקציה לאזור גיאוגרפי אחר, הוא אומר שהמשתמשים יצטרכו להירשם מחדש. ה-⁠hash של הסיסמאות אף פעם לא יוצא מ-⁠Base44.

גם בכיוון ההפוך יש מגבלות: ייבוא CSV ל-⁠Base44 רק מוסיף שורות חדשות, ואף פעם לא מעדכן רשומות קיימות.

ייצוא במסלול Free

במסלול Free, הרשומות הן הדבר היחיד שאפשר להוציא דרך לוח הבקרה: ייצוא ה-⁠CSV שתואר למעלה עובד טבלה אחר טבלה. כל דרך מתועדת להוציא את הקוד מופיעה עם דרישה למסלול Builder: הורדת ה-⁠ZIP, הסנכרון ל-⁠GitHub, וגישה מחוץ לעורך אל ה-⁠sandbox של האפליקציה בענן, שנכשלת עם שגיאת "premium required" במסלולים שמתחת ל-⁠Builder.

נשארות שלוש דרכים שאנשים בודקים.

משדרגים לחודש, מייצאים, וחוזרים למסלול נמוך

זו הדרך המתועדת, והאפשרות הזולה ביותר היא חודש אחד של Builder. נכון לאוקטובר 2026, ‏Builder עולה $50 בחיוב חודשי או $40 לחודש בחיוב שנתי; Starter ‏($20 בחיוב חודשי) לא כולל את GitHub ואת ה-⁠ZIP (מחירים). בוחרים חיוב חודשי. התנאים של Base44 מגדירים תשלומים שנתיים כלא ניתנים לביטול ולא ניתנים להחזר.

1. משדרגים. בהגדרות סביבת העבודה פותחים את Plan and billing (מסלול וחיוב) ומשדרגים ל-⁠Builder. לפי תיעוד החיוב של Base44, שדרוג נכנס לתוקף ברגע שמשלמים.
2. לוקחים כל מה שאפשר. מחברים את GitHub (המאגר נוצר בחשבון ה-⁠GitHub שלכם), מורידים גם את ה-⁠ZIP, ומייצאים כל טבלה ל-⁠CSV. כשאתם כבר שם, רושמים את השמות של המפתחות הסודיים (secrets), את הקונקטורים ואת רשומות ה-⁠DNS של הדומיין.
3. חוזרים למסלול נמוך או מבטלים. מעבר למסלול נמוך נכנס לתוקף בסוף תקופת החיוב הנוכחית, וכך גם ביטול, כך ש-⁠Builder נשאר אצלכם לחודש ששילמתם עליו. הביטול לא מחזיר את הכסף על החודש הזה.
4. יודעים מה נשאר אצלכם. ה-⁠ZIP והמאגר נשארים שלכם. Base44 מציגה את הסנכרון ל-⁠GitHub כיכולת של Builder, אז לא כדאי לסמוך על כך שהוא ימשיך אחרי המעבר למסלול נמוך. האפליקציות נשארות באוויר במסלול Free, בלי היכולות בתשלום.

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

הפקודה base44 eject

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

תוספי דפדפן מסוג "Downloader" ו-"Code extractor"

חיפוש של ייצוא חינמי מ-⁠Base44 מעלה תוספים ל-⁠Chrome, חלקם ב-⁠Chrome Web Store וחלקם מפורסמים כקוד מקור ב-⁠GitHub, שמציעים להוריד את הקוד של פרויקט כ-⁠ZIP. התיעוד של Base44 לא מזכיר אף אחד מהם.

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

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

הסיכונים נוגעים לחשבון שלכם, לא לקוד:

• התוסף פועל בשמכם. תוסף שמורשה לקרוא ולשנות נתונים באתר של Base44 עובד בתוך החיבור הפעיל שלכם, כך שהוא יכול לעשות כל מה שאתם יכולים לעשות שם, בכל אפליקציה שיש לכם גישה אליה. דף העזרה של Google על Chrome Web Store מסביר את אזהרות ההרשאה האלה: הן לא אומרות שתוסף מזיק, רק שהוא יכול להיות מזיק.
• התוסף יכול להשתנות אחרי שהתקנתם אותו. Chrome בודק עדכונים לתוספים מותקנים כל כמה שעות, כך שהקוד שסמכתם עליו ביום הראשון הוא לא בהכרח הקוד שרץ אחר כך.
• לתנאים של Base44 יש מה לומר. תנאי השימוש מבקשים לשמור על פרטי ההתחברות בסוד ולתת גישה לחשבון רק לאנשים שאתם סומכים עליהם, ומטילים עליכם אחריות לכל מה שנעשה בחשבון שלכם. סעיף השימושים האסורים גם אוסר גישה לפלטפורמה באמצעים אוטומטיים, כמו סריקה (crawling) או גירוד נתונים (scraping), שלא דרך הממשק ש-⁠Base44 מספקת, ואוסר לעקוף אמצעים שמגבילים גישה. כדאי לקרוא את הסעיפים האלה לפני שסומכים על כלי שעושה אחד מהשניים.

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

מה הייצוא משאיר בחוץ

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

למה קוד מיוצא עדיין פונה ל-⁠Base44

צד הלקוח של אפליקציית Base44 מדבר עם צד השרת דרך ה-⁠SDK של Base44. התיקייה src/api יוצרת לקוח עם מזהה האפליקציה שלכם, וכל קריאת נתונים בדפים, כמו שליפת רשימת הזמנות או שמירת טופס, הופכת לבקשת HTTP ל-⁠API של Base44. פונקציות השרת משתמשות באותו SDK מצד השרת. התיעוד למפתחים של Base44 אומר במפורש שקריאות לאינטגרציות תמיד רצות על התשתית של Base44, כך שהמפתחות הסודיים אף פעם לא נמצאים בצד הלקוח.

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

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

1. להישאר ב-⁠Base44 ולייצא באופן קבוע. מפעילים סנכרון ל-⁠GitHub (או מורידים ZIP אחרי שינויים גדולים) ומייצאים את הטבלאות החשובות ל-⁠CSV לפי לוח זמנים קבוע. יש לכם עותקים, לא אפליקציה עצמאית, אבל אתם מוגנים מפני אובדן עבודה.
2. לבנות מחדש על תשתית אחרת. Supabase היא הבחירה הנפוצה; המדריך שלנו להעברת אפליקציית Base44 ל-⁠Supabase מפרט מה זה כולל. צפויה כתיבה מחדש של שכבת הנתונים, כללי האבטחה והפונקציות, וגם בקשה מכל משתמש לאפס את הסיסמה שלו.
3. להעביר את כל האפליקציה לצד שרת תואם Base44 שבבעלותכם. זה מה ש-⁠Unbase44 עושה. הקוד נכנס למאגר פרטי ב-⁠GitHub, הרשומות למסד נתונים שלכם, הקבצים לאחסון קבצים משלכם, וצד שרת מתועד שמדבר ב-⁠API של Base44 רץ על האחסון שלכם. המשתמשים שומרים על הסיסמאות שלהם, והאפליקציה לא נכתבת מחדש: צד הלקוח מקבל רק כמה תיקונים קטנים, שמפורטים בקובץ docs/MIGRATION.md במאגר.

רשימת בדיקה לפני שמייצאים משהו

• בודקים את המסלול: אפשרויות ה-⁠ZIP וה-⁠GitHub דורשות Builder ומעלה.
• מייצאים כל טבלה ל-⁠CSV ושומרים את הקבצים במקום בטוח, לא משנה מה עוד תחליטו.
• רושמים את השמות של המפתחות הסודיים (את הערכים אי אפשר לייצא).
• רושמים את הקונקטורים, את האוטומציות או תהליכי העבודה, וכל מה שהאפליקציה שולחת באימייל.
• רושמים את רשומות ה-⁠DNS של הדומיין המותאם אישית, כדי שתוכלו להפנות אותו למקום אחר בהמשך.
• אם יש לכם משתמשים משלמים, רושמים איך התשלומים מגיעים לאפליקציה (webhooks של Stripe, למשל), כי הכתובות האלה משתנות אם האפליקציה עוברת.