คำตอบสั้น: ใช้ Workers เป็นค่าเริ่มต้นสำหรับงานที่ไม่มี state เช่น API, SSR และ middleware ใช้ Durable Objects เมื่อต้องการจุดเดียวที่เป็นเจ้าของความจริงต่อหนึ่งคีย์ เช่น ห้องแชท ตัวนับสต็อก หรือ rate limiter ที่ต้องแม่นยำ ใช้ Containers เมื่อคุณมีไบนารีหรือไลบรารีที่รันบน Workers ไม่ได้ ใช้ Workflows เมื่องานมีหลายขั้นและแต่ละขั้นต้องทนต่อความล้มเหลวได้เอง และใช้ Browser Rendering ซึ่งปัจจุบันเอกสารเรียกว่า Browser Run เมื่อต้องการเบราว์เซอร์จริง เช่น สร้าง PDF จับภาพหน้าจอ หรือครอวล์หน้าที่เรนเดอร์ด้วย JavaScript
คนส่วนใหญ่ที่มาเจอ Cloudflare ครั้งแรกเข้าใจว่า Workers คือ compute ตัวเดียวที่มี แล้วพยายามยัดทุกอย่างเข้าไปในนั้น ผลคือโค้ดที่ฝืนทำงานต้านขีดจำกัดของรันไทม์ตลอดเวลา ความจริงคือ Cloudflare มี compute อยู่ห้าแบบ แต่ละแบบตอบโจทย์คนละข้อ
บทความนี้ไม่ได้จะเขียนเอกสารของ Cloudflare ซ้ำ มันมีหน้าที่เดียวคือช่วยให้คุณเลือก primitive ที่ถูกตัวสำหรับงานตรงหน้า ทุกหัวข้อจึงจบด้วยว่าควรใช้เมื่อไหร่และไม่ควรใช้เมื่อไหร่ ราคาและขีดจำกัดทั้งหมดมาจากเอกสารทางการ ณ กรกฎาคม 2026
Workers: ค่าเริ่มต้น
Workers คือ isolate ที่รันโค้ด JavaScript หรือ WebAssembly ของคุณ ไม่มี cold start แบบคอนเทนเนอร์ และสมบูรณ์ที่สุดสำหรับงานที่ตอบคำขอ HTTP เร็ว ๆ
การคิดเงินที่เปลี่ยนวิธีคิด
Workers Paid ราคา 5 ดอลลาร์ต่อเดือน รวม 10 ล้านคำขอและ 30 ล้าน CPU-มิลลิวินาที ส่วนเกินคิด 0.30 ดอลลาร์ต่อล้านคำขอ และ 0.02 ดอลลาร์ต่อล้าน CPU-มิลลิวินาที ข้อที่สำคัญที่สุดคือ Workers คิดเงินตาม CPU time ไม่ใช่ wall-clock time เวลาที่โค้ดของคุณนั่งรอฐานข้อมูล รอ API ภายนอก หรือรอ I/O จะไม่ถูกคิดเงิน สำหรับทีมที่ชินกับโมเดลคิดเงินของ Lambda ที่เอา duration คูณ memory นี่คือความต่างที่เปลี่ยนการออกแบบไปเลย เราลงรายละเอียดไว้ใน Cloudflare Workers vs AWS Lambda
ขีดจำกัดที่ต้องรู้ก่อนเขียนโค้ดบรรทัดแรก
หน่วยความจำคือ 128 MB ต่อ isolate เท่ากันทั้งแผน Free และ Paid และเพิ่มไม่ได้ ไม่มีระบบไฟล์ การเชื่อมต่อขาออกพร้อมกันได้สูงสุด 6 รายการ ขนาด bundle หลัง gzip คือ 3 MB บนแผน Free และ 10 MB บนแผน Paid ส่วน CPU ต่อการเรียกหนึ่งครั้งอยู่ที่ 30 วินาทีโดยค่าเริ่มต้น ขยายได้สูงสุด 5 นาทีบนแผน Paid และ 10 มิลลิวินาทีบนแผน Free
ที่มักสับสนคือ wall time ของ Worker ที่ตอบคำขอ HTTP นั้นไม่มีเพดานตราบที่ไคลเอนต์ยังต่ออยู่ แต่ Cron Triggers, Queue Consumers และ Durable Object Alarms มีเพดาน wall time ที่ 15 นาทีต่อการเรียกหนึ่งครั้ง นี่คือเหตุผลที่งาน batch กลางคืนที่เคยเขียนไว้ใน cron ของเซิร์ฟเวอร์ตัวเดิมมักย้ายมาตรง ๆ ไม่ได้ ต้องหั่นงานออกเป็น Workflow หรือ Queue
ใช้เมื่อ งานเป็น request-response ไม่มี state ค้างระหว่างคำขอ เช่น API endpoint, SSR, การ routing, การตรวจ auth, การแปลงภาพ หรืองาน CPU สั้น ๆ ที่ทำซ้ำมหาศาล
อย่าใช้เมื่อ คุณต้องการหน่วยความจำเกิน 128 MB ต้องเขียนไฟล์ลงดิสก์ ต้องรันไบนารี native ต้องเชื่อมต่อขาออกมากกว่า 6 รายการพร้อมกัน หรือต้องรักษา state ที่กำหนดลำดับระหว่างคำขอ
Durable Objects: จุดเดียวที่เป็นเจ้าของความจริง
หัวใจของ Durable Objects คือการรับประกันว่า หนึ่งคีย์จะมี instance ที่มีอำนาจเพียงตัวเดียวในโลก คำขอทุกคำขอที่ส่งมาที่คีย์นั้นจะวิ่งเข้า instance เดียวกันเสมอ นั่นแปลว่าคุณได้ serialisation โดยไม่ต้องมี lock ภายนอก ไม่ต้องมี Redis และไม่มี race condition ระหว่าง read กับ write
นี่คือเหตุผลที่ rate limiter ที่แม่นยำจริง ตัวนับสต็อกที่ขายเกินไม่ได้ ห้องแชท เอกสารที่แก้ร่วมกันได้ หรือเซสชันเกมแบบเรียลไทม์ ล้วนเหมาะกับ Durable Objects หากคุณเคยใช้ Redis ทำงานเหล่านี้ เราเทียบทั้งสองตัวไว้ใน Durable Objects vs Redis
WebSocket Hibernation เปลี่ยนรูปเศรษฐศาสตร์
Durable Objects คิดค่า duration ตาม wall-clock ตราบที่ object ยังทำงานหรือยังอยู่ในหน่วยความจำโดยจำศีลไม่ได้ ซึ่งหมายความว่าการเปิด WebSocket ค้างไว้เฉย ๆ จะคิดเงินตลอดเวลา WebSocket Hibernation API แก้ปัญหานี้โดยปล่อยให้ object จำศีลได้ขณะที่คอนเน็กชันยังเปิดอยู่ เอกสาร Cloudflare ยกตัวอย่างที่ต่างกันอย่างชัดเจน แอปแชทที่เปิด WebSocket ค้างไว้ตลอดเวลาอยู่ที่ประมาณ 138 ดอลลาร์ต่อเดือน ขณะที่แอปแบบเดียวกันที่ใช้ Hibernation อยู่ที่ประมาณ 10 ดอลลาร์ต่อเดือน
ขีดจำกัดที่ต้องออกแบบรอบคือ object หนึ่งตัวรองรับทราฟฟิกได้ตาม soft limit ราว 1,000 คำขอต่อวินาที ถ้าคีย์เดียวของคุณร้อนเกินกว่านั้น คุณต้อง shard คีย์ออกเอง Durable Objects ไม่ได้ช่วยคุณเรื่องนี้
ใช้เมื่อ คุณต้องการ state ที่เขียนแล้วอ่านถูกต้องเสมอต่อหนึ่งคีย์ เช่น ห้องแชท สต็อกสินค้าต่อ SKU rate limiter ต่อผู้ใช้ เซสชันเกม หรือ agent ที่มีความจำ
อย่าใช้เมื่อ งานของคุณเป็น read-heavy และกระจายอยู่แล้วโดยธรรมชาติ การบังคับทุกคำขอให้วิ่งผ่าน object เดียวจะสร้างคอขวดขึ้นมาโดยไม่จำเป็น ให้ใช้ KV หรือ R2 แทน
Containers: สำหรับโค้ดที่รันบน Workers ไม่ได้
Containers คือทางออกเมื่อคุณมี ffmpeg, Pandas, LaTeX, ImageMagick หรือไลบรารี native ที่คอมไพล์เป็น WebAssembly ไม่ได้ คุณแพ็กกเจเป็น image แล้วเรียกจาก Worker
การคิดเงินคิดทุก 10 มิลลิวินาทีที่คอนเทนเนอร์รันอยู่จริง และหยุดคิดเงินเมื่อ instance หลับ ทำให้ scale to zero ได้จริง บนแผน Workers Paid มีโควตารวม 25 GiB-hours สำหรับหน่วยความจำ 375 vCPU-นาที และ 200 GB-hours สำหรับดิสก์ ส่วนเกินคิดเพิ่มตามอัตราที่ประกาศ
สิ่งที่คนมักมองข้ามคือ instance ที่ใหญ่ที่สุดคือ standard-4 ที่ 4 vCPU, 12 GiB และดิสก์ 20 GB นี่ไม่ใช่เครื่องที่จะรันโมเดลภาษาขนาดใหญ่ หรืองาน in-memory analytics ที่กิน RAM เยอะ นอกจากนี้ image รวมทั้งหมดต่อบัญชีเก็บได้ 50 GB และคอนเทนเนอร์แต่ละตัวมี Durable Object ของตัวเอง แปลว่าคุณจ่ายทั้งค่า Workers และค่า Durable Objects ด้วย
ใช้เมื่อ คุณมีโค้ดเดิมที่ต้องการระบบไฟล์ ไบนารี native หรือหน่วยความจำมากกว่า 128 MB เช่น การแปลงวิดีโอ การประมวลผลไฟล์ขนาดใหญ่ หรือโค้ด Python ที่มี dependency เยอะ
อย่าใช้เมื่อ งานของคุณเขียนเป็น JavaScript อยู่แล้วและรันบน Workers ได้ การย้ายมา Container จะทำให้คุณจ่ายแพงขึ้นและได้ cold start กลับมาโดยไม่ได้อะไรเพิ่ม
Workflows: durable execution สำหรับงานที่เจ๊งกลางคันไม่ได้
Workflows คือคำตอบเมื่องานของคุณมีหลายขั้น แต่ละขั้นอาจล้มได้ และคุณต้องการให้มันกลับมาทำต่อจากจุดที่ล้ม ไม่ใช่เริ่มใหม่ทั้งกระบวนการ แต่ละ step จะ persist ผลลัพธ์เอง รีไทรเอง และเดินต่อจากจุดที่ค้างไว้
ตัวเลขที่กำหนดการออกแบบ บนแผน Workers Paid มีได้ 10,000 step ต่อ instance เป็นค่าเริ่มต้น ปรับขึ้นได้ถึง 25,000 ผลลัพธ์ต่อ step แบบไม่สตรีมจำกัดที่ 1 MiB ขนาด payload ของ event ก็ 1 MiB เช่นกัน state ที่เก็บต่อ instance ได้ถึง 1 GB บนแผน Paid และ step.sleep หลับได้นานสุด 365 วัน
จุดที่สำคัญคือ instance ที่อยู่ในสถานะ waiting ไม่นับรวมในโควตา concurrency แปลว่าคุณมี Workflow หลับหรือรออีเวนต์นับล้านตัวพร้อมกันได้ มีเฉพาะ instance ที่ running เท่านั้นที่นับโดยมีเพดาน 50,000 instance ต่อบัญชีบนแผน Paid
การคิดเงินกำลังจะเปลี่ยน
เดิม Workflows คิดเงินเหมือน Workers คือคำขอและ CPU time บวกค่า storage ที่ 1 GB-month รวมอยู่แล้ว บวก 0.20 ดอลลาร์ต่อ GB-month ส่วนเกิน แต่เมื่อ 7 กรกฎาคม 2026 Cloudflare ประกาศเพิ่มการคิดเงินต่อ step โดยจะเริ่มเก็บเงินค่า step และ storage ไม่เร็วกว่าวันที่ 10 สิงหาคม 2026 โดยแผน Paid จะรวม 500,000 step ต่อเดือน จากนั้นคิด 0.80 ดอลลาร์ต่อทุก 100,000 step ที่เกินมา ส่วนแผน Free รวม 3,000 step ต่อวัน
ความหมายเชิงออกแบบเปลี่ยนไปด้วย การซอย step เล็ก ๆ หลายสิบขั้นเพื่อความสวยงามจะเริ่มมีต้นทุนหลังสิงหาคม 2026 ให้ตัดสินขอบเขต step ตามหน่วยงานที่ต้องรีไทรอิสระจริง ไม่ใช่ตามบรรทัดโค้ด
ใช้เมื่อ กระบวนการมีหลายขั้น ล้มกลางคันไม่ได้ ต้องรีไทร หรือต้องรออะไรบางอย่างนานเป็นนาที ชั่วโมง หรือวัน เช่น saga ของการสั่งซื้อ การ onboarding หรือไปป์ไลน์ ETL
อย่าใช้เมื่อ งานเป็นคำขอเดียวจบในหนึ่งครั้ง หรือเป็น fire-and-forget ที่ล้มแล้วไม่เสียหาย ใช้ Worker ธรรมดาหรือ Queue จะง่ายกว่าและถูกกว่า
Browser Rendering (ปัจจุบันเรียกว่า Browser Run)
เมื่อคุณต้องการเบราว์เซอร์ Chromium จริง ๆ เช่น สร้าง PDF จาก HTML จับภาพหน้าจอ ทำ OG image หรือครอวล์หน้าที่เรนเดอร์ด้วย JavaScript นี่คือบริการที่ต้องใช้ เอกสารปัจจุบันเรียกมันว่า Browser Run
มีสองโหมด โหมด Quick Actions เช่น endpoint สำหรับ screenshot, PDF หรือ markdown คิดเงินเฉพาะ browser hours ส่วนโหมด Browser Sessions ที่คุณคุม Puppeteer, Playwright หรือ CDP เอง คิดทั้ง browser hours และจำนวนเบราว์เซอร์ที่รันพร้อมกัน
บนแผน Workers Paid คุณได้ 10 browser hours ต่อเดือน หลังจากนั้นคิด 0.09 ดอลลาร์ต่อชั่วโมง และได้ 10 เบราว์เซอร์พร้อมกัน เกินกว่านั้นคิด 2.00 ดอลลาร์ต่อเบราว์เซอร์ โดยเพดานสูงสุดที่ 120 เบราว์เซอร์พร้อมกันต่อบัญชี เบราว์เซอร์จะปิดตัวเองหลังไม่มีการใช้งาน 60 วินาที ขยายได้ถึง 10 นาทีด้วย keep_alive
สาเหตุหลักที่ค่าใช้จ่ายบานปลายคือการไม่เรียก browser.close() เบราว์เซอร์ที่ไม่ถูกปิดจะเปิดค้างจนครบ timeout และนับเวลานั้นเป็น browser hours ทั้งหมด ให้ครอบโค้ดด้วย try/finally เสมอ
ใช้เมื่อ คุณต้องการ DOM ที่เรนเดอร์แล้วจริง เช่น สร้างใบกำกับภาษี PDF จากเทมเพลต HTML หรือดึงข้อมูลจากหน้าที่เนื้อหาสร้างด้วย JavaScript
อย่าใช้เมื่อ คุณแค่ต้องการ HTML ธรรมดา การดึงด้วย fetch แล้ว parse เองถูกกว่าหลายสิบเท่า การเปิดเบราว์เซอร์เต็มตัวเพื่อดึงหน้านิ่งคือการเผาเงิน
ขีดจำกัดที่ต้องจำ (ราคา ณ กรกฎาคม 2026)
| บริการ | คิดเงินตาม | ขีดจำกัดสำคัญ | เพดานเวลา |
|---|---|---|---|
| Workers | คำขอ + CPU time | หน่วยความจำ 128 MB, 6 การเชื่อมต่อขาออก, ไม่มีไฟล์ซิสเท็ม | CPU 30 วินาที ขยายได้ถึง 5 นาที |
| Durable Objects | คำขอ + duration (wall-clock) | หนึ่ง instance ต่อคีย์, soft limit ราว 1,000 คำขอ/วินาทีต่อ object | HTTP/RPC ไม่จำกัด, alarm 15 นาที |
| Containers | ทุก 10 มิลลิวินาทีที่รันจริง | สูงสุด 4 vCPU, 12 GiB, ดิสก์ 20 GB | หลับเมื่อไม่มีงาน (scale to zero) |
| Workflows | คำขอ + CPU + storage + step (ส.ค. 2026) | 10,000 step ต่อ instance, ผลต่อ step 1 MiB | ต่อ step ไม่จำกัด, sleep ได้ถึง 365 วัน |
| Browser Rendering | browser hours + เบราว์เซอร์พร้อมกัน | 10 ชั่วโมง + 10 เบราว์เซอร์รวมในแผน Paid | ปิดอัตโนมัติที่ 60 วินาที |
ตารางตัดสินใจ
| ถ้าคุณต้องการ | ให้ใช้ |
|---|---|
| API endpoint หรือ SSR ที่ตอบเร็ว | Workers |
| นับสต็อกหรือตัดสินใจที่ต้องไม่ซ้ำซ้อน | Durable Objects |
| WebSocket แบบห้องหรือ presence | Durable Objects พร้อม WebSocket Hibernation |
| Rate limiting ที่ต้องแม่นยำจริง | Durable Objects |
| รัน ffmpeg, Pandas, LaTeX หรือไบนารี native | Containers |
| ต้องการหน่วยความจำมากกว่า 128 MB หรือระบบไฟล์ | Containers |
| กระบวนการหลายขั้นที่ต้องรีไทรและต่อจากจุดที่ล้มได้ | Workflows |
| งานที่ต้องรอนานเป็นชั่วโมงหรือวัน | Workflows (step.sleep) |
| งานตามตารางเวลาที่จบภายใน 15 นาที | Cron Trigger บน Worker |
| งานตามตารางเวลาที่นานกว่า 15 นาที | Cron Trigger ที่สตาร์ต Workflow |
| สร้าง PDF หรือ screenshot | Browser Rendering |
| ครอวล์หน้าที่เรนเดอร์ด้วย JavaScript | Browser Rendering |
| ดึง HTML ธรรมดาจำนวนมาก | Workers + fetch (อย่าเปิดเบราว์เซอร์) |
ตัวอย่างจริง: ระบบสั่งซื้อของอีคอมเมิร์ซ
สมมติว่าคุณกำลังสร้างระบบสั่งซื้อที่มีงานห้าอย่าง การแม็ปมันลงบน primitive ทั้งห้าตัวจะเป็นแบบนี้
หนึ่ง การรับคำขอสั่งซื้อ เป็น Worker ธรรมดา ตรวจ auth ตรวจความถูกต้องของข้อมูล แล้วส่งต่อ คำขอนี้ตอบภายในหนึ่งหน่วยมิลลิวินาที จึงไม่มีเหตุผลให้ใช้อะไรอื่น
สอง การตัดสต็อก เป็น Durable Object หนึ่งตัวต่อหนึ่ง SKU นี่คือจุดที่ห้ามประนีประนอม ถ้าคุณตัดสต็อกใน D1 หรือ Postgres โดยไม่มี lock ที่ถูกต้อง คุณจะขายเกินในวันที่มีทราฟฟิกสูง Durable Object หนึ่งตัวต่อ SKU ทำให้คำขอทุกคำขอของ SKU นั้นเข้าคิวเดียว จึงตัดสต็อกได้ถูกเสมอ
สาม กระบวนการหลังการสั่งซื้อ เป็น Workflow ตัดเงิน ออกใบกำกับภาษี สร้างเลขพัสดุ แจ้งคลังสินค้า ส่งอีเมล และหนึ่งวันถัดมาส่งคำถามความพึงพอใจ ขั้นตอนสุดท้ายนี้เขียนเป็น step.sleep สองวัน ซึ่งเป็นสิ่งที่ cron 15 นาทีทำไม่ได้ และ instance ที่นอนรออยู่ไม่นับเข้าโควตา concurrency
สี่ การออกใบกำกับภาษี PDF เป็น Browser Rendering ที่เรนเดอร์เทมเพลต HTML ที่คุณดูแลอยู่แล้วออกมาเป็น PDF แล้วเขียนลง R2
ห้า การประมวลผลภาพสินค้า เป็น Container ที่รันไลบรารีประมวลผลภาพเดิมของทีม ซึ่งเขียนด้วย Python และคอมไพล์เป็น WebAssembly ไม่ได้
สังเกตว่าไม่มี primitive ตัวไหนทำงานของอีกตัวได้ดี ถ้าคุณพยายามเขียน saga ทั้งหมดใน Worker เดียวโดยใช้ setTimeout คุณจะเจอเพดาน CPU หรือเจอการที่ Worker จบกลางคันแล้วเสีย state ทั้งหมด
เมื่อไหร่ที่ทางเลือกอื่นดีกว่า
มีหลายกรณีที่ compute ของ Cloudflare ไม่ใช่คำตอบที่ดีที่สุด
ถ้างานของคุณเป็นงาน CPU หนักที่รันนานเกิน 5 นาทีต่อครั้ง หรือต้องการ GPU สำหรับเทรนโมเดล งานเหล่านี้ควรอยู่บน EC2, GKE หรือคลัสเตอร์ของคุณเอง Containers ของ Cloudflare จำกัดที่ 4 vCPU และ 12 GiB ซึ่งเล็กกว่าอินสแตนซ์ขนาดกลางของคลาวด์ใหญ่อื่นมาก
ถ้าทีมของคุณมี Kubernetes ที่ดูแลดีอยู่แล้ว มีคนที่เข้าใจมัน และมี tooling ที่เชื่อมกันอยู่ การย้ายมา Cloudflare เพียงเพื่อ latency อาจไม่คุ้มกับต้นทุนการเปลี่ยนผ่าน และสิ่งที่ต้องยอมรับคือคุณกำลังผูกกับโฮสต์รายเดียว
และถ้าการทำงานของคุณคือการอ่านหนักจากฐานข้อมูลเชิงวิเคราะห์ขนาดหลายสิบกิกะไบต์ การเอา compute มาอยู่ใกล้ข้อมูลนั้นสมเหตุสมผลกว่าการดึงข้อมูลมาที่ edge
สรุป
คำถามที่ควรถามไม่ใช่ Cloudflare ดีกว่าหรือไม่ แต่คืองานชิ้นนี้มี state หรือไม่ ต้องการความสอดคล้องแบบจุดเดียวหรือไม่ ทนนานเกิน 15 นาทีหรือไม่ และต้องการไบนารี native หรือไม่ ตอบสี่คำถามนี้ได้ คุณก็จะรู้ว่าต้องใช้ primitive ตัวไหน
Cipher ออกแบบและพัฒนาระบบบน Cloudflare Developer Platform ให้ธุรกิจในประเทศไทย และรับประเมินสถาปัตยกรรมที่มีอยู่เพื่อดูว่างานส่วนไหนควรอยู่บน primitive ตัวไหน
คำถามที่พบบ่อย
Workers กับ Durable Objects ต่างกันอย่างไร
Worker หนึ่งคำขออาจรันที่ไหนก็ได้ในเครือข่าย จึงไม่เหมาะกับ state ที่ต้องสอดคล้องกัน ส่วน Durable Object รับประกันว่าหนึ่งคีย์มี instance ที่มีอำนาจเพียงตัวเดียวในโลก ทำให้คำขอที่กระทบ state เดียวกันถูก serialise โดยอัตโนมัติ เหมาะกับห้องแชท ตัวนับสต็อก หรือ rate limiter
Workflows คิดเงินอย่างไร
เดิม Workflows คิดเงินเหมือน Workers คือคำขอกับ CPU time บวกค่า storage ที่ 1 GB-month รวมอยู่ จากนั้น 0.20 ดอลลาร์ต่อ GB-month เมื่อ 7 กรกฎาคม 2026 Cloudflare เพิ่มการคิดเงินต่อ step โดยจะเริ่มเก็บเงินไม่เร็วกว่าวันที่ 10 สิงหาคม 2026 โดยแผน Paid รวม 500,000 step ต่อเดือน จากนั้นคิด 0.80 ดอลลาร์ต่อทุก 100,000 step
เมื่อไหร่ควรใช้ Containers แทน Workers
ใช้ Containers เมื่อโค้ดของคุณต้องการสิ่งที่ Workers ให้ไม่ได้ ได้แก่ ระบบไฟล์ ไบนารี native หรือหน่วยความจำมากกว่า 128 MB ตัวอย่างที่พบบ่อยคือ ffmpeg, Pandas, LaTeX หรือ ImageMagick ถ้าโค้ดเป็น JavaScript อยู่แล้วและรันบน Workers ได้ การย้ายมา Container มีแต่ทำให้จ่ายแพงขึ้นและได้ cold start กลับมา
Cron Trigger ของ Workers รันได้นานสุดเท่าไหร่
Cron Triggers มีเพดาน wall time ที่ 15 นาทีต่อการเรียกหนึ่งครั้ง เช่นเดียวกับ Queue Consumers และ Durable Object Alarms ถ้างาน batch ของคุณนานกว่านั้น ให้ใช้ cron เป็นตัวสตาร์ต Workflow แล้วให้ Workflow ทำงานจริงแทน
Browser Rendering กับ Browser Run คืออะไร
เป็นบริการเดียวกัน เอกสารของ Cloudflare ปัจจุบันเรียกบริการนี้ว่า Browser Run บนแผน Workers Paid คุณได้ 10 browser hours ต่อเดือน หลังจากนั้นคิด 0.09 ดอลลาร์ต่อชั่วโมง สาเหตุที่พบบ่อยที่สุดของค่าใช้จ่ายบานปลายคือการไม่เรียก browser.close() ทำให้เบราว์เซอร์ค้างจนครบ timeout
