איך להעביר אפליקציה מ-⁠Base44, שלב אחר שלב, בלי זמן השבתה

בקצרה

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

1. ממפים את כל מה שהאפליקציה משתמשת בו: טבלאות, משתמשים, פונקציות, אוטומציות, קבצים, מפתחות סודיים (secrets), אינטגרציות, הדומיין, וכל שירות חיצוני שפונה אליה.
2. מעבירים עותק שרץ במצב בדיקה, לחשבונות שבבעלותכם, בזמן ש-⁠Base44 ממשיכה לשרת את המשתמשים.
3. בודקים את העותק: התחברויות, הרשאות גישה, רשומות, קבצים, פונקציות, וכל מה ששולח הודעות.
4. מחברים את הדומיין לאפליקציה החדשה. זה הרגע שבו המשתמשים עוברים.
5. נותנים למשתמשים להתחבר פעם אחת. כשעושים את זה נכון, הסיסמאות שלהם עוברות איתם.
6. מעבירים את ה-⁠webhooks של Stripe, ‏PayPal, ‏Twilio ושירותים אחרים לכתובת החדשה.
7. מבטלים את Base44, ומשאירים את האפליקציה הישנה מפורסמת עד שהמשתמשים הפעילים התחברו לחדשה.

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

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

מה העברה צריכה לכסות

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

• ה-⁠API שצד הלקוח (frontend) פונה אליו בכל רשומה, התחברות ופונקציה
• חשבונות המשתמשים והסיסמאות שלהם
• הרשאות הגישה של כל טבלה
• סביבת הריצה של פונקציות השרת, והמתזמן שמפעיל את האוטומציות ואת תהליכי העבודה (workflows)
• אחסון הקבצים, כולל קבצים פרטיים
• האינטגרציות המובנות לאימייל, ל-⁠AI ולהעלאת קבצים, וקונקטורים כמו Gmail או Slack
• סוכני AI והשיחות שלהם
• הערכים של המפתחות הסודיים (מפתחות ה-⁠API שהפונקציות שלכם משתמשות בהם)
• הדומיין המותאם אישית והתעודה שלו

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

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

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

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

שלב 1: ממפים את מה שהאפליקציה משתמשת בו

רושמים את כל מה שהאפליקציה תלויה בו. הרשימה הזו תהפוך לתוכנית הבדיקות שלכם בשלב 3 ולתוכנית המעבר בשלבים 4 עד 6.

• טבלאות ורשומות. באזור "Data" (הנתונים) בלוח הבקרה, רושמים כל טבלה ובערך כמה רשומות יש בה.
• משתמשים. כמה יש, אילו תפקידים, ואיך אנשים מתחברים: אימייל וסיסמה, Google או ספק אחר.
• פונקציות שרת. לאילו מהן הדפים שלכם קוראים, ולאילו קוראים שירותים חיצוניים (webhooks של תשלומים, למשל).
• אוטומציות ותהליכי עבודה. מה רץ לפי תזמון, מה רץ כשנתונים משתנים, ומה שולח אימייל, הודעות SMS או התראות.
• אינטגרציות וקונקטורים. קריאות ל-⁠AI, שליחת אימייל, העלאת קבצים, ושירותים מחוברים כמו Gmail, ‏Slack או Google Sheets.
• סוכנים. כל סוכן AI, ומה הוא יכול לעשות.
• מפתחות סודיים. השמות של המפתחות שהפונקציות שלכם משתמשות בהם. Base44 מסתירה את הערכים שלהם כשהיא מציגה את הרשימה.
• קבצים. קבצים שהועלו, והאם חלק מהם פרטיים.
• הדומיין שלכם. איפה הוא רשום ומי מנהל את ה-⁠DNS שלו: רשם דומיינים כמו GoDaddy, ‏Namecheap או Cloudflare, או דומיין שקניתם דרך Base44.
• שירותים חיצוניים שפונים לאפליקציה. כל שירות שהכתובת של האפליקציה שמורה אצלו: Stripe, ‏PayPal, ‏Twilio, ‏Telegram, ‏Zapier וכן הלאה.

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

עם Unbase44, השלב הזה הוא הניתוח החינמי. מתחברים עם חשבון ה-⁠Base44 שלכם דרך ההתחברות בקוד אישור (device sign-in) של Base44 עצמה, כך ש-⁠Unbase44 אף פעם לא רואה את הסיסמה שלכם ל-⁠Base44. הוא מציג את האפליקציות שלכם, אתם בוחרים אחת, והניתוח מראה מה יש בה (דפים, טבלאות, רשומות, משתמשים, פונקציות, אוטומציות, תהליכי עבודה, סוכנים וקבצים) ומחיר חד-פעמי, עוד לפני שמחברים חשבון כלשהו או משלמים משהו. בתקופת הבטא ההעברות חינמיות; המחיר הרגיל מתחיל ב-⁠$99, חד-פעמי, לכל אפליקציה, וספקי האחסון והשירותים האחרים מחייבים אתכם ישירות. אפשר להריץ את הניתוח כאן.

שלב 2: מעבירים עותק שרץ במצב בדיקה

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

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

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

עם Unbase44, העותק עובר לחשבונות שבבעלותכם:

