ה-Free Stack — מה אתה באמת מקבל ב-$0, ופריסה תוך 10 דקות

למה הפרק הזה: מ-"נראה חינמי" ל-"באמת חינמי"

אתה כבר בונה דברים. פותח את Claude Code או Cursor, מתאר מה אתה רוצה, ותוך כמה דקות יש קוד שעובד על המחשב שלך. הבעיה היחידה? הקוד הזה רץ ב-localhost. אף אחד חוץ ממך לא יכול לראות אותו. וברגע שאתה רוצה לפרוס אותו לעולם — מתחיל מבול של החלטות: איפה לארח? מה זה יעלה? מתי החשבון יקפוץ פתאום ל-$40/חודש?

Cloudflare פותרת בדיוק את החלק הזה, ועושה את זה עם ה-free tier הכי נדיב בענף — אם יודעים לקרוא אותו נכון. הבעיה: יש שלושה סוגים של "חינם" אצל Cloudflare, ורובם נראים זהים מבחוץ עד שמגיע החיוב:

• חינם-לתמיד: שירותים בלי תקרת נפח בכלל (Static Assets serving, Tunnel, Turnstile). תשתמש כמה שתרצה — לא תשלם.
• חינם-עד-מגבלה: רוב המוצרים. יש קוטה יומית או חודשית נדיבה (Workers, KV, D1, R2, Workers AI). חינם — עד שאתה נוגע בקיר.
• לא-חינם: מוצרים שאין להם free tier אחסון/delivery כלל (Stream, Cloudflare Images storage, Containers, שליחת Email). פה צריך workaround או כרטיס אשראי.

המטרה של הפרק הזה היא לתת לך מפה מנטלית מדויקת של שלוש הקטגוריות האלה, ולפרוס דבר ראשון חי כדי שהמילים "Worker", "deploy" ו-"workers.dev" יהפכו ממונחים מופשטים לדבר שאתה כבר עשית. אנחנו לא הולכים לכסות את כל המוצרים לעומק — לכל אחד מהם מוקדש פרק. אנחנו הולכים לבנות את ה-מסגרת שתשרת אותך עד סוף הקורס.

למה ההבחנה הזו בין שלושת סוגי ה"חינם" כל-כך קריטית? כי הסיפורי-אימה שאתה שומע על "חשבון ענן שקפץ ל-$500 בלילה" כמעט תמיד נובעים מבלבול בין הקטגוריות. מישהו בנה על מוצר "לא-חינם" בהנחה שהוא חינמי, או לא שם לב שעבר את הקיר של "חינם-עד-מגבלה" ונכנס ל-overage. כשאתה יודע מראש לאיזה דלי כל מוצר שייך, אתה בשליטה מלאה על העלות — בלי הפתעות. זו לא רק ידיעה טכנית, זו שקט נפשי.

ועוד הבטחה: בסוף הפרק לא רק שתבין את התיאוריה — יהיה לך אתר חי באינטרנט שאתה פרסת, ב-URL ציבורי, שעובד מהטלפון. זה לא תרגיל "צעצוע"; זו בדיוק אותה זרימה (create → dev → deploy) שתשתמש בה לכל פרויקט אמיתי בהמשך. אנחנו בונים שריר, לא רק קוראים על אימון.

הערה על המספרים בפרק: Cloudflare משנה מחירים, מגבלות ומוצרים תכופות. כל המספרים פה אומתו מול התיעוד הרשמי בתאריך הכנת הקורס (מאי 2026), אבל הסעיפים הרגישים מסומנים — תמיד שווה לאמת מול הדף הרשמי לפני בנייה כבדה.

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

הקורס הזה מדבר אל Vibe Coder — מי שבונה דברים אמיתיים עם כלי AI (Claude Code, Cursor, V0, Lovable), נוח בטרמינל, יודע לקרוא קוד JavaScript/TypeScript אבל לא בהכרח כותב אותו מאפס. אם זה אתה, יש לך יתרון ענק: ה-AI כותב את הקוד, אבל מישהו צריך להחליט איפה הוא רץ ומה הוא עולה — וזה בדיוק הפער שהקורס סוגר. ה-AI לא ידע בשבילך שאתה הולך לשבור את מגבלת KV writes, או ש-Stream יעלה לך כסף; את ההחלטות האלה אתה מקבל, והפרק הזה נותן לך את הכלים.

אנחנו לא מניחים שאתה מכיר את Cloudflare. נתחיל מפתיחת חשבון. אנחנו כן מניחים שיש לך טרמינל, ש-Node מותקן (נבדוק מיד), ושאתה לא נבהל מהרצת פקודה. כל מונח טכני באנגלית מוסבר בפעם הראשונה שהוא מופיע, וכל המונחים מרוכזים במילון בראש הפרק.

למה דווקא Cloudflare ולא Vercel, Netlify או AWS? שלוש סיבות: ה-free tier הנדיב באמת (לא trial ל-30 יום), ה-$0 egress של R2 (חוסך הון כשמגישים קבצים), והעובדה שהכל יושב על edge אחד — compute, storage, AI ו-media באותו מקום, מחוברים ב-bindings. בשביל מי שבונה לבד ורוצה לפרוס מהר בלי להפוך ל-DevOps engineer, זה השילוב הקשה ביותר לנצח.

