פריסה ו-Hosting — מהמחשב לאינטרנט

מה זה Deployment — מהלוקאל לאינטרנט

בפרקים הקודמים בניתם אתר. הקוד נמצא אצלכם במחשב, בתיקייה כמו my-portfolio/. כשאתם מריצים npm run dev, נפתח שרת קטן ב-localhost:3000 והאתר רץ. אבל רק אתם רואים אותו. אם תסגרו את המחשב — האתר נעלם. אם החבר שלכם בברלין ינסה להיכנס ל-localhost:3000 — הוא יראה את האתר שלו, לא שלכם.

זה הבדל מהותי — localhost זה "המחשב הזה". לא שרת בענן, לא באוויר — פשוט מחשב מקומי שלכם. כדי שהאתר יהיה נגיש לכל העולם, צריך לשים אותו על שרת שמחובר לאינטרנט 24/7, שכתובת IP שלו מקושרת לשם דומיין, ושיש לו אישור SSL לחיבור מאובטח.

פעם — לפני 15 שנה — כל זה היה סיוט. היית צריך לשכור שרת במרכז נתונים, להתקין Linux, להגדיר nginx או Apache, לקנות אישור SSL, להגדיר DNS ידנית, ולעשות הכל מחדש בכל שינוי. זה לקח ימים. היום? בפלטפורמות מודרניות זה לוקח 3 דקות. הסיבה: הפלטפורמות (Vercel, Netlify, Cloudflare) מסדרות הכל אוטומטית.

הנה מה שקורה מאחורי הקלעים כשאתם "פורסים אתר":

