App2Store ← מדריכים ← פרויקט Lovable שנחסם

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

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

מאת אייזיק אפרים, מייסד App2Store

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

מה בעצם קורה כשפרויקט ב Lovable נעצר

לפי התיעוד של Lovable, ה backend המובנה, Lovable Cloud, נעצר בשני מצבים: כשנגמרים הקרדיטים, וכש Lovable משהה את הפרויקט בגלל שימוש חריג. בזמן ההשהיה הדף עדיין נטען, אבל ההתחברות והנתונים לא עובדים. מסלול נפרד הוא חסימה של צוות Trust & Safety על הפרת כללי הפלטפורמה, ואז גם האתר יורד.

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

While paused, your backend is unavailable, and your published app can't read or write data until you resume.

המקרה שהכי מסוכן לעסק הוא השהיה בגלל שימוש חריג, וזה הנוסח של Lovable עליו:

Lovable paused the project for excessive Cloud usage. This happens when a project's Cloud usage reaches an extreme level, far beyond what its plan covers. Adding credits does not resume it, and Wake up is not available. Contact support with the project URL to have the project reviewed.

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

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

Depending on the case, Lovable blocks the project or removes it, and the published site is taken down.

למה אי אפשר לייצא את הנתונים בזמן שהפרויקט עצור

כי הייצוא של Lovable Cloud עובד רק כשה backend רץ. בפרויקט שהושהה בגלל שימוש חריג אין Wake up, ולכן אין גם ייצוא עד ש Lovable משחררת אותו. מי שייצא לפני כן, יש לו עותק. מי שלא, מחכה.

"You can only export while your backend is running."

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

מה הייצוא כולל, בנוסח של Lovable:

The export contains your full database, both structure and data. It does not include files in storage, Edge Function code, or your project's secrets, so plan to move those separately.

ולגבי המשתמשים:

The export includes your users' accounts and their password hashes, the scrambled form in which passwords are stored. If you restore the export into a Supabase project, your users keep their passwords.

המגבלות: מסד נתונים של עד 15GB, קובץ ייצוא של עד 5GB, וייצוא אחד ב 24 שעות. Lovable שולחת קישור להורדה במייל ושומרת עותק גם באחסון של הפרויקט. את הקובץ מורידים ושומרים מחוץ ל Lovable, בדרייב או בכל מקום שלכם, כי האחסון של הפרויקט נעצר יחד עם כל ה backend. ואת הקבצים שהמשתמשים העלו, תמונות ומסמכים, מורידים בנפרד מ More, Cloud, Storage, כי הם לא חלק מהייצוא.

הפרויקט כבר עצור. מה עושים עכשיו

פונים לתמיכה של Lovable עם הקישור לפרויקט ומבקשים בן אדם, כי התשובה הראשונה מגיעה מבוט. אם הגיע מייל מ Trust & Safety, מערערים בטופס המתאים ב lovable.dev/abuse. ובמקביל מאתרים ומתקנים את הקוד שיצר את העומס, כדי שתהיה לכם תשובה כשמישהו יבדוק.

כך עובדת התמיכה של Lovable, לפי התיעוד שלה:

Lovable's support AI replies within a couple of minutes and resolves most questions.

If the answer does not help, ask for a human. A member of the support team then follows up by email.

על הזמנים Lovable כותבת שהצוות עונה תוך 24 שעות, בעיקר בימי חול, ומדגישה שזה הזמן לתשובה ראשונה, לא לפתרון. טופס התמיכה ב lovable.dev/support פתוח רק לחשבון בתוכנית בתשלום, ובתוכנית Business הפניות מקבלות עדיפות. אם הטופס לא זמין, כותבים ל support@lovable.dev מהמייל של החשבון.

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

אם הגיע מייל מ Trust & Safety על חסימה או הסרה, זה לא עניין לתמיכה. הערעור נעשה ב lovable.dev/abuse, מחוברים לחשבון שבבעלותו הפרויקט, בטופס שמתאים להודעה שקיבלתם. ו Lovable כותבת בהגינות: "Submitting an appeal does not guarantee reinstatement."

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

ארבעה דברים להגדיר היום, לפני שזה קורה

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

אחת, הקוד. Lovable מפרידה בין השניים:

Your code is separate from your data. On paid plans, you can take a copy of the code with Download codebase in the code editor. On any plan, you can keep a repository in sync with Git sync.

סנכרון ל GitHub שווה יותר מהורדה חד פעמית, כי הוא מתעדכן לבד, והריפו נשאר שלכם גם אם הקשר מתנתק: "Your repository stays on GitHub. It remains intact with all history and files."

שתיים, הנתונים. ייצוא מ More, Cloud, Overview, Advanced settings, פעם בשבוע לפחות, ובמערכת עם לקוחות פעילים כל יום. הקובץ יורד מהמייל ונשמר אצלכם. עשר דקות בשבוע, במקום רגע שבו כל הנתונים של העסק תלויים בתשובה של מישהו אחר.

שלוש, התראות. בהגדרות הסביבה, Workspace settings, יש Usage limits & alerts. שם מגדירים התראה על צריכה ומגבלת קרדיטים. מגבלה שנחצתה עוצרת את ה backend, אבל את זה פותרים לבד: מעלים את המגבלה ולוחצים Wake up. השהיה בגלל שימוש חריג לא נפתרת לבד, ולכן כדאי לראות את הזינוק לפני ש Lovable רואה אותו.

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

ומעל ארבעתם: איפה הנתונים יושבים. על זה הסעיף הבא.

Lovable Cloud או Supabase משלכם: מה ההבדל ביום שמשהו נתקע

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

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

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

We automatically back up all Pro, Team, and Enterprise Plan projects on a daily basis.

בתוכנית Pro משחזרים מ 7 הימים האחרונים, ב Team מ 14, וב Enterprise עד 30. בתוכנית החינמית אין גיבוי אוטומטי, ו Supabase ממליצה לגבות בעצמכם:

We recommend that free tier plan projects regularly export their data using the Supabase CLI db dump command and maintain off-site backups.

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

If you want your own copy, plan to collaborate with developers, or move your project elsewhere, you can export and sync your project to GitHub: back up your code, review changes in pull requests, work locally in your IDE, test features on branches, and deploy outside Lovable.

המעבר עצמו, בנוסח של Lovable:

There is no one-click migration from the built-in backend (Cloud) to your own Supabase project. If you want to move, you export your Cloud data, connect a Supabase project to a new Lovable project, and rebuild the schema there.

ומה לא עובר עם מסד הנתונים:

Moving the PostgreSQL database alone does not move authentication, storage, realtime, or Edge Functions.

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

ואם האפליקציה שלכם גם בחנויות

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

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

ולפני הגשה, עוד סיבה לסדר את זה: אפל דורשת שהשרת יעבוד בזמן הביקורת, ובלשון ההנחיה שלה, "turn on your back-end service!" backend מושהה בזמן ביקורת הוא סיבה לדחייה. מי שעולה לחנות עם מערכת עסקית, כדאי שיסדר גיבוי ובעלות על הנתונים לפני ההגשה, לא אחריה. איך אפליקציית Lovable מגיעה לאפ סטור, שלב אחרי שלב, במדריך Lovable לאפ סטור.

שאלות נפוצות

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