איך מוציאים מערכת מ-Lovable, שכבה אחרי שכבה

לפני שמתחילים: שלוש בדיקות קצרות

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

1. איפה יושבים הנתונים שלכם?

   ברוב הפרויקטים החדשים הנתונים, המשתמשים והקבצים יושבים בצד השרת המובנה של Lovable, שנקרא Lovable Cloud^[1]. אם בתפריט "More" של הפרויקט יש "Cloud" ובו טבלאות, זה המצב אצלכם. יש פרויקטים שחוברו בזמנו לשירות מסד נתונים חיצוני, בחשבון שמישהו פתח. אז הנתונים כבר נמצאים בחשבון ההוא, והשאלה הראשונה היא מי מחזיק בו ואיך נכנסים אליו.

2. על איזה בסיס נבנתה האפליקציה?

   אפליקציות שנוצרו מ-13 במאי 2026 בנויות על TanStack Start ומריצות קוד גם בצד השרת. אפליקציות ותיקות יותר בנויות על React עם Vite, והן קבצים סטטיים בלבד. הראשונות צריכות בבית החדש שרת שמריץ קוד. לשניות מספיק אירוח של קבצים. כדי לדעת, אפשר לשאול את Lovable בצ׳אט של הפרויקט, או לחפש את @tanstack/react-start בקובץ package.json^[2].

3. האם צד השרת פעיל?

   ייצוא מסד הנתונים עובד רק כשצד השרת רץ. אם הוא מושהה, גם כשההשהיה קרתה כי נגמרו הקרדיטים או כי הגעתם לתקרת הוצאה, צריך קודם להעיר אותו^[4]. כשהקרדיטים נגמרים, השירותים של צד השרת נעצרים זמן קצר אחר כך. הנתונים נשמרים, אבל אי אפשר לגשת אליהם או לייצא אותם עד שהשירותים חוזרים לפעול. הוספת קרדיטים לא תמיד מעירה אותם לבד, ואז לוחצים "Wake up" במסך הסקירה של Cloud^[11].

רשימת מלאי: מה יש במערכת שלכם

לפני שמוציאים משהו, כדאי לרשום מה יש. כל הפריטים כאן גלויים בממשק של Lovable, תחת "More" ואז "Cloud"^[10], ולא צריך לדעת לתכנת כדי לאסוף אותם. הרשימה הזו היא גם הבסיס לבדיקה בסוף: מה שלא נרשם עכשיו, אי אפשר לוודא אחר כך שהגיע.

מה יוצא מ-Lovable, ואיך: התמונה המלאה

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

הקוד והמסכים: חיבור ל-GitHub

זה החלק הקל, והוא זמין בכל התוכניות, כולל החינמית^[1]. כשמחברים פרויקט, Lovable פותחת מאגר קוד חדש בחשבון שלכם ושומרת אותו מסונכרן לשני הכיוונים: כל שינוי ב-Lovable נשמר במאגר, וכל שינוי שנשמר במאגר חוזר ל-Lovable^[3].

1. פותחים את הגדרות הפרויקט, בלשונית Git

   משם מחברים את החשבון ב-GitHub, ב-GitLab או ב-Bitbucket. החיבור שייך לסביבת העבודה, וכל פרויקט בה יכול להשתמש בו^[3].

2. מקשרים את הפרויקט למאגר

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

3. בודקים שהסנכרון שלם

   בלשונית Git יש כרטיס סטטוס. "In sync" אומר ש-Lovable והמאגר נמצאים על אותה גרסה^[3].

מה מקבלים: את כל קוד המקור, את קובצי ההגדרות, ואת קובצי ה"מיגרציות" שמתעדים איך נבנה מבנה מסד הנתונים. מה לא מקבלים: את הרשומות עצמן ואת הקבצים שהועלו^[2]. כלומר, מאגר קוד מלא הוא גיבוי טוב של המערכת, אבל לא של המידע העסקי שבה.

מסד הנתונים: הייצוא הרשמי ומגבלותיו

Lovable מציעה שתי דרכים. הראשונה מהירה וקריאה: בכל טבלה במסך Database יש כפתור "Export CSV", שמוריד את הרשומות שלה לקובץ שנפתח באקסל^[5]. זה מצוין כדי לשמור עותק שאתם יכולים לקרוא, אבל לא מתאים להעברה: טבלה אחת בכל פעם, בלי המשתמשים ובלי הקשרים בין הטבלאות. השנייה היא ייצוא מלא של כל מסד הנתונים, וזו הדרך להעביר אותו.

1. נכנסים להגדרות המתקדמות של Cloud

   בתפריט: More, אחר כך Cloud, אחר כך Overview, ושם "Advanced settings"^[4].

2. מבקשים ייצוא

   באזור "Export project data" לוחצים "Export data". בכרטיס "Database" לוחצים "Export", ומאשרים ב-"Start export"^[4].

3. מורידים את הקובץ כשהוא מוכן

   Lovable שולחת מייל עם קישור להורדה, ושומרת עותק גם באחסון של הפרויקט, במסך Storage^[4]. הורידו אותו למקום שבשליטת העסק.

מה יש בקובץ: מבנה מסד הנתונים והתוכן שלו, כולל חשבונות המשתמשים^[4]. הקובץ הוא ארכיון דחוס בפורמט של PostgreSQL, לא קובץ שנפתח בתוכנה רגילה. משחזרים אותו בכלי ייעודי, בגרסה שתומכת בדחיסה שבה הוא נשמר^[2]. זה השלב הראשון שבו בדרך כלל צריך מישהו טכני.

ומה עם הגיבויים של Lovable?

Lovable מגבה את מסד הנתונים פעם ביום ושומרת בערך 14 ימים של גיבויים. אפשר לשחזר לאחד מהם, אבל לא לרגע שבין שני גיבויים, והגיבויים לא כוללים את הקבצים^[5]. הגיבויים האלה שומרים עליכם מטעות בתוך Lovable. הם לא עותק שנמצא אצלכם. עותק כזה הוא רק קובץ ייצוא שהורדתם.

לאן צד השרת יכול לעבור, ומה לא בא עם מסד הנתונים

קובץ הייצוא הוא מסד הנתונים. אבל Lovable Cloud עושה יותר מלשמור רשומות: הוא גם מחבר את המשתמשים, שומר את הקבצים, דוחף עדכונים למסך בזמן אמת ומריץ את פונקציות השרת. לכן לפני שמחליטים איפה לשחזר את הקובץ, כדאי לדעת מה Lovable עצמה תומכת בו. לפי התיעוד שלה, לצד השרת המובנה יש שני יעדים נתמכים, ושניהם אותה תוכנת קוד פתוח שעליה Lovable Cloud בנוי: כשירות מנוהל בחשבון של העסק, או מותקנת על שרתים שאתם מפעילים. מי שמעביר רק את מסד הנתונים לא מקבל איתו את ההתחברות, את הקבצים, את העדכונים בזמן אמת ואת פונקציות השרת. במעבר למסד נתונים רגיל או לספק אחר בונים תחליף לכל אחד מהם ומשנים את הקוד שמחבר אליהם את האפליקציה, ו-Lovable לא תומכת במסלול הזה^[1].

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

המשתמשים: מה עובר, ומה מגדירים מחדש

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

שלושה דברים לא עוברים, וכדאי לתכנן אותם מראש:

• מי שמחובר ברגע המעבר יצטרך להתחבר שוב, כי הבית החדש חותם על החיבורים במפתחות משלו^[2].
• ההתחברות עם Google, Apple או Microsoft מנוהלת ב-Lovable בלי שתצטרכו חשבון מפתחים משלכם^[6]. מחוץ ל-Lovable מגדירים כל אחת מחדש, עם הרשאות משלכם ועם הכתובת החדשה ברשימת הכתובות המורשות^[2].
• אם היעד לא יכול לקלוט את החשבונות המיוצאים, הדרך החלופית היא לשלוח למשתמשים קישור לאיפוס סיסמה^[2]. עדיף לדעת את זה לפני, ולהכין הודעה.

איך בודקים: מתחברים עם משתמש ניסיון מכל סוג (לקוח, מנהל, עובד), ובודקים שכל אחד רואה רק את מה ששלו. את כללי הגישה שהמערכת עובדת לפיהם אפשר לראות ב-Lovable תחת Database, בלשונית "RLS policies"^[5]. הם עוברים עם מבנה מסד הנתונים^[2], אבל הבדיקה האמיתית היא מה שמשתמש אמיתי רואה.