1. Source: הקוד שלכם ב-GitHub repo
2. Build: הפלטפורמה מורידה את הקוד ומריצה npm install + npm run build
3. Output: נוצרים קבצים סטטיים (HTML, CSS, JS) מוכנים להפצה
4. Distribution: הקבצים נשלחים ל-CDN — רשת של שרתים בכל העולם
5. DNS: הדומיין שלכם מופנה לשרתים של הפלטפורמה
6. SSL: אישור HTTPS מונפק אוטומטית (בחינם, דרך Let's Encrypt)
7. Live: האתר זמין בכתובת שלו

כל זה — באוטומטי. אתם רק מחברים GitHub, בוחרים branch, ולוחצים Deploy. את שאר 99% מהעבודה הפלטפורמה עושה במקומכם.

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

למה זה חשוב? אם האתר שלכם סטטי לחלוטין (אין צד-שרת, אין אימות, אין טפסים שנשלחים לשרת) — GitHub Pages מספיק בחינם. אם האתר משתמש ב-Next.js עם Server Components, קוראים API keys, או מגיעים אליו טפסים — Vercel או Netlify הם הבחירה הטבעית. אם התעבורה גבוהה או שאתם חוששים מחשבון ענק בסוף החודש — Cloudflare Pages נותן הכי הרבה בחינם.

Vercel — הבית של Next.js

Vercel היא החברה שפיתחה את Next.js. זה אומר שכל יכולת חדשה ב-Next.js — Server Components, App Router, Streaming, Edge Runtime — נבדקת ומאופטמת על Vercel לפני שהיא משתחררת. לפרויקט Next.js, Vercel היא לא עוד פלטפורמה — היא הבית הטבעי שלו.

מה Vercel נותנת בחינם (Hobby plan):

• 100 GB bandwidth בחודש — מספיק לאתר פורטפוליו עם 10,000-50,000 מבקרים
• 6,000 דקות build זמן — מתורגם ל-כ-200-400 פריסות בחודש
• Serverless functions — 100 GB-Hours של חישוב
• Edge functions — 500,000 invocations בחודש
• Preview deployments — כל Pull Request מקבל URL זמני משלו לבדיקה
• Analytics (בסיסי) — מספר מבקרים, דפים הכי פופולריים
• SSL אוטומטי — HTTPS לכל דומיין
• דומיין חינמי — yourproject.vercel.app

מה לא נכלל בחינם:

• שימוש מסחרי (commercial use) — דורש Pro plan
• אם חרגתם מ-100 GB bandwidth — האתר לא נופל, אבל מקבלים דרישה לעדכן
• Support של Vercel — ב-Pro יש צ'אט, בחינם יש רק פורום קהילה

מחיר Pro: 20$ לחודש למשתמש. כולל 1 TB bandwidth, builds מקבילים, analytics מלא, ו-support. לעסק ישראלי שרוצה לפרוס 3-5 פרויקטים — זה יעלה 200-300 ש"ח בחודש. שווה לזכור שזה מחיר לשימוש עסקי, לא לפורטפוליו אישי.

איך מתחילים עם Vercel — 3 צעדים:

1. נרשמים: נכנסים ל-vercel.com, לוחצים "Sign Up with GitHub". Vercel מקבלת הרשאה לקרוא את ה-repos שלכם (קריאה בלבד כברירת מחדל).
2. Import Project: בלשונית הראשית — "Add New Project". בוחרים repo מתוך הרשימה של GitHub. Vercel מזהה אוטומטית שזה Next.js ומגדירה build command ו-output directory.
3. Deploy: לוחצים "Deploy". 60-120 שניות של build, ומקבלים URL חי — משהו כמו my-portfolio-xxx.vercel.app.

היתרון שיעשה לכם שינוי: אחרי שהפרויקט מחובר, כל git push ל-main גורם לפריסה חדשה. שיניתם טקסט בכפתור? git commit + git push = תוך 90 שניות האתר מעודכן. אין תסריטי FTP, אין העלאות ידניות. זה מרגיש קסום בפעם הראשונה, וזה הופך לשגרה תוך יום.

Preview Deployments: זו הפיצ'ר שהופכת את Vercel למצטיינת. כל פעם שאתם יוצרים Pull Request ב-GitHub, Vercel בונה גרסה זמנית של האתר עם כתובת כמו my-project-git-feature-branch.vercel.app. זה מאפשר לבדוק שינוי לפני שהוא עולה לאוויר, לשלוח לינק למנהל המוצר לאישור, או להראות ללקוח מהסלולר בזמן ישיבה.

Vercel Analytics: בתשלום נוסף (בחינם יש גרסה מצומצמת). מודד Core Web Vitals (LCP, FID, CLS) — המדדים שגוגל משתמש בהם לדירוג SEO. לא נעבור לעומק כאן, אבל דעו שזה כלי שימושי כשהאתר מתחיל לצבור טרפיק.

Netlify — האלטרנטיבה הוותיקה

Netlify קדמה ל-Vercel בכמה שנים. היא הגיעה לשוק ב-2014, הרבה לפני שהפך לנורמלי לפרוס אתר בלחיצת כפתור. הרבה מהכלים שאנחנו לוקחים כמובן מאליו היום (git-based deployment, CDN אוטומטי, SSL חינם) — Netlify הייתה שם הראשונה.

מה Netlify נותנת בחינם (Free tier):

• 100 GB bandwidth בחודש — זהה ל-Vercel
• 300 דקות build זמן — פחות מ-Vercel (6,000), אבל מספיק לרוב הפרויקטים
• Netlify Forms — קולט טפסים בלי לכתוב backend. 100 submissions בחודש בחינם
• Netlify Identity — מערכת אימות משתמשים מובנית (1,000 משתמשים פעילים בחינם)
• Netlify Functions — serverless functions (125,000 calls בחודש)
• Split Testing / A-B — ניסויי A/B מובנים ללא קוד
• Deploy previews — לכל PR (כמו Vercel)
• SSL אוטומטי + דומיין חינמי yourproject.netlify.app

איפה Netlify בולטת מעל Vercel:

1. Netlify Forms — הפיצ'ר הכי שימושי למי שבונה אתרי תדמית. מוסיפים data-netlify="true" לטופס, ו-Netlify קולטת submissions אוטומטית, מציגה אותם ב-dashboard, ושולחת email התראה. בלי backend, בלי database.
2. Netlify Identity — מערכת login מלאה (email+password, Google, GitHub) שמתלבשת על האתר שלכם בלי קוד. שימושי ל-member portals או אתרים שצריכים user accounts פשוטים.
3. Split Testing — A/B testing ברמת ה-deployment. אפשר להציג branch אחד ל-50% מהמבקרים ו-branch אחר לשאר, בלי שינוי קוד.

איפה Vercel מנצחת:

• Next.js integration — Vercel מכירה כל פיצ'ר של Next.js ברגע שהוא יוצא. Netlify תמיד כמה שבועות מאחור.
• Edge functions ביצועים — Vercel ב-Edge Runtime נותן ביצועים טובים יותר ל-Next.js
• Build times — 6,000 דקות ב-Vercel לעומת 300 ב-Netlify free tier

מחיר Pro של Netlify: 19$ לחודש למשתמש. דומה ל-Vercel, עם 1 TB bandwidth, יותר form submissions ו-functions invocations.

מתי לבחור Netlify על פני Vercel:

חסרונות של Netlify שכדאי לדעת:

• Build minutes מוגבלים (300/חודש) — אם הפרויקט בונה הרבה (10 פריסות ביום × 3 דקות = 900 בחודש), חוצים את הגבול.
• Next.js 15 עם App Router ומאפיינים חדשים — לא תמיד עובד מצוין ב-Netlify. יש workarounds, אבל Vercel חלקה יותר.
• Forms — 100 בחודש בלבד בחינם — לאתר עם תנועה גבוהה תצטרכו Pro.

Cloudflare Pages — המתמודד הנדיב

Cloudflare היא אחת מחברות ה-CDN הגדולות בעולם. הם מנהלים בערך 20% מהתעבורה של כל האינטרנט. ב-2020 הם השיקו Cloudflare Pages — פלטפורמת hosting שרוכבת על ה-CDN העצום שלהם.

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

מה Cloudflare Pages נותנת בחינם:

• Unlimited bandwidth — כן, ללא הגבלה. אפילו עם מיליון מבקרים בחודש, עדיין חינם.
• 500 builds בחודש — מספיק לרוב הפרויקטים (16 ביום)
• 500 פרויקטים בחשבון אחד (Vercel נותן 200)
• Workers — 100,000 requests ביום בחינם (המקבילה ל-edge functions)
• D1 database — SQLite בענן, עם 5 GB אחסון חינם
• R2 storage — S3-compatible object storage (10 GB חינם)
• SSL + דומיין חינמי yourproject.pages.dev

איפה Cloudflare Pages בולטת:

1. Bandwidth אין-סופי — אם האתר שלכם צפוי לפרוץ (ויראלי ברשת, פרסום בפריים-טיים), Cloudflare הוא הפתרון היחיד שלא יעקוץ אתכם ב-overage fees.
2. Cloudflare Workers — edge functions עם ביצועים מהמהירים בעולם. רץ ב-300+ מיקומים גלובלי, אפילו בתל אביב (יש Point of Presence של Cloudflare בישראל).
3. Stack מלא בחינם — Pages + Workers + D1 (database) + R2 (storage) + KV (key-value) = יכולים לבנות SaaS מלא בחינם (עד 100k req/day).
4. Security מובנה — Cloudflare היא חברת security במקור. DDoS protection, bot mitigation, WAF — הכל כבר פעיל.

חסרונות:

• Next.js integration פחות חלק — תומכים בזה, אבל לפעמים דורש adapter (@cloudflare/next-on-pages). לא הכל עובד מיידית.
• פחות friendly ל-SSR מורכב — אם אתם עושים heavy server-side rendering עם Next.js 15, Vercel יותר חלקה.
• UI פחות מלוטש — ה-dashboard של Cloudflare הוא "מהנדסי". לא כזה יפה כמו של Vercel.
• D1 ו-R2 עדיין בשלבי beta יחסית — פועלים, אבל API משתנה. לא הייתי בונה עליהם SaaS מסחרי קריטי בלי גיבוי.

מחיר Pro: Cloudflare Pages לבד נשאר חינמי לשימוש עסקי. תשלומים מתחילים רק אם חוצים את המגבלות של Workers (125k invocations ביום = 5$ לחודש) או מעמיסים עוד שירותים.

GitHub Pages — הפשוט והחינמי

GitHub Pages היא השירות הוותיק ביותר ברשימה — קיים מ-2008. הוא גם הכי פשוט. אם הפרויקט שלכם כבר ב-GitHub, הפעלת Pages היא כפתור אחד.

מה GitHub Pages נותנת בחינם:

• 100 GB bandwidth בחודש
• 1 GB אחסון לכל repo
• 10 builds בשעה (מספיק לרוב)
• SSL אוטומטי
• דומיין חינמי username.github.io/repo-name או username.github.io (אם ה-repo נקרא ככה)
• Custom domain — אפשר לחבר דומיין שלכם חינם

מה אין ב-GitHub Pages:

• אין SSR — רק אתרים סטטיים
• אין serverless functions — אין backend, אין API routes, אין dynamic rendering
• אין support ל-Next.js מלא — רק next build עם output: 'export' (static export). כל מה ש-Next.js עושה בשרת לא עובד.
• אין preview deployments — רק main branch מתעדכן
• אין analytics — צריך להוסיף Google Analytics ידנית

למה בכל זאת לבחור GitHub Pages?

• פורטפוליו אישי סטטי — אם בניתם פורטפוליו עם Astro או Vite (בלי backend), GitHub Pages מושלם. פשוט. חינם. אין סיכוי לחשבון מפתיע.
• אתר תיעוד (docs) — הרבה פרויקטים open-source משתמשים ב-GitHub Pages לאתר התיעוד שלהם. זה סטנדרט.
• דף "הדגמה" של פרויקט — אם יצרתם קומפוננטה או ספרייה, אפשר להדגים אותה בעמוד GitHub Pages של אותו repo.

הגבלה הכי חשובה שצריך לדעת: GitHub Pages לא ידע להריץ npm run build לפרויקט Next.js ולפרוס את התוצאה — לפחות לא בלי GitHub Actions. לפרויקטים מתקדמים, זה אומר שצריך להגדיר GitHub Actions workflow שמבצע את ה-build. זה אפשרי, אבל זה הופך את "הפשטות" של GitHub Pages לפחות פשוטה.

פתרון מעשי לפרויקט Next.js על GitHub Pages: צריך להוסיף ל-next.config.js את output: 'export', להגדיר GitHub Action שבונה ומעלה, ולהשלים עם העובדה שאין SSR. זה עובד — אבל לרוב Vercel או Cloudflare Pages שוות את הטרחה החסכתם.

טבלת השוואה מלאה — 4 הפלטפורמות זו מול זו

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

ההמלצה המסכמת:

• Vercel — פרויקט Next.js עם SSR / App Router. האינטגרציה הכי חלקה.
• Netlify — צריכים Forms או Identity מובנים. Astro/SvelteKit/Vite.
• Cloudflare Pages — טרפיק גבוה או חוסכי מדי. פרויקט סטטי או קל.
• GitHub Pages — פורטפוליו סטטי טהור, אתר תיעוד. הכי פשוט.

CI/CD ו-Continuous Deployment — push = deploy

CI/CD הוא הקיצור המשמעותי ביותר בפרק הזה. זה קורה בכל פעם שאתם דוחפים קוד ל-GitHub, וזה מה שהופך "הרגישים בפלטפורמות חדשות" ל-"שגרה פרודוקטיבית".

פירוק הקיצור:

• CI — Continuous Integration (אינטגרציה רציפה): תהליך שמריץ אוטומטית בדיקות על הקוד כל פעם שמישהו דוחף שינוי. בדיקות אוטומטיות, linting, type checking.
• CD — Continuous Deployment (פריסה רציפה): תהליך שמעלה את הקוד לאוויר באופן אוטומטי ברגע שה-CI עבר בהצלחה.

מה קורה טכנית בכל push:

1. אתם: git push origin main
2. GitHub מקבל את השינוי
3. Webhook מודיע לפלטפורמה (Vercel/Netlify/Cloudflare) שיש שינוי
4. הפלטפורמה מורידה את הקוד העדכני
5. מריצה npm install להתקנת dependencies
6. מריצה npm run build לבניית האתר
7. אם build הצליח — מעלה את הקבצים החדשים ל-CDN
8. מעדכנת את כל 300+ שרתי ה-CDN בעולם (לוקח 10-30 שניות)
9. השינוי חי באתר

סה"כ: 60-120 שניות. ללא שום התערבות ידנית אחרי ה-push.

Preview Deployments — הפיצ'ר שעושה את זה קסום: בכל פעם שאתם פותחים Pull Request ב-GitHub (לא מיזוג — רק PR), הפלטפורמה בונה גרסה נפרדת של האתר לאותה תכונה חדשה. אותה תכונה חיה ב-URL זמני. כמה יתרונות:

• בדיקה בלי סיכון: רואים את השינוי בסביבת production אמיתית לפני שהוא עולה לאתר הראשי
• שיתוף מהיר: שולחים לינק למנהל מוצר, לקוח, או עמית — הם רואים בדיוק את השינוי
• בדיקה מהסלולר: ה-URL עובד מכל מכשיר — בודקים Mobile responsive בקלות
• היסטוריה: לכל PR יש URL משלו — אפשר להשוות גרסאות

Build Commands — מה צריך לדעת: בכל פרויקט, הפלטפורמה צריכה לדעת איך לבנות את האתר. היא מזהה אוטומטית רוב המצבים, אבל לפעמים צריך להגדיר ידנית:

שורה תחתונה: בפעם הראשונה שאתם פורסים, הפלטפורמה תנסה לזהות אוטומטית. אם זה לא עובד — שואלים את ה-AI: "מה ה-build command לפרויקט [framework] על [platform]?"

דומיין מותאם אישית — DNS ו-SSL

הפרויקט שלכם פרוס על my-project-xyz.vercel.app. זה עובד. אבל כמו עסק רציני — אתם רוצים my-name.com. זה קוסמטי וגם מקצועי. וזה דורש שני מרכיבים: קניית דומיין ו-הגדרת DNS.

איפה קונים דומיין בישראל:

ההמלצה: לרוב הפרויקטים — Cloudflare Registrar. הם מוכרים דומיינים במחיר עלות (בלי markup), מה שאומר 10$ לשנה ל-.com ללא הפתעות. אם אתם רוצים .co.il — Domain The Net או ספק ישראלי אחר.

מה זה DNS באמת: דמיינו שהאינטרנט הוא עיר ענקית. כל שרת הוא בית עם כתובת (IP address, כמו 76.76.21.93). אבל אנשים לא זוכרים מספרים — הם זוכרים שמות. DNS הוא ספר הטלפונים של האינטרנט — הוא מתרגם google.com לכתובת IP, ו-my-name.com לשרת שהפרויקט שלכם רץ עליו.

סוגי רשומות DNS שצריך להכיר:

חיבור דומיין ל-Vercel — 5 צעדים:

1. ב-Vercel dashboard: Settings → Domains → Add. מקלידים my-name.com.
2. Vercel מציגה 2 רשומות DNS להוסיף: רשומת A (לדומיין הראשי) ורשומת CNAME (ל-www).
3. נכנסים ל-dashboard של ה-registrar (Cloudflare/Namecheap/Domain The Net) בלשונית DNS.
4. מוסיפים את שתי הרשומות:
   • Type: A | Name: @ | Value: 76.76.21.93
   • Type: CNAME | Name: www | Value: cname.vercel-dns.com
5. ממתינים 5-60 דקות (propagation). Vercel תציג "Valid Configuration" כשהדומיין פעיל. SSL ינופק אוטומטית דרך Let's Encrypt.

SSL — ההצפנה שלא צריך לעבוד עליה: פעם היה צריך לקנות אישור SSL (100-500 ש"ח לשנה). היום — Let's Encrypt מנפיק SSL חינם, וכל הפלטפורמות (Vercel, Netlify, Cloudflare, GitHub Pages) עושות את זה אוטומטית ברגע שהדומיין פעיל. המנעול הירוק בדפדפן — מופיע תוך כמה דקות, ואז מתחדש אוטומטית כל 3 חודשים. אפס התערבות.

Environment Variables — סודות שלא שמים בקוד

כמעט כל פרויקט אמיתי צריך סודות: API key של OpenAI, Stripe secret key, connection string ל-database, סיסמה ל-SMTP. הבעיה — אם תשימו אותם בקוד, והקוד ב-GitHub הציבורי, כל העולם רואה. האקרים יגלו תוך דקות ויעשו שימוש לרעה.

הפתרון: Environment Variables (משתני סביבה). במקום לשים סודות בקוד, שמים אותם בהגדרות הפלטפורמה או בקובץ .env.local שלא עולה ל-Git.

איך זה עובד בקוד:

// במקום זה (רע):
const apiKey = "sk-proj-abc123-xyz789"
fetch('https://api.openai.com/v1/chat', {
  headers: { 'Authorization': `Bearer ${apiKey}` }
})

// עושים את זה (טוב):
const apiKey = process.env.OPENAI_API_KEY
fetch('https://api.openai.com/v1/chat', {
  headers: { 'Authorization': `Bearer ${apiKey}` }
})

המשתנה process.env.OPENAI_API_KEY מוגדר במקום אחד — לא בקוד. בפיתוח מקומי, הוא מגיע מקובץ .env.local. ב-production, הוא מגיע מהגדרות הפלטפורמה.

Frontend vs Backend — ההבדל הקריטי: משתני סביבה ב-Next.js מתחלקים לשני סוגים, לפי אם הם נחשפים ב-browser או לא.

קבצי .env שחייבים להכיר:

• .env.local — פיתוח מקומי. לא עולה ל-Git (כתוב ב-.gitignore). זה הקובץ שעובדים איתו ב-localhost.
• .env.production — production. לרוב לא צריך, כי הפלטפורמה עצמה מנהלת את זה בדשבורד.
• .env.example — דוגמה בלי ערכים אמיתיים. עולה ל-Git. מציג לאחרים איזה משתנים הפרויקט צריך. חשוב מאוד לשיתוף פעולה!

דוגמה ל-.env.example:

# .env.example — דוגמה. העתיקו ל-.env.local ומלאו בערכים אמיתיים.

OPENAI_API_KEY=
STRIPE_SECRET_KEY=
DATABASE_URL=

NEXT_PUBLIC_GA_ID=
NEXT_PUBLIC_SITE_URL=http://localhost:3000

הגדרה ב-Vercel dashboard:

1. Project → Settings → Environment Variables
2. לכל משתנה: מקלידים name ו-value
3. בוחרים סביבה: Production / Preview / Development (בדרך כלל כל השלוש)
4. Save. מהפריסה הבאה המשתנה זמין ב-process.env.XXX

Edge Functions ו-Serverless Functions

אחד הפיצ'רים שמבדילים פלטפורמות מודרניות מ-hosting קלאסי הוא היכולת להריץ קוד על השרת — בלי לנהל שרת. זה קורה דרך שני סוגים של פונקציות: Serverless Functions ו-Edge Functions.

Serverless Function — קוד שרץ לפי דרישה:

• רץ רק כשמישהו קורא ל-endpoint מסוים
• רץ על שרת אחד מרכזי (בדרך כלל בצפון-מזרח ארה"ב או אירלנד)
• יש לו "cold start" — אם לא היה שימוש, הפעם הראשונה לוקחת 500-2000 מילישניות
• אין הגבלת זמן קשה (עד 10-60 שניות, לפי הפלטפורמה)
• תומך ב-Node.js מלא — כל ספרייה, כל API

Edge Function — קוד שרץ קרוב למשתמש:

• רץ על CDN — קרוב גיאוגרפית למשתמש (תל אביב, לונדון, ניו יורק)
• אין cold start — מוכן מיד
• תגובה מהירה משמעותית (50-100 מילישניות vs 500-2000)
• מגבלות קפדניות: זמן ריצה קצר (30 שניות), אין גישה ל-Node.js APIs מסוימים (fs, child_process)
• מושלם ל: A/B testing, redirects, auth checks, geolocation

דוגמה ב-Next.js App Router:

// app/api/hello/route.ts

// Serverless (ברירת מחדל):
export async function GET() {
  return Response.json({ message: "Hello" })
}

// Edge (דורש שורה נוספת):
export const runtime = 'edge'
export async function GET() {
  return Response.json({ message: "Hello from edge" })
}

מתי להשתמש בכל אחד:

שלושה דגלים אדומים שכדאי לשים לב אליהם לפני שבוחרים Edge: (1) אם הקוד שלכם קורא fs.readFile, path, או child_process — לא יעבוד ב-Edge, תצטרכו Serverless. (2) אם אתם מתחברים ל-Postgres או MySQL עם driver רגיל (pg, mysql2) — אין תמיכה ב-Edge; תצטרכו HTTP-based driver כמו @neondatabase/serverless או @vercel/postgres. (3) אם הספרייה שאתם משתמשים בה (כמו sharp לעיבוד תמונה או puppeteer ל-scraping) מסתמכת על קבצים בינאריים של Node.js — Edge לא יכול להריץ אותה.

כלל אצבע פרקטי: התחילו הכל כ-Serverless (ברירת המחדל של Next.js). אחרי שהאתר חי ועובד, הסתכלו באיזה endpoints יש לטנסי תגובה גבוה או תנועה גבוהה, ורק אותם העבירו ל-Edge על ידי הוספת השורה export const runtime = 'edge'. אל תנסו לאפטם מראש — זה בזבוז זמן אם הפלטפורמה בכלל עונה מהר מספיק.

צ'קליסט פריסה — 12 צעדים מ-localhost לאתר חי

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

בפעם הראשונה זה לוקח 30-60 דקות. מהפעם השנייה — 10 דקות. התהליך הופך ל-מוזר-הטבעי אחרי פעם-פעמיים, וזו אחת מהסיבות שהפלטפורמות האלה שינו את הדרך שבה בונים אתרים.

איך לבקש מ-AI prompts פריסה מוכנים

הפלטפורמות קלות — אבל הפעם הראשונה דורשת הרבה החלטות קטנות. הדבר הכי יעיל: לבקש מ-AI (Claude, ChatGPT, V0) להנחות אתכם שלב-שלב. להלן 10 prompts שעובדים: