Supabase: מה עובר לאחסון ומה נשאר

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

שלושה חלקים שכדאי להפריד ביניהם

1. הקוד: קבצי הפרויקט, שנמצאים בכלי הבנייה, במאגר GitHub או במחשב שלכם.
2. האתר עצמו (החזית): מה שהגולש רואה. אחרי build זו תיקיית קבצים סטטיים, בדרך כלל dist.
3. הנתונים וההתחברות (ה-backend): מסד הנתונים, המשתמשים הרשומים, קבצים שמשתמשים העלו, ולפעמים פונקציות שרצות בשרת. כל אלה יושבים אצל Supabase.

מה עובר לאחסון, ומה נשאר

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

נשאר אצל Supabase:

• מסד הנתונים והטבלאות.
• המשתמשים, הסיסמאות וההתחברות.
• קבצים שמשתמשים העלו (Storage).
• פונקציות שרצות אצל Supabase, אם יש.

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

שתי השלכות חשובות:

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

משתני סביבה שמתחילים ב-VITE_

בפרויקט יש בדרך כלל קובץ .env עם משתנים כמו VITE_SUPABASE_URL ומפתח ציבורי של Supabase. שני דברים חשובים:

1. הם נכנסים לקוד בזמן ה-build. ב-Vite, משתנים שמתחילים ב-VITE_ נכתבים לתוך הקבצים כשמריצים npm run build, ולא כשהאתר רץ. לכן צריך להגדיר אותם לפני ה-build. אם שיניתם משתנה, צריך להריץ build מחדש ולהעלות שוב.

2. כל מה שנכנס אליהם גלוי לכל גולש. כל אחד יכול לראות אותם בקוד שנטען בדפדפן. זה בסדר עבור הכתובת של הפרויקט ועבור המפתח הציבורי (anon או publishable), שנועד להיות בצד הדפדפן, בתנאי שהגדרתם הרשאות גישה לטבלאות (Row Level Security) אצל Supabase. מפתח סודי, כמו service_role, לא שמים לעולם במשתנה VITE_. מי שמחזיק אותו יכול לעקוף את כל הרשאות הגישה.

כתובות הפניה להתחברות בדומיין החדש

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

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

הפתרון, בהגדרות הפרויקט ב-Supabase, תחת Authentication ואז URL Configuration:

1. Site URL: מעדכנים לכתובת הדומיין החדש, עם https. זו הכתובת שמשמשת בקישורים שנשלחים במייל, למשל אימות הרשמה ואיפוס סיסמה.
2. Redirect URLs: מוסיפים את הדומיין החדש, וגם את גרסת ה-www אם משתמשים בה.

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

דברים נוספים לבדוק

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

צ'קליסט אחרי המעבר

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

איזו חבילה מתאימה

אתר שהחזית שלו סטטית והנתונים אצל Supabase מתאים לחבילת אתרים סטטיים: עד 3 אתרים, 2GB נפח, 30GB תעבורה בחודש, SSL חינם וגיבוי יומי מחוץ לשרת, 14 ימים אחורה, החל מ-17.90 ₪ לחודש כולל מע"מ (בלי מייל). איך מעלים את האתר, במדריך איך מעלים לאוויר אתר שבניתם עם AI. אם האפליקציה מריצה קוד בשרת משלה, ולא רק אצל Supabase, קראו קודם את אתר סטטי או אפליקציה עם שרת.