מפת ה-Developer Platform: כל המוצרים על דף אחד

כשנכנסים לראשונה ל-Cloudflare Developer Platform זה מציף: עשרות שמות מוצרים, כל אחד עם דף תיעוד משלו. אבל יש סדר מתחת לבלגן. אפשר לחלק את הכל ל-חמש שכבות, וכל המוצרים נתלים על דבר אחד מרכזי — ה-Worker.

הנקודה החשובה ביותר: ה-Worker הוא המרכז. כל שאר השכבות מתחברות אליו כ-binding — שורה אחת ב-wrangler.toml שאומרת ל-Worker "יש לך גישה ל-KV הזה / D1 הזה / R2 הזה". במקום לנהל קרדנציאלס, מחרוזות חיבור ו-API keys, אתה מצהיר על binding וה-Worker מקבל אובייקט מוכן לשימוש (כמו env.DB או env.BUCKET). זה הדפוס שיחזור על עצמו בכל פרק בקורס.

למה ה-binding כל-כך חשוב? כי הוא מבטל שכבה שלמה של כאב. בענן רגיל, כדי שהקוד שלך יגיע לבסיס נתונים אתה מנהל מחרוזת חיבור עם סיסמה, דואג שהיא לא תדלוף ל-git, מגדיר רשתות ו-firewall. ב-Cloudflare, ה-binding הוא קישור ישיר ברמת הפלטפורמה — אין סיסמה לנהל, אין endpoint ציבורי לחשוף, והגישה מהירה כי הכל באותו edge. כשתבנה את ה-SaaS המלא בפרק 6, ה-wrangler.toml שלך יחזיק את כל ה-bindings יחד — D1, R2, KV, AI — והקוד פשוט יקרא env.DB, env.BUCKET, env.AI. זה כל הסוד.

אל תיבהל מכמות המוצרים. בקורס הזה נוסיף אותם בהדרגה, שכבה אחרי שכבה — בדיוק לפי המפה למעלה. בפרק הזה אנחנו נוגעים ב-Compute (Worker) וב-Edge (Static Assets, Tunnel). בפרק 2 נוסיף את כל שכבת ה-Storage. בפרק 3 את ה-AI. וכן הלאה. עד סוף הקורס, כל קופסה במפה תהיה משהו שכבר השתמשת בו.

טעות שכדאי להימנע ממנה כבר עכשיו: לנסות להבין את כל המוצרים לפני שמתחילים לבנות. זו דרך בטוחה לשיתוק. הגישה הנכונה היא הפוכה — תתחיל עם Worker + Static Assets (מה שתפרוס היום), ותוסיף primitive רק כשיש לך בעיה ספציפית שהוא פותר. צריך לשמור config? תוסיף KV. צריך נתונים רלציוניים? תוסיף D1. צריך לאחסן קבצים שמשתמשים מעלים? תוסיף R2. כל אחד מהם הוא בסך הכל עוד binding ב-wrangler.toml — תוספת של דקות, לא ימים. המפה היא מצפן, לא רשימת מטלות.

Workers על Isolates: למה אין Cold Start ולמה זה משנה לך

אם אתה בא מ-AWS Lambda או מ-Vercel functions, אתה מכיר את ה-cold start — הבקשה הראשונה אחרי שקט מחכה שניות עד שהקונטיינר נטען. ב-Workers אין דבר כזה, וזה לא טריק שיווקי. זה נובע מארכיטקטורה שונה לחלוטין.

במקום להריץ כל פונקציה בקונטיינר (מכולה) משלה, Cloudflare מריצה אותה ב-V8 isolate — אותו מנגנון בידוד שבו Chrome מפריד בין טאבים. ה-isolate הוא קל-משקל בקיצוניות: אלפי isolates חיים באותו תהליך, וההפעלה של אחד חדש לוקחת מילי-שניות בודדות, לא שניות. התוצאה: ה-Worker שלך רץ קרוב למשתמש (ב-300+ ערים ברחבי העולם), נטען מיידית, ו-scale-to-zero — כשאף אחד לא משתמש בו, הוא לא צורך כלום, ולא משלמים על זמן המתנה.

למה זה משנה לך בפועל? כי המודל הזה הופך כל פרויקט קטן לזול עד אפס. ב-AWS Lambda מאחורי API Gateway, אפילו אפליקציה שאף אחד לא משתמש בה יכולה לצבור עלויות (provisioned concurrency, idle resources). ב-Workers, אם אין תעבורה — אין עלות, נקודה. אתה יכול לפרוס עשרה פרויקטי-צד שונים, להשאיר אותם חיים לנצח, ולשלם $0 כל עוד הם לא חוצים את הקוטה. זה משחרר אותך לנסות רעיונות בלי לחשב כל הזמן "כמה זה ידלוף לי בחשבון".

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

נקודת מפתח שתחזור בכל הקורס: ה-isolate רץ אצל Cloudflare, אבל כלי הפיתוח רצים אצלך. wrangler, node ו-npm מותקנים על המחשב שלך ומריצים סימולציה לוקלית של ה-edge (Miniflare). זאת הסיבה ש-"פריסה תוך 10 דקות" מניחה ש-Node כבר מותקן — בלעדיו אין כלום.

מה זה אומר בפועל לדבר שאתה פורס

