הדרך של אפליקציית Lovable לפרודקשן מתחילה בבעלות על הקוד.

Lovable נותנת לכם קוד אמיתי, וזו נקודת פתיחה טובה

Lovable מצוינת בהפיכת רעיון לאפליקציה עובדת בזמן קצר. לפי התיעוד שלה, אפליקציות שנוצרו מ-13 במאי 2026 בנויות על TanStack Start, שמרנדר דפים בצד השרת, ואפליקציות ותיקות יותר בנויות על React ו-Vite ורצות בדפדפן. ה-backend הוא Lovable Cloud, שלפי Lovable נשען על הבסיס הקוד-פתוח של Supabase, או פרויקט Supabase שאתם מחברים בעצמכם. בשני המקרים מסד הנתונים הוא PostgreSQL.

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

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

האבטחה מתחילה במסד הנתונים

באפליקציה מבוססת Supabase הדפדפן מדבר עם מסד הנתונים באמצעות publishable key. התיעוד של Supabase אומר במפורש שהמפתח הזה בטוח לחשיפה, ושמה שקובע לאילו נתונים כל לקוח יכול להגיע הוא RLS. אם לטבלה אין policy, או שה-policy רחב מדי, כל מי שמחזיק במפתח יכול לקרוא או לשנות נתונים שהממשק לא מציג. מפתחות secret או service role עוקפים את RLS לגמרי, ואסור שיגיעו לדפדפן או לריפו.

זה לא תרחיש תיאורטי. CVE-2025-48757, שפורסם במאי 2025, מתאר policies של RLS שלא היו מספיקים באתרים שנוצרו ב-Lovable עד 15 באפריל 2025. Lovable חולקת על ה-CVE, בטענה שכל לקוח אחראי להגנה על הנתונים של האפליקציה שלו. בלי קשר לעמדה במחלוקת, המסקנה המעשית זהה: האחריות אצלכם. היום Lovable מריצה סריקת אבטחה מהירה בזמן publish ומציעה גם סריקה מעמיקה, והתיעוד שלה עצמו אומר שהכלים האלה לא יכולים להבטיח אבטחה מלאה וממליץ על בדיקה מקצועית כשמדובר במידע רגיש.

כדאי לבדוק גם מה נמצא בהיסטוריה של הפרויקט. באפריל 2026 דיווח The Register על טענה של חוקר אבטחה שכל חשבון חינמי ב-Lovable יכול היה לקרוא קוד מקור, פרטי גישה למסדי נתונים והיסטוריית צ'אטים של משתמשים אחרים בפרויקטים שנוצרו לפני נובמבר 2025. Lovable מסרה שלא הייתה דליפת מידע ושהקוד בפרויקטים ציבוריים גלוי במכוון, בהמשך התנצלה על האופן שבו טיפלה בנושא בהתחלה, והסבירה ששינוי הרשאות מפברואר החזיר בטעות גישה לצ'אטים של פרויקטים ציבוריים, ושהשינוי בוטל. כל מפתח שהודבק פעם בפרומפט או נכנס לקוד צריך להיחשב חשוף: מחליפים אותו ומעבירים אותו ל-secrets בצד השרת.

• RLS פעיל בכל טבלה, עם policies שנבדקו גם מחשבון של משתמש שני
• בדיקות הרשאה בפונקציות בצד השרת, לא רק בממשק
• Secrets רק בצד השרת, ומוחלפים אחרי הבדיקה
• סקירה של תלויות עם חולשות ידועות

סביבות, שחרורים ושינויי נתונים

בלחיצה על Publish, Lovable מעלה snapshot של הפרויקט. זה נוח, אבל פרודקשן צריך מסלול שבו שינוי נבדק לפני שמשתמשים רואים אותו. לפי התיעוד של Lovable, ההפרדה בין Test ל-Live ב-Lovable Cloud הופסקה ב-5 באוקטובר 2026. Drafts מאפשרים לראות שינויים באפליקציה לפני פרסום, אבל לא נותנים מסד נתונים שני, והתיעוד מזהיר לא להסתמך על publish כדי להעביר נתונים. בפועל צריך backend נפרד ל-staging, למשל פרויקט Supabase נוסף, עם נתונים ומפתחות משלו.

שינויי סכמה צריכים לחיות כמיגרציות בריפו ולרוץ באותה צורה ב-staging ובפרודקשן. מוסיפים pipeline של CI/CD שמתקין, בונה ומריץ בדיקות על כל שינוי, מגנים על ה-branch הראשי ודורשים review לכל מה שנוגע בהזדהות, בתשלומים או בנתונים. את הבדיקות מתחילים מהתהליכים שהכי יכאב אם יישברו: הרשמה, הרשאות וחיוב.

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

תפעול, עלויות ותוכנית יציאה

פרודקשן צריך גם נראות. מוסיפים error tracking לצד הלקוח ולפונקציות השרת, לוגים מובנים, בדיקות זמינות והתראות שמגיעות לאדם אמיתי. ככל שהנתונים גדלים בודקים שאילתות איטיות ואינדקסים, ועוקבים אחרי עלויות: Lovable Cloud, יכולות AI ו-connectors מנוהלים צורכים קרדיטים של ה-workspace, ואירוח חיצוני מחויב בנפרד.

את תוכנית היציאה מתכננים כשהכול רגוע. סנכרון GitHub נותן לכם את הקוד והמיגרציות, אבל לא את הנתונים ולא את ה-secrets. בתיעוד של Lovable כתוב שהעברה של מסד ה-PostgreSQL לבדו לא מעבירה הזדהות, storage, realtime או Edge Functions, שאין מעבר בלחיצה אחת מ-Lovable Cloud לפרויקט Supabase שלכם, ושאת העורך של Lovable עצמו אי אפשר להריץ אצלכם. ייתכן שנכון להישאר על Lovable. העיקר הוא לדעת מה יידרש אם תחליטו לעזוב.

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

מסלול מעשי: בודקים, מאבטחים, מייצבים ואז מגדילים

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

• בודקים: מחברים GitHub, מריצים את האפליקציה מקומית, ממפים טבלאות, policies, פונקציות, secrets ואינטגרציות, ומסמנים על מה העסק נשען.
• מאבטחים: מפעילים ובודקים RLS בכל טבלה, מעבירים secrets לצד השרת, מחליפים מפתחות חשופים ומוסיפים בדיקות הרשאה בשרת.
• מייצבים: staging, מיגרציות, CI/CD, בדיקות לתהליכים הקריטיים, error tracking, גיבויים ותהליך שחרור כתוב.
• מגדילים: משפרים ביצועים ועלויות, עושים refactor לחלקים שמאטים את הצוות וממשיכים לפתח על בסיס יציב.

שאלות לשאול לפני השקה

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

• למי שייך הריפו, ומי מאשר שחרור לפרודקשן?
• האם משתמש מחובר יכול לקרוא או לשנות רשומות של משתמש אחר דרך ה-API?
• איפה נשמרים ה-secrets, והאם מישהו מהם הודבק פעם בפרומפט?
• האם אפשר לבדוק שינוי מול נתוני staging בלי לגעת בפרודקשן?
• איך מחזירים אחורה שחרור בעייתי, ומתי שחזרנו גיבוי בפעם האחרונה?
• מי מקבל התראה כשיש קפיצה בשגיאות, וכמה עולה לנו שעה של השבתה?
• מה יידרש כדי לעבור מ-Lovable Cloud אם נצטרך?

איך שותף פיתוח ייעודי ניגש לזה

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

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