• קוד: מאגר פרטי בחשבון ה-⁠GitHub שלכם, עם צד הלקוח של האפליקציה ב-⁠React (הקוד שלה עצמה, עם כמה תיקונים קטנים שמפורטים בקובץ docs/MIGRATION.md במאגר), השרת, קובצי Docker, ותיעוד לאנשים ולסוכני קוד (README, ‏AGENTS.md, ‏CLAUDE.md, ומדריכים לארכיטקטורה, לפריסה ולפיתוח מקומי).
• אחסון: חשבון Railway משלכם, עם האפליקציה, מסד נתונים MongoDB ואחסון קבצים (storage bucket) במקום אחד, או כל שרת Linux שאפשר להתחבר אליו ב-⁠SSH, שמריץ את האפליקציה עם Docker ועם HTTPS שמוגדר אוטומטית. מסלול Hobby של Railway עולה $5 לחודש, כולל שימוש בשווי $5 (לפי המחירון של Railway, נכון לאוקטובר 2026), ו-⁠Railway מחייבת אתכם ישירות. Hetzner, ‏MongoDB Atlas ו-⁠AWS יגיעו בקרוב.
• אימייל ו-⁠AI: קודי התחברות והמיילים של האפליקציה עצמה נשלחים דרך חשבון Resend משלכם או דרך כל שרת SMTP; יכולות ה-⁠AI משתמשות במפתח שלכם מ-⁠OpenRouter, ‏OpenAI, ‏Anthropic או Gemini.
• מפתחות סודיים: הערכים שלהם נקראים על ידי פונקציית עזר קטנה וזמנית ש-⁠Unbase44 מוסיף לאפליקציית ה-⁠Base44 שלכם ומסיר מיד. מודיעים לכם לפני שזה קורה, ואפשר לבטל את הסימון ולהקליד את הערכים בעצמכם.
• התחברות עם Google: עוברת באמצעות לקוח התחברות של Google (Google sign-in client) משלכם. העמוד של האפליקציה ב-⁠Unbase44 מדריך אתכם ביצירת לקוח כזה בכמה דקות.

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

שלב 3: בודקים את העותק

עוברים על העותק כמו שהמשתמשים שלכם היו עוברים עליו, לפי הרשימה משלב 1. מתקנים כל מה שנראה לא תקין לפני שממשיכים.

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

שלב 4: מחברים את הדומיין

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

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

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

אחר כך משנים את רשומות ה-⁠DNS. איפה עושים את זה תלוי במקום שבו הדומיין מנוהל:

• רשום במקום אחר (GoDaddy, ‏Namecheap, ‏Cloudflare ואחרים): משנים את הרשומות אצל ספק ה-⁠DNS שלכם. התיעוד של Base44 מציין שדומיין שמחברים נשאר רשום אצל הספק שלכם, כך שרק הרשומות צריכות להשתנות.
• נקנה דרך Base44: לפי התיעוד של Base44, כמעט כל דומיין שנקנה ב-⁠Base44 מגיע היום מ-⁠Wix ומנוהל מלוח הדומיינים של האפליקציה, שבו אפשר לערוך רשומות A ו-⁠CNAME. אפשר גם להעביר אותו לספק אחר, אבל רק 60 יום אחרי שנרשם (או אחרי שינוי בפרטי הקשר שלו), והעברה יכולה לקחת עד 7 ימים. אם מעבירים, מוסיפים את הרשומות של האפליקציה אצל הספק החדש, אחרת הדומיין יפסיק לעבוד.

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

שלב 5: נותנים למשתמשים להתחבר פעם אחת

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

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

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

שלב 6: מעבירים webhooks ושירותים אחרים שפונים לאפליקציה

שירותים חיצוניים מגיעים לאפליקציה דרך כתובות ששמורות אצלם. לפי התיעוד של Base44, כל פונקציית שרת מקבלת כתובת HTTP על הדומיין של האפליקציה, שמשמשת לדברים כמו קריאות חוזרות (callbacks) מ-⁠Stripe או מ-⁠GitHub. עוברים על הרשימה משלב 1:

• תשלומים והודעות. Stripe, ‏PayPal, ‏Twilio ו-⁠Telegram שומרים כל אחד כתובת webhook. שירות ששמורה אצלו כתובת ה-base44.app של האפליקציה ימשיך לפנות ל-⁠Base44 עד שתשנו אותה. המעבר המודרך של Unbase44 עוזר להעביר את ארבעתם לכתובת החדשה. החריג הוא Stripe שהוגדר דרך התשלומים המובנים של Base44: את ה-⁠webhooks האלה Base44 רושמת בעצמה, ולפי התיעוד שלה אי אפשר להפנות אותם לכתובת אחרת, ולכן צריך לתכנן את הגדרת התשלומים הזו בנפרד (סוכנים ואינטגרציות).
• כלי אוטומציה. Zaps וכלים דומים שפונים לאפליקציה, או שהאפליקציה פונה אליהם.

אחרי כל שינוי, מפעילים אירוע בדיקה (למשל התראת תשלום לבדיקה) ומוודאים שהאפליקציה החדשה קיבלה אותו.

שלב 7: מבטלים את Base44, ואז מורידים את האפליקציה הישנה

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

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

עם Unbase44, האפליקציה שהועברה לא תלויה בשום דבר של Unbase44. קוד השרת במאגר שלכם הוא ברישיון MIT, והכפתור "Revoke access" (בטלו גישה) בעמוד של האפליקציה ב-⁠Unbase44 מוחק כל מפתח ש-⁠Unbase44 החזיק. ב-⁠Railway, ‏push לענף main של המאגר פורס את האפליקציה, כך שאתם, מפתח או סוכן קוד יכולים להמשיך לעבוד עליה.

מתי לא כדאי לעבור

לעזוב זו לא תמיד ההחלטה הנכונה.

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