בוא נתרגם את המגבלות האלה למקרים אמיתיים שתיתקל בהם כ-Vibe Coder, כי ההבדל בין "הבנתי את התיאוריה" ל"לא אבזבז שעה על באג" הוא בדיוק כאן:

• API שעוטף שירות חיצוני (למשל proxy ל-OpenAI, או endpoint שמושך נתונים מ-API ומחזיר אותם) — מושלם ל-Worker. רוב הזמן הוא ב-await על הרשת, שלא צורך CPU. זה התרחיש הכי נפוץ ל-Vibe Coders, והוא נכנס בקלות ב-free tier.
• עיבוד תמונה כבד בצד השרת (resize עם sharp, יצירת thumbnail) — בעייתי. sharp הוא native module שלא ירוץ ב-isolate, ועיבוד פיקסלים שורף CPU. הפתרון הנכון הוא Image Transforms של Cloudflare (פרק 4), לא קוד ב-Worker.
• אפליקציה שמחזיקה state בזיכרון (למשל "ספירת מבקרים חיה" שנשמרת ב-RAM) — לא תעבוד כמו שאתה מצפה. כל בקשה עלולה לרוץ ב-isolate אחר, והזיכרון לא משותף בין בקשות. ל-state אמיתי צריך KV/D1/Durable Objects (פרק 2).
• קריאת/כתיבת קבצים מהדיסק (fs.readFile) — פשוט לא קיים. אם הקוד שה-AI כתב לך משתמש ב-fs, זה דגל אדום שצריך להחליף ב-binding של R2 או KV.

הכלל המנטלי: Worker מצוין ב-glue ובהזרמת נתונים, פחות טוב ב-compute כבד. כשה-AI כותב לך קוד שעושה הרבה עיבוד מקומי, עצור ושאל — האם זה צריך לרוץ ב-Worker, או שיש primitive מנוהל שעושה את זה בשבילי?

ה-Free Tier המלא במספרים: מה מקבלים ב-$0

זה הסעיף שתחזור אליו שוב ושוב. כל המספרים פה אומתו מול התיעוד הרשמי (מאי 2026). שמור אותו — בתרגיל 2 תהפוך אותו לטבלה אישית לאפליקציה שלך.

Compute — מה ה-Worker עצמו מקבל

Storage — איפה שומרים נתונים

תוספות שכדאי לזכור

• Tunnel — חינם לתמיד. חשיפת localhost ב-HTTPS בלי תקרת נפח (סעיף נפרד בהמשך).
• Workers AI — 10,000 neurons/day. אזכור קל בלבד כאן; "neuron" הוא יחידת compute שמנרמלת מחיר inference. ~350 קריאות ל-llama-3.1-8b ביום. נצלול לזה בפרק 3.

שים לב ל-אסימטריה בין reads ל-writes. KV נותן 100,000 קריאות אבל רק 1,000 כתיבות. D1 נותן 5 מיליון שורות-קריאה אבל "רק" 100,000 שורות-כתיבה. הדפוס הזה — קריאות זולות, כתיבות יקרות — הוא בדיוק מה שיקבע איזו מגבלה תיפול ראשונה אצלך. נחזור לזה בסעיף ה-$5.

איך לקרוא את המספרים האלה נכון

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

• 100,000 בקשות/יום ≈ אם כל משתמש פעיל עושה 50 בקשות ביום, זה תומך ב-~2,000 משתמשים פעילים יומיים (DAU) לפני שתיגע בתקרה. ובקשות ל-Static Assets לא נספרות — רק בקשות שמפעילות קוד Worker.
• 1,000 KV writes/יום ≈ הקוטה הכי קטנה, ולכן הכי מסוכנת. אם אתה כותב ל-KV בכל login (session) או בכל אירוע analytics, 1,000 משתמשים = 1,000 כתיבות = הקיר. זו הסיבה ש-KV מתאים ל-config ו-feature flags (קוראים הרבה, כותבים מעט), לא ל-state שמשתנה כל הזמן.
• 5GB ב-D1 ≈ מיליוני שורות טקסט. לרוב אפליקציה לא תיגע בקיר האחסון של D1 — תיגע קודם בקיר ה-writes או ב-rows-read.
• 10GB + $0 egress ב-R2 — ה-$0 egress הוא הקסם. בענן רגיל (S3) אתה משלם על כל בייט שיוצא; ב-R2 ההורדה חינמית לתמיד, בכל הטיירים. זה הופך את R2 לבחירה ברורה ל-CDN תמונות וקבצים.

שמור את המספרים האלה לא בעל-פה אלא בטבלה — בדיוק מה שתבנה בתרגיל 2. טבלה שמתרגמת כל מגבלה למשתמשים של האפליקציה שלך שווה יותר מכל רשימת מספרים גנרית.

מה נראה חינמי אבל לא: Stream, Images Storage, Containers

כאן נופלים הכי הרבה אנשים. כל המוצרים בקטגוריה הזו נראים כמו חלק מ-Cloudflare החינמית, אבל אין להם free tier אחסון/delivery — והחיוב מתחיל מהדקה הראשונה, לפעמים גם אם אף אחד לא משתמש בתוכן.