הקבצים: הורדה ידנית

תמונות, מסמכים וכל מה שהמשתמשים העלו שמורים באחסון נפרד, מחולקים לתיקיות שנקראות buckets. הם לא נכללים לא בגיבויים ולא בייצוא של מסד הנתונים^[7].

1. פותחים את Storage

   בתפריט: More, אחר כך Cloud, אחר כך Storage. כל תיקייה מסומנת "Private" או "Public"^[7].

2. מורידים את התוכן של כל תיקייה

   מסמנים קבצים ותיקיות ולוחצים "Download". כמה קבצים יחד יורדים כקובץ ZIP אחד^[7].

3. סופרים

   רושמים כמה קבצים ירדו מכל תיקייה, ומשווים לרשימת המלאי.

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

מפתחות, AI, משימות ודומיין

מפתחות לשירותים חיצוניים

סליקה, שליחת מיילים או כל שירות חיצוני אחר מחוברים בעזרת מפתחות ששמורים ב-Secrets. אחרי ששמרתם מפתח, Lovable לא מציגה את הערך שלו שוב. אפשר רק להחליף אותו או למחוק אותו. מפתח שאבד מפיקים מחדש אצל השירות שהנפיק אותו^[8]. הצעד המעשי: העתיקו את רשימת השמות מ-Secrets, ולכל שם רשמו מי מחזיק בחשבון של השירות ההוא.

AI ומחברים

יכולות AI בתוך האפליקציה רצות דרך Lovable ומחויבות בקרדיטים של סביבת העבודה. גם המחברים לשירותים חיצוניים רצים דרכה, והחיבורים עצמם לא יוצאים בייצוא. אחרי המעבר מחליפים כל אחד מהם בחשבון משלכם אצל הספק^[2]. עד שמחליפים, הקריאות האלה ממשיכות לעבור דרך Lovable ולצרוך קרדיטים, גם כשהאפליקציה כבר רצה במקום אחר.

משימות מתוזמנות

משימה שרצה כל לילה, למשל תזכורת או דוח, צריך להקים מחדש בבית החדש. אחרי ההקמה בודקים שהיא רצה בזמן שנקבע לה. מפעילים אותה רק כשהעותק הישן כבר כבוי, כדי שהיא לא תרוץ פעמיים^[2].

הדומיין

יש שני מצבים. אם הדומיין רשום אצל רשם אחר, הוא מחובר ל-Lovable בשתי רשומות DNS: רשומת A שמפנה לשרת של Lovable, ורשומת TXT לאימות^[12]. בסוף המעבר משנים את הרשומות אצל הרשם כך שיפנו לבית החדש. אם קניתם את הדומיין דרך Lovable, הוא שייך לסביבת העבודה, ו-Lovable רשמה אותו ומנהלת אותו בשבילכם. כדי להוציא אותו מבטלים את נעילת ההעברה ומקבלים קוד העברה בהגדרות הדומיינים של סביבת העבודה. ההעברה הזו בלתי הפיכה מהצד של Lovable, והאתר מפסיק לעבוד מ-Lovable על הדומיין הזה ברגע שהיא מסתיימת^[12].

הכתובת שמסתיימת ב-lovable.app נשארת ב-Lovable וממשיכה להציג את הגרסה האחרונה שפורסמה שם, עד שמבטלים את הפרסום^[2].

סדר הפעולות שלא עוצר את העסק

Lovable ממליצה על סדר ברור למעבר מלא, והוא שומר על המערכת הישנה פעילה עד הרגע האחרון^[2]:

