Media ב-Edge — וידאו, תמונות, screenshots ו-real-time ב-$0

מפת ה-media ב-$0: מה באמת חינמי ומה רק נראה ככה

media זה השדה שבו אפליקציות שורפות הכי הרבה כסף בלי לשים לב. תמונה אחת שלא מכווצת היא 4MB; וידאו של חמש דקות הוא כמה מאות מגה; וכל אלה צריכים להיות מאוחסנים, מומרים ומוגשים שוב ושוב. אצל ספקים מסורתיים, ה-egress — הדאטה שיוצאת מהשרת אל הגולש — היא הרוצח השקט: אתה משלם על כל בייט שנשלח החוצה, וזה מצטבר מהר. לכן השאלה הראשונה בכל פרויקט media היא לא "איזה כלי הכי טוב", אלא "איפה מתחיל החיוב".

ב-Cloudflare התמונה שונה ומבלבלת בו-זמנית. יש כאן חמישה מוצרי media שונים, וההבחנה הקריטית היא בין אחסון/הגשה (storage/delivery) לבין עיבוד (transforms). העיבוד — לקחת תמונה קיימת ולשנות לה גודל, או לחתוך frame מסרטון — הוא חינמי בנדיבות. האחסון וההגשה של media מנוהל — Stream ו-Cloudflare Images — הם דווקא לא. זו בדיוק הנקודה שבה vibe coders נופלים: רואים "Cloudflare Images, 5,000 חינם" ומניחים שהכול חינם, ואז מגלים שה-5,000 מתייחס רק ל-transforms, וה-storage מחויב מהתמונה הראשונה.

בוא נסדר את זה אחת ולתמיד. R2 הוא ה-storage שלך — 10GB חינם, ו-egress תמיד $0, מה שהופך אותו לבסיס של כל workaround media חינמי. Image Transforms (ה-prefix /cdn-cgi/image/) נותן 5,000 המרות ייחודיות בחודש חינם בכל הטיירים. Media Transformations (ה-prefix /cdn-cgi/media/) נותן 5,000 פעולות ייחודיות בחודש לוידאו — הקצאה נפרדת לגמרי. Browser Run נותן 10 דקות דפדפן ביום. ו-Realtime נותן 1,000 GB egress בחודש. כל אלה — חינם.

ומה לא חינם? Cloudflare Stream — אין לו free tier בכלל. אתה משלם $5 לכל 1,000 דקות מאוחסנות, ועוד $1 לכל 1,000 דקות שמוגשות, גם אם אף אחד לא צפה. Cloudflare Images storage — paid-only: $5 לכל 100,000 תמונות מאוחסנות, $1 לכל 100,000 שמוגשות. שני אלה הם מוצרים מנוהלים שמרוויחים מהנוחות שלהם — ובהמשך הפרק נראה בדיוק מתי הנוחות הזו שווה את הכסף ומתי R2+ffmpeg חוסכים לך הכול.

הכלל המנחה לכל הפרק, אם תזכור רק משפט אחד: אחסן את המקורות ב-R2, עבד אותם דרך Transform URLs, ושמור את ה-media המנוהל (Stream/Images storage) רק כשאתה באמת צריך את ה-pipeline המנוהל ומוכן לשלם עליו. זו לא קמצנות — זו ארכיטקטורה. כשה-egress הוא $0 והעיבוד נספר רק על קומבינציות ייחודיות, אתה יכול לבנות CDN תמונות שמשרת מיליוני בקשות בלי לשלם, כל עוד אתה לא חורג מ-5,000 וריאציות שונות.

שים לב גם להבחנה דקה אחת שתחזור: ה-free tier של ה-transforms סופר קומבינציות ייחודיות, לא בקשות. אם 100,000 גולשים מבקשים את אותה תמונה ברוחב 400 פיקסל, זו המרה אחת שנספרת פעם אחת; שאר הבקשות מוגשות מה-cache בחינם. לעומת זאת, אם תבקש את אותה תמונה ב-50 רוחבים שונים, אלה 50 המרות. זה משנה לחלוטין איך אתה מתכנן וריאנטים, ונחזור לזה בסקשן הבא.

למה זה כל כך משחרר ל-vibe coder? כי זה מסיר את החרדה הגדולה ביותר של media — "מה יקרה אם הפרויקט שלי יתפוצץ ויקבל מיליון גולשים?". בארכיטקטורות מסורתיות, הצלחה היא בעיה: יותר תנועה = יותר egress = חשבון גדול יותר. כאן ההפך — ה-egress של R2 הוא $0 בכל קנה מידה, וה-transforms נספרים פעם אחת לכל וריאנט ולא לכל גולש. כלומר אפליקציה עם עשרה גולשים ואפליקציה עם עשרה מיליון גולשים משלמות אותו דבר על אותה תמונה: כלום. זה מה שהופך את ה-stack הזה למתאים בדיוק ל-vibe coder שלא יודע מראש אם הפרויקט יתרומם — אתה לא משלם על ההימור, רק על מה שבאמת בנית.

המספרים בפרק נכונים ל-מאי 2026. תמחור ושמות מוצרים ב-Cloudflare משתנים (Calls הפך ל-Realtime, חיוב Media Transformations התחיל ב-1 בנובמבר 2025) — לפני שאתה מתכנן תקציב production, אמת מול דף ה-pricing הרשמי של כל מוצר.

Image Transforms — resize, WebP/AVIF ו-crop דרך URL בלבד

Image Transforms הוא הפיצ'ר היחיד שאתה צריך כדי לבנות CDN תמונות מקצועי, והיופי בו הוא שאין בו שום קוד. אתה לא מתקין SDK, לא כותב Worker, לא מגדיר pipeline. אתה בונה URL. כל הלוגיקה של resize, חיתוך, שינוי איכות והמרת פורמט יושבת בתוך פרמטרים שאתה מצרף ל-URL, ו-Cloudflare מבצע את ההמרה ב-edge הקרוב לגולש ושומר את התוצאה ב-cache.

המבנה תמיד זהה: https://<ZONE>/cdn-cgi/image/<OPTIONS>/<SOURCE-IMAGE>. ה-OPTIONS הוא רשימה מופרדת בפסיקים — לפחות אופציה אחת חובה — וה-SOURCE-IMAGE יכול להיות נתיב יחסי על אותו zone, או URL מלא לתמונה במקום אחר (למשל ה-URL הציבורי של bucket R2). הנה דוגמה אמיתית:

https://your-zone.com/cdn-cgi/image/width=400,quality=85,format=auto/https://pub-xxxx.r2.dev/uploads/photo.jpg

# format=auto => AVIF/WebP לפי כותרת Accept. fit=cover,gravity=face ל-avatars:
https://your-zone.com/cdn-cgi/image/fit=cover,width=200,height=200,gravity=face/avatars/u123.png

בוא נפרק את האופציות החשובות. width (או w) ו-height (h) קובעים את הממדים בפיקסלים — או auto לרוחב שמתאים את עצמו. quality (q) הוא 1 עד 100; ערך 80–85 הוא נקודת המתיקות שבה העין כמעט לא רואה הבדל אבל המשקל צונח. format (f) קובע את פורמט הפלט, ובו טמון הקסם הגדול ביותר.

כשאתה כותב format=auto, Cloudflare בודק את כותרת ה-Accept של הדפדפן ומגיש את הפורמט המודרני ביותר שהוא תומך בו: AVIF לדפדפנים החדשים (קטן בערך ב-50% מ-JPEG באותה איכות), WebP לדפדפנים מעט ישנים יותר (קטן ב-25–35%), ו-JPEG כ-fallback. זה אומר שגולש בכרום מקבל AVIF זעיר וגולש בדפדפן ישן מקבל JPEG תקין — מאותו URL בדיוק, בלי שתכתוב שורת קוד אחת. הסתייגות חשובה: זה עובד רק כשהדפדפן שולח Accept מתאים; אל תבטיח ללקוח AVIF באופן גורף, כי דפדפנים מסוימים פשוט לא יבקשו אותו ויקבלו fallback.

ה-fit שולט באיך התמונה מתאימה את עצמה למסגרת: scale-down (לא מגדיל מעבר למקור), contain (כל התמונה נכנסת), cover (ממלא את המסגרת וחותך עודף), crop ו-pad. בשילוב עם gravity (למשל gravity=face שמזהה פנים, או gravity=auto שבוחר את האזור המעניין ביותר) אתה מקבל avatars מושלמים בלי לגעת ב-Photoshop. נקודה קריטית לתקציב: כל זה — שילוב של מספר אופציות + מקור — נספר כהמרה ייחודית אחת, לא כמה.

CDN תמונות חינמי בפועל: R2 כמקור + Transform URLs

עכשיו נחבר את שני החלקים: R2 כמקור האחסון, ו-Image Transforms כשכבת העיבוד. התוצאה היא CDN תמונות מלא — מקור יחיד, אינסוף גדלים, פורמטים מודרניים ו-edge caching — בעלות אפס. זו אחת הדוגמאות הנקיות ביותר ל"ארכיטקטורת $0" של Cloudflare, כי כל חלק בשרשרת חינמי: ה-storage (10GB ב-R2), ה-egress ($0 ב-R2), והעיבוד (5,000 המרות ייחודיות).

הזרימה היא כזו: אתה מעלה את התמונה פעם אחת ב-resolution הכי גבוה ל-R2. מפרסם את ה-bucket כ-public — או דרך subdomain של r2.dev (טוב ל-dev, לא ל-production) או דרך custom domain (production). ואז בונה URL של /cdn-cgi/image/ שמצביע על ה-URL הציבורי של R2. ה-edge מבצע את ההמרה בבקשה הראשונה, שומר את התוצאה ב-cache, ומכאן והלאה כל בקשה לאותו גודל מוגשת מיד מה-edge הקרוב לגולש.

בוא נעלה תמונה. עם wrangler זה שורה אחת — שים לב ל---content-type המפורש, שיהיה חשוב מאוד גם בהמשך כשנעבוד עם HLS:

wrangler r2 object put my-bucket/photo.jpg --file ./photo.jpg --content-type image/jpeg

אם אתה רוצה שליטה מלאה — למשל להגביל איזה objects חשופים, להוסיף headers משלך, או להגיש מ-bucket פרטי — אתה כותב Worker קטן שמגיש מ-R2. החלק הקריטי כאן הוא writeHttpMetadata: הוא לוקח את ה-content-type ושאר ה-metadata שנשמרו ב-upload ומדביק אותם על התגובה, כך שהדפדפן מקבל בדיוק את ה-content-type הנכון:

// מגיש כל object מ-R2 עם ה-content-type הנכון (מה-metadata שנשמר ב-upload)
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const key = url.pathname.slice(1); // מסיר את ה-/ הראשון
    if (request.method !== "GET") return new Response("Method Not Allowed", { status: 405 });

    const object = await env.MY_BUCKET.get(key);
    if (object === null) return new Response("Object Not Found", { status: 404 });

    const headers = new Headers();
    object.writeHttpMetadata(headers); // קובע content-type וכו' מה-metadata השמור
    headers.set("etag", object.httpEtag);
    return new Response(object.body, { headers });
  },
};

ה-binding ב-wrangler.toml הוא בדיוק זה שכבר הכרת מפרק 2 — אנחנו רק נשתמש בו שוב. נציג כאן את הצורה המלאה שתשרת אותנו לאורך הפרק, כולל הטבלה ל-Browser Run שנגיע אליה בקרוב:

[[r2_buckets]]
binding = "MY_BUCKET"
bucket_name = "my-bucket"

# binding ל-Browser Run (נפרד, טבלה עליונה — נשתמש בו בסקשן הבא):
[browser]
binding = "MYBROWSER"

שים לב למילה edge caching כאן — זה לא רק "מהיר יותר", זו הסיבה שזה חינם בקנה מידה. אחרי שהבקשה הראשונה הפעילה את ההמרה ושמרה אותה, כל הבקשות הבאות לאותו URL מוגשות מה-cache בלי להפעיל המרה חדשה ובלי לגעת ב-R2. כך אתה משלם (במונחי מכסה) פעם אחת לכל וריאנט, ומשרת תנועה בלתי מוגבלת. תוכל לאמת את זה ב-DevTools: בקשה ראשונה תראה cf-cache-status: MISS, והשנייה HIT.

Browser Run — Chrome headless ב-Edge עם Puppeteer

עכשיו נעבור ממדיה סטטית ל-media שאתה מייצר. Browser Run (השם הרשמי החדש למה שהיה Browser Rendering) הוא Chrome מלא, headless, שרץ ב-edge של Cloudflare. אתה שולט בו דרך Puppeteer — אותה ספרייה שמשתמשים בה לאוטומציית דפדפן בכל מקום — רק שכאן הדפדפן לא רץ על השרת שלך אלא ברשת של Cloudflare. עם זה אתה מצלם screenshots, מייצר PDF מדפים, וגורף תוכן מאתרים שדורשים JavaScript לרינדור.

למה vibe coder צריך את זה? כי המון משימות "פשוטות" דורשות דפדפן אמיתי. רוצה תמונת preview של URL ל-card ברשת חברתית? צריך לפתוח את הדף ולצלם. רוצה לייצר חשבונית PDF מתבנית HTML? אותו דבר. רוצה לבדוק שאתר עלה כמו שצריך? לפתוח ולצלם. בלי Browser Run היית צריך שרת עם Chrome מותקן, ניהול memory, ו-headless flags — כאן זה binding אחד, בלי שום תשתית משלך.

מתחילים בהתקנת החבילה. Cloudflare מספקת fork מותאם של Puppeteer:

npm i @cloudflare/puppeteer
# חלופה: npm i @cloudflare/playwright — אם אתה מעדיף Playwright API

עכשיו ה-binding. כאן יש תיקון חשוב שמדריכים ישנים מפספסים: הצורה המודרנית היא טבלה עליונה בשם [browser] עם binding = "MYBROWSER" — לא הצורה הישנה של browser = {} inline. אם תעתיק קוד ישן עם הצורה ה-inline, ה-binding פשוט לא יעבוד, וזה אחד מ-debugging-ים הכי מתסכלים כי הקוד "נראה נכון".

[browser]
binding = "MYBROWSER"

והנה ה-Worker הבסיסי שמצלם screenshot. שים לב לזרימה: משיגים את ה-URL מ-query string, מפעילים את הדפדפן דרך ה-binding, פותחים עמוד, מנווטים אליו, מצלמים, וסוגרים. הסגירה (browser.close()) קריטית — דפדפן פתוח שורף מהתקציב היומי שלך, ובהמשך נראה כמה מהר:

// wrangler.toml:
//   [browser]
//   binding = "MYBROWSER"
//
// src/index.js:
import puppeteer from "@cloudflare/puppeteer";

export default {
  async fetch(request, env) {
    const { searchParams } = new URL(request.url);
    const target = searchParams.get("url");
    if (!target) return new Response("Add ?url=https://example.com", { status: 400 });

    const browser = await puppeteer.launch(env.MYBROWSER);
    const page = await browser.newPage();
    await page.goto(target, { waitUntil: "networkidle0" });
    const img = await page.screenshot({ type: "png" });
    await browser.close();

    return new Response(img, { headers: { "content-type": "image/png" } });
  },
};

שתי נקודות עדינות בקוד. ה-waitUntil: "networkidle0" אומר ל-Puppeteer לחכות עד שהרשת נרגעה (אין בקשות פעילות) לפני שהוא מצלם — כך אתה מקבל את הדף המלא, לא שלד חצי-טעון. וה-type: "png" נותן איכות מלאה; אם אתה רוצה משקל קטן יותר אפשר type: "jpeg" עם quality. מעבר ל-Puppeteer, Browser Run תומך גם ב-Playwright וב-CDP (Chrome DevTools Protocol) ישיר — אבל ל-vibe coder, Puppeteer הוא הברירת מחדל הנוחה ביותר, ובו נישאר.

מגבלת 10 הדקות/יום: מה Browser Run כן ולא נועד אליו

עכשיו לחלק שמפריד בין מי שבונה דמו מגניב למי שמקבל הפתעה לא נעימה ב-production. ה-free tier של Browser Run הוא 10 דקות browser ביום ועד 3 דפדפנים במקביל. זה לא 10 דקות לכל בקשה — זה 10 דקות סך הכל ביום, מתאפס ב-00:00 UTC. וזה משנה לחלוטין את מה שאפשר לבנות.

בוא נעשה את החשבון, כי הוא מפכח. טעינה וצילום של דף ממוצע לוקחים בערך 5–10 שניות (תלוי במשקל הדף וב-networkidle0). ניקח 7 שניות כממוצע. 10 דקות = 600 שניות. 600 ÷ 7 ≈ 85 ניווטים ביום. בקצה האופטימי (5 שניות לדף) תקבל ~120, ובקצה הפסימי (10 שניות) ~60. אז התקציב היומי האמיתי שלך הוא בערך 60 עד 120 צילומים ביום, לא יותר. זכור גם שכברירת מחדל session נשאר פתוח עד 10 דקות של חוסר פעילות — אז אם שכחת browser.close(), אתה ממשיך לשרוף בשקט.

זה מספיק לגמרי בשביל: דמו, כלי פנימי, screenshot API אישי, או פיצ'ר preview באפליקציה קטנה. זה לא מספיק בשביל: scraping של production בקנה מידה, שירות screenshot ציבורי עם תנועה אמיתית, או כל דבר שצריך מאות-אלפי צילומים. אם תנסה — אחרי שהתקציב נגמר, הקריאות פשוט נכשלות עד reset, וזה ייראה כמו באג אקראי שמופיע "בערך באמצע היום".

אז מה הפתרון? cache. זו התובנה המרכזית של הסקשן: ברגע שצילמת URL מסוים, שמור את התוצאה ב-KV (או R2) ממופתחת ב-hash של ה-URL. בקריאה הבאה לאותו URL, בדוק קודם את ה-cache — אם הצילום קיים, החזר אותו בלי לפתוח דפדפן בכלל. ככה אתה הופך 85 ניווטים יקרים ל-85 צילומים ייחודיים, וכל שאר התנועה מוגשת מ-cache בחינם. זה בדיוק מה שנבנה בתרגיל הבא, וזו תבנית שתשרת אותך הרבה מעבר ל-screenshots.

שווה להכיר גם מה הגרסה בתשלום נותנת, כדי שתדע מתי לשדרג. ה-paid tier (חלק מ-Workers Paid, $5/חודש) מעלה ל-10 שעות browser בחודש ו-10 דפדפנים במקביל, ומוסיף שני פיצ'רים שהוצגו ב-Agents Week 2026: Live View (לצפות ב-session של הדפדפן בזמן אמת, מצוין ל-debugging של agent) ו-Human in the Loop (להשהות את ה-agent עד שאדם מאשר/מזין משהו — קריטי לזרימות שדורשות login או CAPTCHA). באותו עדכון הוכפלה גם ה-concurrency פי 4. כל אלה בתשלום, אבל הם הופכים את Browser Run מכלי screenshot לכלי automation אמיתי.

פרויקט: Edge Screenshot API עם cache ב-KV

זה הפרויקט שמרכיב את כל מה שלמדנו עד כה: Browser Run לצילום, R2 לאחסון, ו-KV ל-cache. התוצאה היא API חי שמקבל ?url=, מחזיר screenshot, ובקריאה חוזרת מגיש מ-cache בלי לשרוף עוד מהתקציב היקר של 10 הדקות. זה הופך את ~85 הניווטים היומיים ל-85 URLs ייחודיים — מעבר לזה, הכול מ-cache.

הלוגיקה בנויה כך: כשמגיעה בקשה, מחשבים מפתח cache מ-hash של ה-URL המבוקש. בודקים את KV — אם המפתח קיים, יש כבר צילום שמור, אז מחזירים מיד את ה-URL של R2 (או את הצילום עצמו) בלי לגעת בדפדפן. רק אם המפתח לא קיים, פותחים דפדפן, מצלמים, שומרים ל-R2 עם content-type נכון, רושמים את המפתח ב-KV, ומחזירים. ככה כל URL ייחודי עולה צילום אחד, ולא יותר.

שים לב ל-httpMetadata: { contentType: "image/png" } ב-put ל-R2 — בלעדיו, R2 ישמור את הקובץ עם content-type גנרי, וכשתגיש אותו מאוחר יותר הדפדפן לא ידע שזו תמונה. זו אותה מלכודת content-type שתחזור בענק בסקשן ה-HLS, אז כדאי להפנים אותה כבר עכשיו: תמיד קבע content-type מפורש ב-put ל-R2.

// wrangler.toml צריך: [browser] + [[r2_buckets]] (SHOTS) + [[kv_namespaces]] (CACHE)
import puppeteer from "@cloudflare/puppeteer";

export default {
  async fetch(request, env) {
    const target = new URL(request.url).searchParams.get("url");
    if (!target) return new Response("Add ?url=https://example.com", { status: 400 });

    // מפתח cache מ-hash של ה-URL
    const key = "shots/" + btoa(target).replace(/[^a-z0-9]/gi, "").slice(0, 40) + ".png";

    // 1) בדוק KV — אם קיים, החזר מ-R2 בלי דפדפן
    const cached = await env.CACHE.get(key);
    if (cached) {
      const obj = await env.SHOTS.get(key);
      if (obj) {
        const h = new Headers(); obj.writeHttpMetadata(h);
        return new Response(obj.body, { headers: h }); // HIT — 0 browser-minutes
      }
    }

    // 2) MISS — צלם בפועל
    const browser = await puppeteer.launch(env.MYBROWSER);
    const page = await browser.newPage();
    await page.goto(target, { waitUntil: "networkidle0" });
    const img = await page.screenshot({ type: "png" });
    await browser.close();

    // 3) שמור ל-R2 עם content-type, ורשום ב-KV
    await env.SHOTS.put(key, img, { httpMetadata: { contentType: "image/png" } });
    await env.CACHE.put(key, "1", { expirationTtl: 86400 }); // תוקף יום

    return new Response(img, { headers: { "content-type": "image/png" } });
  },
};

ה-expirationTtl: 86400 נותן ל-cache תוקף של יממה — אחרי זה, URL שביקשו שוב ירונדר מחדש (שימושי אם תוכן הדף משתנה). אתה יכול להאריך או לקצר לפי כמה "טרי" אתה צריך את הצילום. הגישה הזו — cache לפי hash, החזרה מ-store אם קיים — היא דפוס שתשתמש בו שוב ושוב בכל פעם שיש לך פעולה יקרה (browser-minutes, neurons מפרק 3, קריאת API חיצוני) שאתה לא רוצה לחזור עליה.

Cloudflare Stream — למה אין כאן free tier בכלל

עד כה הכול היה $0. עכשיו נכיר את המוצר היחיד בפרק שאין לו free tier בכלל — Cloudflare Stream — דווקא כדי שתבין למה ה-workaround של R2+HLS בסקשן הבא שווה את המאמץ. Stream הוא מוצר וידאו מנוהל ומצוין: אתה מעלה קובץ גולמי, והוא דואג לכל השאר — transcoding למספר איכויות, יצירת HLS ladder אוטומטית, player מובנה, signed URLs להגנה, ו-analytics לכל צופה. זה pipeline וידאו שלם בלי שתכתוב שורה.

אבל הנוחות הזו עולה כסף, ובמודל חיוב שתופס vibe coders לא מוכנים. החיוב הוא לפי דקות, בשני צירים. Storage: $5 לכל 1,000 דקות וידאו מאוחסנות, prepaid. Delivery: $1 לכל 1,000 דקות שמוגשות, post-paid. ה-encoding וה-ingress (ההעלאה עצמה) חינמיים — אבל ברגע שהקובץ יושב אצלם, השעון רץ.

הנה הנקודה שהכי כואבת: אתה משלם על דקות מאוחסנות גם אם אף אחד לא צופה. סרטון של 10 דקות שהעלית ושכחת ממנו ממשיך לעלות לך כל חודש, לנצח, רק על זה שהוא קיים. במונחים מעשיים: כל 1,000 דקות מאוחסנות = $5 לחודש על storage לבד. זה לא הרבה לסרטון אחד, אבל אם אתה בונה פלטפורמה עם תוכן משתמשים, ה-storage מצטבר בלי קשר לצפיות, ומכפיל את עצמו עם כל העלאה. חיוב Media Transformations, אגב, התחיל ב-1 בנובמבר 2025 — עוד תזכורת שהמספרים האלה חיים ומשתנים.

אז מה בכל זאת מצדיק את Stream? כשהדברים שהוא נותן באמת חשובים לך ואין לך זמן לבנות אותם: transcoding אוטומטי (אתה מעלה קובץ אחד, הוא מייצר את כל האיכויות), adaptive HLS ladder (הנגן עובר בין איכויות לפי מהירות הרשת של הצופה), player מובנה שעובד בכל דפדפן, signed URLs להגבלת גישה, ו-per-viewer analytics. אם אתה בונה פלטפורמת וידאו רצינית עם הרבה תוכן ומשתמשים, וזמן הפיתוח שלך יקר — Stream שווה את הכסף. אם הווידאו שלך קצר, ידוע מראש, ואתה מוכן ל-ffmpeg — תמשיך לסקשן הבא, שם נבנה את אותו דבר ב-$0.

וידאו ב-$0: HLS self-hosting על R2 (דפוס DIY)

הנה החלופה החינמית ל-Stream — ובמילה אחת היא HLS. HLS (HTTP Live Streaming) הוא הפרוטוקול שעליו רץ כמעט כל הווידאו באינטרנט. הרעיון פשוט: במקום קובץ וידאו ענק אחד, מפצלים את הסרטון לקטעים קצרים (segments) של כמה שניות כל אחד, ויוצרים קובץ playlist (.m3u8) שמפרט את סדר הקטעים. הנגן מוריד את ה-playlist, ואז מושך קטע-קטע — מה שמאפשר התחלה מהירה ומעבר חלק בין איכויות.

הבהרה חשובה לפני שממשיכים: "HLS על R2" הוא דפוס DIY/קהילתי, לא מוצר turnkey של Cloudflare. אין דף תיעוד רשמי של "HLS on R2". אתה מרכיב אותו בעצמך משלושה חלקים סטנדרטיים: ffmpeg לפיצול, R2 לאחסון, ונגן HLS (כמו hls.js או Safari native) בצד הלקוח. זה עובד מצוין — אבל אתה האחראי לכל חלק, וזה בדיוק החיסרון מול Stream המנוהל שראינו זה עתה.

נתחיל בפיצול. ffmpeg הופך קובץ MP4 ל-package של HLS בפקודה אחת. ה--codec: copy אומר "אל תקודד מחדש, רק חתוך" — מהיר וללא איבוד איכות (בהנחה שהמקור כבר ב-codec תקין שהדפדפן מבין):

ffmpeg -i input.mp4 -codec: copy -start_number 0 -hls_time 6 -hls_list_size 0 -f hls playlist.m3u8

זה ייצר playlist.m3u8 ושורה של קבצי .ts (הקטעים). ה--hls_time 6 קובע קטעים של ~6 שניות, ו--hls_list_size 0 אומר "שמור את כל הקטעים ב-playlist" (חשוב ל-VOD, וידאו לפי דרישה, להבדיל מ-live שבו רק החלון האחרון נשמר).

עכשיו מעלים ל-R2 — וכאן המלכודת מספר אחת של כל הפרק. כל קובץ צריך content-type נכון. ה-.m3u8 חייב להיות application/vnd.apple.mpegurl (או application/x-mpegURL), וקובצי ה-.ts חייבים להיות video/mp2t. אם R2 מגיש את ה-playlist כ-application/octet-stream (ברירת המחדל לקובץ לא מוכר), הנגן נכשל בשקט — בלי שגיאה ברורה, פשוט מסך שחור. זו הסיבה השכיחה ביותר ל"למה הווידאו לא מתנגן", ואנשים מבזבזים עליה שעות כי הם בודקים את הנגן ולא את ה-headers.

# העלה את ה-playlist עם content-type מפורש:
wrangler r2 object put bkt/playlist.m3u8 --file ./playlist.m3u8 --content-type application/vnd.apple.mpegurl

# העלה כל קטע .ts עם content-type של video/mp2t:
wrangler r2 object put bkt/playlist0.ts --file ./playlist0.ts --content-type video/mp2t

יש גם אופציית ביניים נחמדה: Media Transformations (ה-prefix /cdn-cgi/media/). אם המקור שלך כבר ב-R2 ואתה רק צריך clip קצר, thumbnail או resize — לא צריך ffmpeg בכלל. URL אחד עושה את העבודה, עם 5,000 פעולות ייחודיות בחודש חינם (הקצאה נפרדת מ-Image Transforms, כזכור):

https://your-zone.com/cdn-cgi/media/mode=video,time=5s,duration=5s,width=500,height=500,fit=crop,audio=false/https://pub-xxxx.r2.dev/clip.mp4
# mode=frame ל-thumbnail סטטי בזמן time=Ns. 5,000 פעולות ייחודיות/חודש חינם.

מה אתה מוותר עליו כשבוחרים HLS self-host על פני Stream? שלושה דברים מרכזיים: transcoding אוטומטי (ב-DIY אתה מקודד בעצמך עם ffmpeg, ואם אתה רוצה כמה איכויות אתה מייצר master playlist ידנית), signed URLs מובנים (אתה תצטרך לבנות הגנה משלך, למשל דרך Worker עם Turnstile מפרק 5), ו-per-viewer analytics. בתמורה — $0 egress, שליטה מלאה, ואפס נעילה לספק. עבור וידאו קצר, מדריכים, או תוכן ידוע מראש, ה-trade הזה כמעט תמיד משתלם.

Real-time וידאו: Cloudflare Realtime (לשעבר Calls) — WebRTC SFU

החלק האחרון של מחסנית ה-media הוא הכי מרשים: וידאו בזמן אמת. Cloudflare Realtime — שם חדש למה שהיה Cloudflare Calls — נותן לך תשתית WebRTC מלאה לבניית video chat, שידורים חיים ו-multiplayer. חשוב לדעת את שני השמות: רוב המדריכים הקיימים עדיין מדברים על "Calls", אז כשתחפש דוגמאות תמצא אותן תחת השם הישן. התמחור זהה לחלוטין בין השמות.

הלב של המוצר הוא SFU — Selective Forwarding Unit. כדי להבין למה זה קריטי: ב-WebRTC נאיבי (peer-to-peer), כל משתתף שולח את הווידאו שלו ישירות לכל שאר המשתתפים. בחדר של 5 אנשים, כל דפדפן שולח 4 זרמים ומקבל 4 — זה מתפוצץ מהר, גם ברוחב פס וגם ב-CPU של המכשיר. SFU פותר את זה: כל משתתף שולח זרם אחד לשרת, והשרת מעביר אותו לכל השאר. הדפדפן שולח פעם אחת — והחדר יכול לגדול בלי שכל מכשיר יקרוס.

וכאן מודל החיוב הופך את זה לחינמי-בפועל: inbound תמיד חינם (כל מה שנכנס ל-Cloudflare לא עולה), ו-1,000 GB egress בחודש חינם לפני שמתחיל חיוב כלשהו. במונחי וידאו אמיתי: ב-500kbps, 1,000 GB מספיקים ל-כ-4,400 שעות של וידאו יוצא בחודש. מעבר לזה — $0.05 לכל GB. בשביל רוב האפליקציות שתבנה, אתה לעולם לא תיגע בקיר הזה. ה-SFU וה-TURN מחויבים יחד תחת חיוב Realtime המאוחד.

הארכיטקטורה הבטוחה בנויה משלושה חלקים. ל-App שלך יש App ID (ציבורי-למחצה) ו-App Secret (חייב להישאר בצד שרת). ה-Worker משמש כ-signaling/auth proxy דק: הוא קורא ל-Connection API עם ה-App Secret בכותרת Authorization, יוצר sessions ומנהל tracks. ה-דפדפן עושה את חילופי המדיה האמיתיים ישירות מול ה-SFU — הוא מקבל מה-Worker רק session/track IDs ו-SDP, לעולם לא את ה-Secret.

הנה דפוס מייצג של ה-Worker. שים לב היטב: ה-host וה-header המדויקים הם high-confidence אך לא אומתו verbatim מול ה-doc העדכני ביותר. ה-host ההיסטורי (תקופת Calls) הוא https://rtc.live.cloudflare.com/v1, וה-header הסטנדרטי הוא Authorization: Bearer <App Secret> — אבל אמת מול ה-OpenAPI/quickstart הרשמי לפני production. זו דוגמה מייצגת, לא copy-paste מובטח:

// דוגמה מייצגת — אמת host + header מול ה-OpenAPI הרשמי לפני production!
// ה-App Secret נשמר עם: wrangler secret put REALTIME_APP_SECRET
const BASE = "https://rtc.live.cloudflare.com/v1"; // אמת מול ה-OpenAPI!

export default {
  async fetch(request, env) {
    const appId = env.REALTIME_APP_ID;
    const auth = { "Authorization": `Bearer ${env.REALTIME_APP_SECRET}` };

    // יצירת session חדש מול ה-SFU (ה-Secret נשאר כאן, בצד שרת):
    const res = await fetch(`${BASE}/apps/${appId}/sessions/new`, {
      method: "POST",
      headers: { ...auth, "content-type": "application/json" },
    });
    const session = await res.json();

    // הדפדפן יקבל רק את ה-sessionId ו-SDP — לעולם לא את ה-Secret:
    return Response.json({ sessionId: session.sessionId });
  },
};

נקודות המפתח של ה-API (כדפוס, אמת את הנתיבים): POST /apps/{appId}/sessions/new יוצר session, POST /apps/{appId}/sessions/{sessionId}/tracks/new מפרסם או מנוי ל-tracks, ו-PUT .../renegotiate מבצע renegotiation של ה-SDP כשמשהו משתנה (למשל מישהו נכנס או יצא מהחדר). ה-Worker עוטף את אלה, והדפדפן רק קורא ל-Worker — כך ה-Secret נשאר מוסתר.

פרויקט: חדר וידאו real-time ב-$0 (Realtime SFU + Worker signaling)

זה הפרויקט שסוגר את הפרק: חדר וידאו אמיתי שבו שני (או יותר) משתתפים רואים זה את זה — הכול ב-$0, על תשתית Cloudflare בלבד. אנחנו מרכיבים שלושה חלקים שכבר הכרנו: Realtime SFU כשרת המדיה, Worker כ-signaling proxy שמחזיק את ה-Secret, ו-Static Assets (frontend WebRTC) שרץ בדפדפן.

זרימת ה-signaling היא הלב. הדפדפן קורא ל-getUserMedia כדי לקבל גישה למצלמה ולמיקרופון, יוצר offer של SDP, ושולח אותו ל-Worker. ה-Worker — עם ה-App Secret בצד שלו — יוצר session מול ה-SFU, מפרסם את ה-track של המשתמש, ומחזיר את ה-answer ואת ה-track IDs לדפדפן. כדי לראות משתתפים אחרים, הדפדפן מבקש מה-Worker להירשם (subscribe) ל-tracks שלהם. כל חילופי המדיה עצמם — הזרמים בפועל — קורים ישירות בין הדפדפן ל-SFU; ה-Worker רק מתווך את ההסכמות (ה-SDP).

החלוקה הזו היא מה שהופך את זה גם בטוח וגם זול. בטוח — כי ה-Secret נשאר ב-Worker, והדפדפן מקבל רק IDs ו-SDP (חזרה למלכודת מהסקשן הקודם: אם תשים Secret ב-frontend, פתחת חור שמישהו ינצל). זול — כי ה-inbound חינם וה-egress רחב מאוד, אז חדרים רצים אלפי שעות לפני שתשלם משהו.

בוא נעשה את חשבון ה-egress, כי הוא מה שמוכיח את ה-$0. נניח חדר של 3 משתתפים ב-500kbps. כל משתתף מקבל את הזרמים של שני האחרים = 1Mbps יוצא אליו, ולשלושתם ~3Mbps egress מה-SFU. 1,000 GB = 8,000,000 megabits. ב-3Mbps, זה כ-740 שעות חדר בחודש (8,000,000 ÷ 3 ÷ 3600). כלומר חדר של 3 אנשים יכול לרוץ עשרות שעות ביום, כל חודש, ב-$0. אפליקציה קטנה לעולם לא תתקרב לקיר — וזה לפני שספרנו שה-inbound כולו חינם.

ל-frontend אתה משתמש ב-WebRTC API הסטנדרטי של הדפדפן (RTCPeerConnection), שמדבר עם ה-Worker שלך לצורך ה-signaling. את ה-frontend אתה מגיש כ-Static Assets מאותו Worker — אין צורך בשרת נפרד או ב-hosting אחר. הקוד המדויק של ה-SDP exchange תלוי בפרטי ה-API של Realtime, ולכן (כמו שהדגשנו) אמת את ה-host וה-endpoints מול ה-quickstart הרשמי לפני שאתה מסתמך עליהם ב-production.

// frontend WebRTC skeleton (illustrative — verify against official quickstart)
const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });
const pc = new RTCPeerConnection();
stream.getTracks().forEach(t => pc.addTrack(t, stream));
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
// POST ה-SDP offer ל-Worker (לעולם לא ישירות ל-SFU — הוא מחזיק את ה-Secret)
const { answer } = await fetch('/signaling/session', {
  method: 'POST',
  headers: { 'content-type': 'application/json' },
  body: JSON.stringify({ sdp: offer.sdp, type: offer.type }),
}).then(r => r.json());
await pc.setRemoteDescription({ type: 'answer', sdp: answer });

תקציב media משולב: מה אפשר לדחוס ב-$0 ועל מה מתחיל החיוב

סגרנו ארבעה רכיבי media — תמונות, screenshots, וידאו ו-real-time — וכולם רצים על אותה תשתית. עכשיו השאלה המעשית: כשאתה מרכיב אותם באפליקציה אחת, איזה limit נופל ראשון? זו השאלה החשובה ביותר בתכנון תקציב, כי הקיר הראשון הוא זה שיעצור אותך, ולא משנה כמה רחבים האחרים.

הנה המפה המלאה. שים לב במיוחד לשתי ההקצאות הנפרדות של ה-transforms — זו הטעות החוזרת ביותר:

איזה limit נופל ראשון? כמעט תמיד Browser Run. 10 דקות ביום זה התקציב הצר ביותר במחסנית — ~85 צילומים, מתאפס יומית. תמונות (5,000 וריאנטים) ו-Realtime (4,400 שעות) הם רחבים מאוד, ו-R2 (10GB) מספיק להמון מקורות. אז אם האפליקציה שלך נשענת על screenshots, שם תרגיש את הלחץ הראשון — ולכן ה-cache ב-KV הוא לא אופציונלי אלא הכרחי. אם, לעומת זאת, אתה מעלה הרבה תמונות בוריאנטים דינמיים, ה-5,000 של Image Transforms עלול ליפול לפני הכול — תלוי איך תכננת את הוריאנטים.

ההחלטה הגדולה שמתגבשת מכל הפרק היא managed מול self-host. R2 + Transforms + ffmpeg + Realtime SFU נותנים לך מחסנית media שלמה ב-$0 — בתמורה לכך שאתה מרכיב ומתחזק את החלקים. Stream + Cloudflare Images נותנים pipeline מנוהל — בתמורה לתשלום. הבחירה אינה אידיאולוגית: היא תלויה בנפח, בזמן הפיתוח שלך, ובכמה הפיצ'רים המנוהלים (transcoding, signed URLs, analytics) באמת קריטיים לך. שתי המסגרות בפרק נותנות לך את הכלים להחליט בכל מקרה לגופו — לא לפי אופנה אלא לפי המספרים שלך.

עצה אחרונה לתכנון: אל תנסה להחליט הכול מראש. הגישה הנכונה ל-vibe coder היא להתחיל self-host ב-$0, ולעבור ל-managed רק כשמשהו קונקרטי שובר. בנה את ה-CDN תמונות על R2+Transforms; אם תגלה שאתה צריך וריאנטים אינסופיים שחורגים מ-5,000, אז תשקול Cloudflare Images. בנה וידאו על HLS+R2; אם תמצא שאתה מבזבז שעות על transcoding ידני ואתה צריך adaptive ladder אוטומטי, אז Stream שווה. הקיר הראשון שתפגוש יגיד לך בדיוק איפה כדאי לשלם — וזה הרבה יותר חכם מלשלם מראש על pipeline מנוהל שאולי לא תצטרך. ה-$0 הוא לא רק חיסכון, הוא גם הדרך הזולה ביותר ללמוד מה הפרויקט שלך באמת צריך.

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

• הפעלתי Transformations על ה-zone (Images → Transformations) לפני שבניתי URL של /cdn-cgi/image/.
• בניתי URL של Image Transform עם width, quality ו-format=auto, ואימתתי resize.
• אימתתי ב-DevTools ש-format=auto מגיש image/webp או image/avif בדפדפן עדכני.
• העליתי מקור ל-R2 עם --content-type מפורש, ובניתי CDN תמונות מ-R2 + Transform URL.
• אימתתי cf-cache-status: HIT בקריאה שנייה — ההמרה לא נספרה שוב.
• הבנתי שה-free tier סופר המרות ייחודיות, ותכננתי סט קבוע של וריאנטים מתחת ל-5,000.
• התקנתי @cloudflare/puppeteer והגדרתי טבלת [browser] עליונה ב-wrangler.toml.
• הרצתי Browser Run עם wrangler dev --remote (לא dev רגיל) וקיבלתי screenshot.
• חישבתי את התקציב היומי האמיתי (~60–120 צילומים) והוספתי cache ב-KV לפי hash של URL.
• אימתתי שקריאה שנייה ל-screenshot API חוזרת מ-cache בלי לפתוח דפדפן.
• פיצלתי וידאו ל-HLS עם ffmpeg והעליתי עם content-type נכון (.m3u8 = application/vnd.apple.mpegurl, .ts = video/mp2t).
• אימתתי שהווידאו HLS מתנגן בדפדפן מ-R2 ב-$0 egress.
• יצרתי App ב-Realtime ושמרתי את ה-App Secret עם wrangler secret put — לא בקוד.
• בניתי חדר וידאו עם Worker signaling ואימתתי שני feeds בשתי כרטיסיות.
• מילאתי טבלת תקציב media משולב וזיהיתי איזה limit נופל ראשון באפליקציה שלי.