הכלל הפשוט: וידאו ותמונות מאוחסנות עולות כסף, גם ב-Cloudflare. מה שחינם זה ה-compute (Worker), האחסון הגנרי (R2/KV/D1) וההגשה הסטטית. ברגע שאתה רואה מוצר מדיה מנוהל — עצור ובדוק ב-FlareCalc לפני שאתה בונה עליו.

למה Cloudflare בכלל מציעה את המוצרים ה"לא-חינמיים" האלה אם יש workaround חינמי לכל אחד? כי ה-workaround עולה לך בעבודה. Stream נותן לך transcoding אוטומטי, HLS, ו-player מובנה — דברים שתצטרך לבנות בעצמך עם R2 + HLS. Cloudflare Images נותן ניהול מלא של נכסי תמונה. הבחירה היא קלאסית: זמן מול כסף. בתור Vibe Coder בתחילת פרויקט, כמעט תמיד עדיף ה-workaround החינמי (R2 + Transforms) — אתה עוד לא יודע אם הפרויקט ישרוד, אז למה לשלם. אם וכאשר תגיע למסה קריטית של וידאו, Stream הופך משתלם. נדון בזה לעומק בפרק 4; כאן העיקר הוא לדעת שהמוצרים האלה לא חינמיים, כדי לא להיתפס.

מקרה מבחן מהיר: נניח שאתה בונה אפליקציה שמאפשרת למשתמשים להעלות תמונת פרופיל ולהציג אותה בגדלים שונים. התחושה אומרת "אשתמש ב-Cloudflare Images, זה בדיוק בשבילי". המציאות: אחסון ב-Cloudflare Images הוא paid. הדרך הנכונה ב-$0: אחסן את המקור ב-R2 (10GB, $0 egress), והגש בגדלים שונים דרך Image Transforms (5,000 unique/חודש חינם). אותה חוויית משתמש בדיוק, אפס עלות. זה בדיוק סוג ההחלטה שהקורס מאמן אותך לקבל אוטומטית.

Static Assets מול Pages ב-2026: על מה להתחיל פרויקט חדש

אם חיפשת איך לארח אתר ב-Cloudflare, בטוח נתקלת ב-Pages וגם ב-Static Assets, ואולי שמעת לחישות ש-"Pages מת". בוא נסדר את זה נכון, כי זה תחום עם הרבה דיסאינפורמציה.

Pages אינו deprecated ואינו sunset. Cloudflare הצהירה זאת בפומבי. פרויקט Pages קיים שעובד ימשיך לעבוד, ולאתר סטטי פשוט עם git CI/CD — Pages עדיין בחירה תקפה לחלוטין.

אבל — וזה ה"אבל" המעשי — ל-Workers יש feature-set רחב בהרבה, והפיצ'רים החדשים נוחתים שם קודם. כמה מהיכולות הבאות זמינות רק על Workers, לא על Pages:

המסקנה המעשית: פרויקט full-stack חדש ב-2026 צריך להתחיל על Workers + Static Assets. לא כי Pages "מת", אלא כי אתה רוצה גישה ל-Durable Objects, Cron ו-Queues כשתצטרך אותם — בלי הגירה כואבת באמצע. וזה בדיוק מה שנעשה בפרק הזה: Worker עם בלוק [assets] שמגיש את ה-frontend.

מבחינה מעשית, ההבדל בחוויית הפיתוח קטן. בשני המקרים אתה כותב HTML/CSS/JS (או build של framework כמו React/Svelte) לתיקייה, ו-Cloudflare מגישה אותה מה-edge. ההבדל הוא מה מסביב: על Workers, אותו פרויקט שמגיש את ה-frontend יכול גם להריץ API (ה-Worker עצמו), לגשת ל-D1, לתזמן Cron ולצרוך Queues — הכל ב-wrangler.toml אחד. על Pages תצטרך Pages Functions נפרדות עם פחות יכולות. בשביל Vibe Coder שבונה SaaS שלם, זה ההבדל בין מקום אחד לכל הלוגיקה לבין פיצול מלאכותי.

עוד נקודה ששווה לדעת: גם Workers תומך ב-git CI/CD מובנה (Workers Builds) — אז גם הטיעון הקלאסי בעד Pages ("רק על Pages יש deploy אוטומטי מ-git") כבר לא תקף ב-2026. אין כמעט מקרה שבו פרויקט חדש חייב להתחיל על Pages.

מתקינים את הסביבה: c3, wrangler dev, Miniflare ו-.dev.vars

עכשיו לחלק שאתה מחכה לו — לפרוס משהו חי. נתחיל ביצירת השלד. הכלי הוא c3 (create-cloudflare), אשף שיוצר פרויקט מוכן, מתקין dependencies ומגדיר wrangler.toml ראשוני.

הפקודה (זו הפקודה המאומתת — העתק בדיוק):

npm create cloudflare@latest -- my-first-worker

(אם אתה מעדיף pnpm או yarn: pnpm create cloudflare@latest my-first-worker או yarn create cloudflare my-first-worker.)

האשף ישאל כמה שאלות. לפרק הזה בחר את התבנית "Hello World example" → "Worker only" — Worker בסיסי שמחזיר טקסט. עצור לפני שלב ה-deploy (אם האשף מציע לפרוס בסוף — סרב בינתיים), כי אנחנו רוצים להבין כל שלב.

הקובץ החשוב: wrangler.toml

זה לב הפרויקט. הנה מבנה בסיסי תקין (מאומת מול התיעוד) עם בלוק [assets] לאתר סטטי:

name = "my-first-worker"
main = "src/index.ts"
compatibility_date = "2026-05-01"
compatibility_flags = ["nodejs_compat"]

# Static Assets: הגשת קבצים מתיקיית ./public, וחשיפת env.ASSETS
# ל-Worker כדי שיוכל ליפול חזרה לקבצים סטטיים ב-routes של SPA.
[assets]
directory = "./public"
binding = "ASSETS"

# bindings שתוסיף בהמשך הקורס (כולם free-tier) — כרגע מוערים:
# [[kv_namespaces]]
# binding = "MY_KV"
# id = "<your-kv-namespace-id>"
#
# [[d1_databases]]
# binding = "DB"
# database_name = "my-app-db"
# database_id = "<your-d1-database-id>"

טיפ: לאתר סטטי לחלוטין (בלי קוד Worker) אפשר למחוק את שורת main ואת שורת binding, ולהשאיר רק directory — Cloudflare תגיש את הקבצים בלי Worker בכלל. בקורס הזה נשאיר Worker, כי בפרק הבא נוסיף לו לוגיקה.

הרצה לוקלית: wrangler dev + Miniflare

היכנס לתיקיית הפרויקט והרץ:

npx wrangler dev

זה מפעיל שרת פיתוח לוקלי על http://localhost:8787 עם hot reload — כל שינוי בקוד מתעדכן מיד. מתחת למכסה המנוע רץ Miniflare, סימולטור שמריץ את ה-Worker ואת ה-bindings (KV/D1/R2) על המחשב שלך, כך שאתה מפתח בלי לגעת בענן. (יש גם npx wrangler dev --remote שמריץ מול ה-edge האמיתי — שימושי כש-Miniflare לא מדמה משהו במדויק.)

למה שני מצבים? Miniflare (ברירת המחדל, לוקלי) מהיר, חינמי ולא נוגע בקוטה — אידיאלי ל-90% מהפיתוח. אבל הוא סימולציה, ולפעמים יש פערים: מודל ה-consistency של KV, התנהגות מדויקת של Workers AI, או binding שעוד לא ממומש מקומית. כשמשהו עובד ב-wrangler dev אבל נשבר אחרי deploy, הצעד הראשון לדיבוג הוא להריץ wrangler dev --remote ולראות אם הבעיה מופיעה מול ה-edge האמיתי. זה חוסך שעות.

סודות לוקליים: .dev.vars

כשתצטרך מפתח API או סוד בפיתוח, אל תכתוב אותו בקוד ואל תשים אותו ב-[vars] (שם הוא plaintext ונכנס ל-git). במקום זה, צור קובץ .dev.vars בשורש הפרויקט בפורמט dotenv:

API_KEY="sk-local-dev-value"
DATABASE_URL="postgres://user:pass@host:5432/db"

.dev.vars נקרא רק ע"י wrangler dev, וחייב להיכנס ל-.gitignore. המקבילה ל-production היא npx wrangler secret put SECRET_NAME — שמצפין את הסוד בצד השרת.

הפריסה הראשונה: wrangler deploy ל-URL חי

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

שלב 1 — התחברות

npx wrangler login

זה יפתח מסך OAuth בדפדפן שמבקש לאשר ל-Wrangler גישה לחשבון Cloudflare שלך. אל תיבהל — זה צפוי, וזו דרך החיבור הסטנדרטית. אחרי האישור, ה-token נשמר לוקלית. ודא שאתה מחובר לחשבון הנכון:

npx wrangler whoami

למה OAuth ולא הדבקת API token? כי זו הדרך הבטוחה והמהירה למתחיל. ה-OAuth flow מאמת אותך מול הדפדפן שכבר מחובר ל-Cloudflare, ושומר token מצומצם-הרשאות לוקלית. אין צורך ליצור token ידנית, להעתיק אותו, או לדאוג שידלוף. (למתקדמים ול-CI/CD יש דרך אחרת — משתנה סביבה CLOUDFLARE_API_TOKEN — אבל לפיתוח לוקלי, wrangler login הוא הנכון.) אם wrangler whoami מראה את האימייל והחשבון הנכונים, אתה מוכן.

שלב 2 — פריסה

npx wrangler deploy

בפעם הראשונה Cloudflare תבקש ממך לבחור subdomain לחשבון (למשל nadav-dev). זה קורה פעם אחת בלבד — מכאן והלאה כל ה-Workers שלך יחיו תחת אותו subdomain. אחרי הפריסה ה-Worker חי בכתובת:

https://<WORKER_NAME>.<YOUR_SUBDOMAIN>.workers.dev

למשל https://my-first-worker.nadav-dev.workers.dev. פתח אותה — היא חיה, ב-HTTPS, נגישה מכל מקום בעולם. שים לב שקיבלת HTTPS בלי לעשות כלום — בלי תעודת SSL, בלי הגדרת DNS, בלי שרת. זה חלק ממה שהופך את workers.dev לכלי כל-כך מהיר לדמואים.

כמה דברים ששווה לדעת על ה-URL הזה: ה-subdomain (nadav-dev בדוגמה) משותף לכל ה-Workers בחשבון, ושם ה-Worker (my-first-worker) נקבע משדה name ב-wrangler.toml. אם תשנה את name ותפרוס שוב — תקבל URL חדש, וה-Worker הישן יישאר חי תחת השם הקודם (עד שתמחק אותו). לכתובת ייצור אמיתית (דומיין משלך) מחברים custom domain — אבל זה לפרק מתקדם; ל-MVP ולדמו, *.workers.dev מספיק לחלוטין.

אתר סטטי + Worker יחד

אם הוספת בלוק [assets] עם directory = "./public", אז wrangler deploy מעלה גם את הקבצים הסטטיים. ה-binding ASSETS מאפשר ל-Worker שלך ליפול חזרה לקובץ סטטי (דפוס שימושי ל-SPA: כל route לא-מוכר מחזיר את index.html). זה בדיוק מה שתבנה בתרגיל 1.

בפועל זה עובד כך: כשבקשה מגיעה, Cloudflare בודקת קודם אם יש קובץ סטטי תואם בתיקיית ה-assets. אם כן — היא מגישה אותו ישירות (חינם, בלי להפעיל את ה-Worker). אם לא — הבקשה עוברת לקוד ה-Worker, שיכול להחליט מה לעשות: להחזיר תשובת API, או — בעזרת env.ASSETS.fetch() — להחזיר את index.html כדי שה-router בצד הלקוח (React Router, למשל) יטפל ב-route. זה הדפוס הסטנדרטי ל-SPA full-stack: frontend סטטי + API באותו Worker, באותו URL, ב-deploy אחד. ה-index.html הראשון שלך יכול להיות פשוט כמו:

<!DOCTYPE html>
<html lang="he" dir="rtl">
<head><meta charset="UTF-8"><title>האתר שלי</title></head>
<body>
  <h1>האתר הראשון שלי על Cloudflare</h1>
  <p>פרוס על ה-edge, חי בכל העולם, ב-$0.</p>
</body>
</html>

שמור אותו ב-./public/index.html, וה-deploy יגיש אותו בשורש ה-URL.

Logs חיים

לראות מה קורה ב-Worker בזמן אמת:

npx wrangler tail

זה מזרים לטרמינל כל בקשה ו-console.log מה-Worker הפרוס — כלי הדיבוג הראשון שתשתמש בו. בניגוד ל-wrangler dev שמראה logs לוקליים, wrangler tail מראה לך מה קורה ב-Worker החי, מול תעבורה אמיתית. כשמשתמש מדווח "האתר נשבר אצלי", זה הדבר הראשון שתפעיל כדי לראות את השגיאה בזמן אמת.

שלוש טעויות התחלה נפוצות בפריסה הראשונה, שכדאי להכיר מראש: (1) לשכוח wrangler login — ה-deploy ייכשל עם שגיאת אימות; הפתרון פשוט, פשוט להתחבר. (2) שם Worker תפוס או לא חוקי — שמות מותר להם אותיות קטנות, מספרים ומקפים בלבד; אם name ב-wrangler.toml מכיל רווח או אות גדולה, תקבל שגיאה. (3) לבחור subdomain בחיפזון — ה-subdomain קבוע לחשבון, אז בחר שם נקי וקריא (לא test123) כי הוא יופיע בכל URL שתפרוס. אף אחת מאלה לא קריטית — כולן הודעות שגיאה ברורות עם פתרון מיידי — אבל לדעת עליהן מראש חוסך את רגע הבלבול הראשון.

מלכודת .assetsignore: למה ה-deploy מעלה 40,000 קבצים

זו אחת המלכודות שתופסת כמעט כל מי שעובר מ-Pages ל-Static Assets, ולוקח שעה להבין מה קרה. הנה התרחיש: אתה מריץ wrangler deploy, וה-deploy פתאום לוקח דקות, מנסה להעלות עשרות אלפי קבצים, ואולי אפילו נכשל. למה?

כי Static Assets לא מחריג node_modules אוטומטית כמו ש-Pages עשה. כשהגדרת directory = "./public" זה בסדר — אבל אם בטעות כיוונת את ה-directory לשורש הפרויקט, או ש-node_modules נמצא בתוך תיקיית ה-assets, wrangler ינסה להעלות את כל ה-node_modules. תיקיית node_modules טיפוסית מכילה עשרות אלפי קבצים — וזה חוצה מיד את מגבלת 20,000 הקבצים של ה-free tier.

הפתרון: קובץ .assetsignore בתוך תיקיית ה-assets, שמורה ל-wrangler מה לדלג עליו. הפורמט הוא רשימת נתיבים/glob, אחד בכל שורה (סגנון דומה ל-.gitignore):

node_modules
.git
.DS_Store
*.log
.dev.vars
.env

אחרי שיצרת אותו, בפלט של wrangler deploy ודא שמספר הקבצים שמועלים סביר (בודדים עד עשרות לאתר טיפוסי), לא עשרות אלפים. זה הסימן שה-.assetsignore עובד.

איפה בדיוק שמים את הקובץ? בתוך תיקיית ה-assets (זו שהגדרת ב-directory), לא בשורש הפרויקט. אם directory = "./public", אז הקובץ הוא ./public/.assetsignore. זו נקודה שמבלבלת — בניגוד ל-.gitignore שיושב בשורש, .assetsignore יושב בתוך התיקייה שממנה מעלים.

שתי דרכים נוספות להימנע מהמלכודת לגמרי: (1) הקפד שתיקיית ה-assets תכיל רק את ה-build הסטטי (HTML/CSS/JS/תמונות) — לא את כל הפרויקט. אם אתה משתמש ב-framework, ה-directory צריך להצביע על תיקיית ה-dist/build, שבה אין node_modules מלכתחילה. (2) תמיד תסתכל על השורה בפלט ה-deploy שאומרת כמה קבצים הועלו — היא ה-canary שלך. ראית מספר תלת-ספרתי ומעלה לאתר פשוט? עצור ובדוק את ה-directory ואת ה-.assetsignore.

חושפים localhost ב-HTTPS: wrangler tunnel quick-start

תרחיש קלאסי של Vibe Coder: בנית משהו ב-localhost, ולקוח/חבר רוצה לראות אותו עכשיו מהטלפון שלו. עד היום היית שולף את ngrok. מ-מרץ 2026, Wrangler עושה את זה בפקודה אחת, חינם, בלי חשבון:

npx wrangler tunnel quick-start http://localhost:8787

זה מקים Quick Tunnel — מנהרה זמנית שמחזירה URL אקראי בתבנית https://<random>.trycloudflare.com שמפנה ל-localhost שלך. אין port forwarding, אין הגדרת DNS, אין חשבון. אתה מכוון אותו ל-port של ה-wrangler dev שלך (8787 כברירת מחדל), והנה — ה-localhost שלך חי באינטרנט ב-HTTPS.

למה זה כל-כך שימושי ל-Vibe Coder? כי הפער בין "עובד אצלי" ל"הלקוח רואה" הוא לרוב חיכוך מטופש: לפרוס deploy מלא רק כדי שמישהו יסתכל, או להתעסק עם הגדרות רשת. Quick Tunnel מוחק את החיכוך — אתה ממשיך לפתח לוקלית עם hot reload מלא, והלקוח רואה כל שינוי בזמן אמת דרך ה-URL הציבורי. זה גם פותר תרחישים כמו בדיקת webhook מספק חיצוני (Stripe, GitHub) שצריך URL ציבורי כדי לשלוח אליו אירועים, או בדיקת איך האתר נראה בפועל על מכשיר נייד אמיתי, לא רק ב-DevTools.

חשוב להבין מה Quick Tunnel אינו: ה-URL אקראי ומשתנה בכל הרצה, הוא נעלם כשאתה סוגר את הטרמינל, ואין לך שליטה על הדומיין. לכל אלה — דומיין יציב, URL קבוע, ניהול מרחוק — צריך named tunnel (פרק 5). Quick Tunnel הוא ה-"ngrok של 30 שניות", לא תשתית production.

(הפקודה היא חלק מסט פקודות ה-tunnel שנוסף ב-2026-03-19: create, list, info, delete, run, quick-start — ניהול מנהרות מתוך Wrangler בלי להתקין cloudflared בנפרד.)

ה-Forcing Function של $5: מתי Workers Paid הופך מחובה

בשלב מסוים, לכל אפליקציה רצינית, ה-free tier ייגמר. השאלה היא לא אם אלא מתי, ואיזה primitive ישבור ראשון. ההבנה הזו היא מה שמבדיל בין "פרסתי משהו" ל"אני יודע לתכנן עלות".

הקפיצה הראשונה היא ל-Workers Paid — $5/חודש מינימום. מה $5 פותחים:

הקפיצה פרופורציונלית: ה-CPU עולה פי 3,000 (מ-10ms ל-30s), הבקשות הופכות לבלתי-מוגבלות יומית, וה-KV writes קופצים מ-1,000/יום ל-1M/חודש. בשביל $5 זו עסקה מצוינת — וזו הסיבה שאין טעם "להילחם" על ה-free tier כשכבר חצית.

נקודה פסיכולוגית שכדאי לקבל מראש: הרבה מפתחים מתעקשים להישאר ב-$0 גם כשהאפליקציה כבר חוצה את הקיר, ומשקיעים שעות ב-workarounds מפותלים כדי לחסוך $5. זו טעות בחישוב. אם האפליקציה שלך מספיק פעילה כדי לשבור את ה-free tier, שעה אחת של עבודה שלך שווה הרבה יותר מ-$5. ה-$5 אינו "כישלון להישאר חינמי" — הוא סימן שהאפליקציה מצליחה. המטרה של הקורס היא לדעת בדיוק מתי זה קורה ולמה, לא להימנע מזה לנצח.

שווה גם לדעת מה $5 לא פותח: הוא לא הופך מוצרי "לא-חינם" (Stream, Images storage, Containers) לזולים — לאלה יש תמחור נפרד משלהם. $5 הוא ספציפית עבור Workers Paid (ה-compute ומגבלות ה-storage primitives הסטנדרטיים). אם האפליקציה שלך נשענת על Stream או Containers, החשבון יהיה גבוה יותר — ולכן ה-triage 3-דליים מהסעיף הקודם כל-כך חשוב.

איזו מגבלה תיפול ראשונה?

זוכר את האסימטריה reads-מול-writes מסעיף המספרים? היא קובעת את הסדר. חשוב: מה שבא עכשיו הוא heuristic מעשי — מה שראינו בפועל — לא דירוג רשמי של Cloudflare. אבל הוא עובד לרוב האפליקציות.

הסיבה שהסדר הזה חוזר על עצמו היא בכמה אפליקציות עובדות: רובן קוראות הרבה וכותבות מעט — חוץ מנקודה אחת, שבה הן כותבות לכל אירוע משתמש (session חדש, click, מדד analytics). הכתיבות האלה הולכות לרוב ל-KV, וה-1,000 כתיבות/יום הן הקוטה הקטנה ביותר במערכת כולה — לכן הן נשברות ראשונות. אחרי שמסדרים את הכתיבות (מעבירים analytics ל-Analytics Engine, sessions ל-Durable Objects), הקיר הבא הוא ה-CPU, שנפגע ברגע שמתחילים לעבד נתונים בתוך ה-Worker. ו-D1 writes נשברים אחרונים כי רוב האפליקציות פשוט לא כותבות 100,000 שורות ביום. כשאתה מתכנן אפליקציה, שאל לגבי כל פעולה: "האם זו כתיבה? לאן? כמה פעמים ביום?" — והתשובה תגיד לך איפה הקיר.

סיכום ומה הלאה: מ-Worker חי ל-Storage Primitives

עברת דרך ארוכה בפרק אחד. בוא נסכם מה השגת בפועל, ומה השתנה בעולם Cloudflare ב-2026 שכדאי להחזיק בראש. אם עשית את שלושת התרגילים — אתה כבר לא קורא על Cloudflare, אתה משתמש בה: פרסת Worker, חשפת localhost, ובנית מטריצת עלות אישית. זה הבסיס שכל שאר הקורס נבנה עליו.

מה השגת

• מפה מנטלית של 5 שכבות המוצרים — והבנה ש-ה-Worker הוא המרכז שהכל נתלה עליו.
• טבלת free-tier matrix אישית: מה חינם-לתמיד, מה חינם-עד-מגבלה, מה לא-חינם.
• Worker חי עם Static Assets פרוס על *.workers.dev, וגישה אליו מהטלפון.
• localhost חשוף ב-HTTPS דרך Quick Tunnel — דמו לקליינט בפקודה אחת.
• החלטת pay-or-not: אתה יודע איזו מגבלה תיפול ראשונה אצלך ומתי $5 הופך מחובה.

מילון 2026 — מה השתנה השנה

Cloudflare זזה מהר. שלושה שינויים שכדאי להכיר (כולם רק רקע לפרק הזה — נעמיק בהם בפרקים הבאים):

• Durable Objects SQLite — חיוב אחסון הופעל מתחילת ינואר 2026 (התאריך 7 בינואר היה יעד, לא תאריך-נעילה מדויק).
• Queues הפכו חינמיים (10,000 ops/day) ב-2026.
• Containers הגיעו ל-GA באפריל 2026 — אבל paid-only, לא חלק מה-free tier.

גשר לפרק הבא

יש לך Worker חי, אבל הוא עדיין "טיפש" — הוא לא זוכר כלום בין בקשות. בפרק 2 ניקח את אותו wrangler.toml ונוסיף לו זיכרון: KV, D1, R2 ו-Durable Objects. נפצח את "קיר ה-10ms" עד הסוף (מתי CPU נשרף ומתי לא), ותלמד לבחור את ה-primitive הנכון לכל בעיית אחסון — לפי consistency, מחיר והמגבלה שתיפול ראשונה. הטבלה שבנית היום תהיה הכלי שתשתמש בו שם.

צ'קליסט — סיכום פרק 1

• פתחתי חשבון Cloudflare חינמי (ללא כרטיס אשראי) ואני מחובר.
• אימתתי ש-node -v ו-npm -v מותקנים.
• אני יודע למנות את 5 שכבות ה-Developer Platform ולמה ה-Worker הוא המרכז.
• אני מבין למה אין cold start ומהן 4 מגבלות ה-isolate (128MB, אין filesystem, אין native modules, 10ms CPU).
• יצרתי טבלת free-tier matrix עם 7+ מוצרים והמגבלות החינמיות שלהם.
• אני מזהה את 3 הקטגוריות: חינם-לתמיד / חינם-עד-מגבלה / לא-חינם.
• אני יודע ש-Stream, Images storage, Containers ו-Email sending אינם חינמיים — ומה ה-workaround לכל אחד.
• אני מבין למה פרויקט חדש מתחיל על Workers + Static Assets (בלי לטעון ש-Pages מת).
• יצרתי wrangler.toml עם בלוק [assets] תקין.
• יצרתי .assetsignore ו-.dev.vars (ב-gitignore).
• הרצתי wrangler dev ואימתתי ב-localhost:8787.
• פרסתי עם wrangler deploy ופתחתי את ה-URL החי מהטלפון.
• חשפתי את ה-localhost ב-HTTPS עם wrangler tunnel quick-start ואימתתי ממכשיר חיצוני.
• אני יודע מתי $5 Workers Paid הופך מחובה ואיזו מגבלה תיפול ראשונה אצלי.
• שמרתי את ה-URL החי ואת קובץ המטריצה ב-README לקראת פרק 2.