1. משחזרים את מסד הנתונים והקבצים בבית החדש, ומריצים עליו עותק ניסיון. הלקוחות עדיין עובדים במערכת הישנה.
2. מחפשים בקוד קריאות שעדיין עוברות דרך Lovable: צד השרת המובנה, יכולות AI ומחברים.
3. מתכננים את ההעתקה האחרונה. רשומות שנוצרו אחרי הייצוא לא נמצאות בו, ולכן עוצרים לזמן קצר כתיבה חדשה: משתמשים, משימות מתוזמנות ושירותים ששולחים עדכונים. מייצאים שוב (זכרו: ייצוא אחד ב-24 שעות), מעתיקים קבצים שהשתנו, ומשחזרים. כמה זמן לוקחים הייצוא והשחזור מודדים מראש, בהרצת הניסיון.
4. מעבירים את הדומיין לבית החדש, ומבטלים את הפרסום ב-Lovable כשכבר לא צריך את כתובת lovable.app.
5. רק בסוף, אחרי שהורדתם ובדקתם את קובץ הייצוא ואת הקבצים: מסירים את Lovable Cloud ומנתקים את הסנכרון עם המאגר.

איך בודקים ששום דבר לא הלך לאיבוד

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

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

הראשון: תנאי השימוש של Lovable (בגרסה מ-28 באוגוסט 2026) מבקשים לא להעלות לשירות הרגיל מידע רגיש, ומונים בין היתר מספרי חשבון בנק, פרטי כרטיסי אשראי, מזהים ממשלתיים ומידע ביומטרי. התנאים גם קובעים שהשירות הרגיל לא נועד לשמש מערכת רשומות למידע כזה^[13]. מספר תעודת זהות הוא מזהה ממשלתי. אם המערכת שלכם שומרת מספרי זהות או פרטי תשלום, זו סיבה טובה לבדוק איפה המידע הזה צריך לשבת.

השני: את האזור שבו יושבים הנתונים בוחרים פעם אחת, כשמפעילים את Cloud. האפשרויות הן אמריקה, אירופה ואסיה-פסיפיק, ואי אפשר לשנות אזור אחר כך או להעביר פרויקט קיים לאזור אחר^[10]. באיזה אזור יושב הפרויקט שלכם רואים בהגדרות המתקדמות של Cloud, בשורה "Database location"^[4]. אם חשוב לכם שהנתונים ישבו במקום מסוים, למשל בישראל, הדרך לשם עוברת בהעברה.

מה אפשר לעשות לבד, ומתי כבר צריך עזרה

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

גם להישאר זו החלטה טובה, לא פחות. Lovable עצמה ממליצה להעביר חלקים מהמערכת רק כשנתקלים במגבלה אמיתית, למשל דרישה לגבי המקום שבו הנתונים יושבים^[1]. אם המערכת עובדת, העלות סבירה ואין דרישה כזו, גיבוי מסודר כל כמה זמן עשוי להספיק.

המעבר עצמו כבר עבודה של אנשי מקצוע. Lovable מפרטת מה עובר לאחריותכם כשמפסיקים להשתמש בה: התשתית, הגיבויים, ההרשאות, ההתחברות, המפתחות, חשבונות ה-AI, הניטור והאבטחה^[1]. סימנים שזה כבר לא פרויקט לסוף שבוע:

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

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

איך הכנו את המדריך

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

נבדק מול התיעוד הרשמי ב-11 באוקטובר 2026.

מקורות

1. Deployment, hosting, and ownership options with Lovable Lovable · נבדק ב-11 באוקטובר 2026
2. Deploying and hosting outside Lovable Lovable · נבדק ב-11 באוקטובר 2026
3. Sync your Lovable project code with GitHub, GitLab, or Bitbucket Lovable · נבדק ב-11 באוקטובר 2026
4. Advanced settings Lovable · נבדק ב-11 באוקטובר 2026
5. Database Lovable · נבדק ב-11 באוקטובר 2026
6. Users and authentication Lovable · נבדק ב-11 באוקטובר 2026
7. Storage Lovable · נבדק ב-11 באוקטובר 2026
8. Secrets Lovable · נבדק ב-11 באוקטובר 2026
9. Revert and restore your project with version history Lovable · נבדק ב-11 באוקטובר 2026
10. Lovable Cloud Lovable · נבדק ב-11 באוקטובר 2026
11. Credits and usage Lovable · נבדק ב-11 באוקטובר 2026
12. Set up a custom domain Lovable · נבדק ב-11 באוקטובר 2026
13. Terms of Service (version of August 28, 2026) Lovable · נבדק ב-11 באוקטובר 2026
14. Our response to the April 2026 incident Lovable · נבדק ב-11 באוקטובר 2026