OpenWorkers – Cloudflare Workers แบบโฮสต์เองที่พัฒนาด้วย Rust

 (openworkers.com)
19 คะแนน โดย GN⁺ 2026-01-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • OpenWorkers คือ รันไทม์โอเพนซอร์ส สำหรับรัน JavaScript บน V8 ซึ่งทำให้สามารถสร้างเอดจ์คอมพิวติงบนโครงสร้างพื้นฐานของตนเองได้
  • รองรับ KV storage, PostgreSQL, สตอเรจที่เข้ากันได้กับ S3/R2, service bindings, environment variables และ secrets
  • รักษา ความเข้ากันได้ กับ Cloudflare Workers ในระดับสูง พร้อม Web API หลักอย่าง fetch, ReadableStream, crypto.subtle
  • สามารถโฮสต์เองได้อย่างง่ายดายด้วย แซนด์บ็อกซ์ V8 Isolate, การตั้งเวลาแบบ cron, และ การดีพลอยด้วย Docker Compose
  • เป็นโปรเจกต์ที่พัฒนามาราว 7 ปี โดยมีเป้าหมายเป็น สภาพแวดล้อมรัน JavaScript ที่ไม่ผูกกับผู้ให้บริการรายใด

ภาพรวม OpenWorkers

  • OpenWorkers เป็น รันไทม์ที่เข้ากันได้กับ Cloudflare Workers ซึ่งเขียนด้วย Rust และรัน JavaScript โดยใช้ V8 Isolate
    • ทำให้สามารถนำข้อดีของเอดจ์คอมพิวติงมาใช้ในสภาพแวดล้อมเซิร์ฟเวอร์ของตนเองได้
    • เปิดซอร์สให้ใช้งาน จัดจำหน่าย และแก้ไขได้อย่างอิสระ

ฟีเจอร์หลัก

  • เชื่อมต่อกับทรัพยากรภายนอกหลากหลายผ่านความสามารถด้าน Bindings
    • KV storage: รองรับ get, put, delete, list
    • เชื่อมต่อกับฐานข้อมูล PostgreSQL
    • รองรับ สตอเรจที่เข้ากันได้กับ S3/R2
    • รวมถึง service bindings, environment variables และการจัดการ secrets
  • รองรับ Web API
    • มี API มาตรฐานอย่าง fetch, Request, Response, ReadableStream
    • รวม crypto.subtle, TextEncoder/Decoder, Blob, setTimeout, AbortController

สถาปัตยกรรม

  • ระบบประกอบด้วย nginx proxy, dashboard, API, บริการล็อก, runner, PostgreSQL, NATS, scheduler เป็นต้น
    • แต่ละ runner จะรันโค้ดภายใน V8 Isolate โดยมีข้อจำกัดที่ CPU 100ms และ หน่วยความจำ 128MB
    • มี scheduler ในตัว ที่รองรับ ไวยากรณ์ cron แบบ 5–6 ฟิลด์
    • คง ความเข้ากันได้ด้านไวยากรณ์ กับ Cloudflare Workers

การโฮสต์เอง

  • สามารถดีพลอยได้ด้วยเพียง ฐานข้อมูล PostgreSQL เดียว และ ไฟล์ Docker Compose
    • รันได้ง่ายด้วยคำสั่ง git clone, ตั้งค่า .env, และ docker compose up
    • รวมขั้นตอน migration และการสร้างโทเค็นไว้ด้วย

เบื้องหลังการพัฒนา

  • เป็นโปรเจกต์ที่ผ่านกระบวนการพัฒนามาราว 7 ปี
    • ช่วงแรกทดลองทำ JS sandboxing ด้วย vm2 ก่อนพัฒนาต่อโดยได้แรงบันดาลใจจากโมเดล Cloudflare Workers
    • ผ่าน Deno-core และปัจจุบันเขียนใหม่บนพื้นฐาน rusty_v8
  • เป้าหมายคือการมอบ ประสบการณ์นักพัฒนา (DX) ระดับ Cloudflare Workers พร้อมสร้าง สภาพแวดล้อมรันบนเซิร์ฟเวอร์ของตนเองที่ไม่ผูกกับผู้ให้บริการรายใด
  • ในอนาคตมีแผนเพิ่มความสามารถ deterministic debugging ผ่าน การบันทึกและเล่นซ้ำการทำงาน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-01-02
ความคิดเห็นจาก Hacker News

  • แนวคิดในการนำ พลังของ edge computing มาไว้บนโครงสร้างพื้นฐานของตัวเอง น่าสนใจมาก
    แต่ก็รู้สึกว่าการ self-hosting ขัดกับแก่นแท้ของ edge computing อยู่พอสมควร
    นี่เป็นโมเดลที่เป็นไปได้เพราะผู้ให้บริการรายใหญ่อย่าง Cloudflare มี PoP (Point of Presence) มากกว่า 300 แห่งทั่วโลก
    แน่นอนว่าสามารถประกอบผู้ให้บริการรายเล็กที่ มีจริยธรรมมากกว่า เพื่อสร้างโครงสร้างคล้ายกันได้ แต่ต้องแลกกับความพยายามและความเสี่ยงที่สูงกว่ามาก

    • ก็สงสัยเหมือนกันว่าจำเป็นต้องมี PoP ถึง 300 แห่งจริงหรือไม่เพื่อให้ได้ข้อดีของโมเดล edge
      คิดว่าแค่มีสัก 10 แห่งในภูมิภาคหลัก ๆ ก็น่าจะพอแล้วหรือเปล่า
    • อยากรู้ว่าจะมีโมเดลที่ เครือข่ายโฮสต์แบบกระจายศูนย์ ร่วมมือกันเพื่อทำลายการผูกขาดของ Cloudflare ได้ไหม
      แต่ก็แอบกังวลว่าการประสานงานให้ปลอดภัยและเชื่อถือได้จะยากเกินไปหรือเปล่า

  • ปัญหาของโซลูชัน sandbox คือมันต้องให้ การรับประกันอย่างแข็งแกร่งว่าโค้ดจะไม่สามารถหนีออกจาก sandbox ได้
    การพิสูจน์สิ่งนี้ต้องอาศัยผลการทดสอบต่อสถานการณ์โจมตีหลากหลายแบบและเอกสารที่ละเอียดมาก
    แต่เอกสารระดับนี้หาได้ยากมาก และแทบหาเคสที่น่าเชื่อถือจริง ๆ ไม่ค่อยได้
    เพราะงั้นฉันจึงมักดูว่ามีกรณีที่บริษัทใหญ่ใช้งานจริงใน production และ ทีมความปลอดภัยเป็นผู้ดูแลรักษา หรือไม่

    • เห็นด้วยเหมือนกัน AI ช่วยเพิ่มประสิทธิภาพก็จริง แต่ในสภาพแวดล้อมที่ต้องการความปลอดภัยสูง คำว่า “เขียนใหม่บน rusty_v8 ด้วยความช่วยเหลือจาก Claude” ฟังแล้วน่ากังวลมากกว่า
    • หนึ่งในเหตุผลที่ Cloudflare Workers runtime ปลอดภัยคือพวกเขารักษา การซิงก์กับ V8 mainline อย่างเข้มข้นมาก
      ถึงขั้นนำ V8 release มาใช้ก่อน Chrome เสียอีก
    • V8 isolate ให้การแยกหน่วยความจำ และมีข้อจำกัด CPU (100ms) กับหน่วยความจำ (128MB)
      worker แต่ละตัวรันเป็น isolate ไม่ใช่ process แยก ทำให้คล้ายกับโมเดลของ Cloudflare
      แต่ถ้าต้องจัดการโค้ดจาก third party ที่ไม่อาจเชื่อถือได้ทั้งหมด ก็ควรแยกเพิ่มอีกชั้นด้วย container หรือ VM
      การ sandbox แบบนี้เน้นเรื่องการแยกทรัพยากรมากกว่าความปลอดภัย
    • คิดว่าการเรียกร้องการรับประกันที่สมบูรณ์แบบแบบนั้นไม่สมจริง
      การตรวจสอบความปลอดภัยระดับ “เราตรวจแล้วและปลอดภัย เชื่อเราได้” นั้นไม่เพียงพอ
    • Cloudflare ต้องถือว่ามีโค้ดผู้ใช้ที่อาจเป็นอันตราย จึงจำเป็นต้องมีความปลอดภัยของ sandbox
      แต่ในสภาพแวดล้อมแบบ self-hosting นั้นมีสิทธิ์เข้าถึงระบบอยู่แล้ว จึงไม่ค่อยต้องกังวลเรื่อง การหลุดออกจาก sandbox มากนัก

  • คิดว่าเป็นโปรเจ็กต์ที่ยอดเยี่ยม
    ถ้า workerd เป็นโอเพนซอร์สอยู่แล้ว ก็สงสัยว่าจุดต่างของ OpenWorkers คือการให้สภาพแวดล้อมแบบครบชุดใช่ไหม
    แล้วตัว runtime เองต่างกันอย่างไร หรือมีแผนเรื่อง managed service ในอนาคตหรือไม่

    • ความต่างหลักมีอยู่สามข้อ
      1️⃣ workerd ให้มาแค่ runtime แต่ OpenWorkers เป็นแพลตฟอร์มครบชุดที่รวม dashboard, API, scheduler, logs, bindings (KV, S3/R2, Postgres) มาด้วย
      2️⃣ workerd พัฒนาด้วย C++ ส่วน OpenWorkers ใช้ Rust + rusty_v8 จึงเรียบง่ายกว่าและแฮ็กปรับแต่งได้ง่ายกว่า
      3️⃣ ตอนนี้มีเวอร์ชัน managed อยู่แล้วที่ dash.openworkers.com และมี free tier ด้วย
      แต่ก็ออกแบบโดยให้ self-hosting เป็นพลเมืองชั้นหนึ่ง

  • แก่นสำคัญของ Cloudflare Workers คือ การคิดค่าบริการตามฟังก์ชัน แต่ถ้าเป็น self-hosting สุดท้ายก็ต้องจัดหา hardware ล่วงหน้าอยู่ดี

    • ทุกวันนี้ก็ยังมีหลายบริษัทที่รันเซิร์ฟเวอร์ในดาต้าเซ็นเตอร์ของตัวเอง
      ไม่จำเป็นต้องเอาทุกอย่างไปจ้างภายนอกทั้งหมด และการมี ทางเลือกที่คล้ายกัน ก็นับว่าเป็นเรื่องดี
      ตัวเลือกแบบนี้ช่วยลดอุปสรรคในการนำไปใช้ได้

  • เมื่อก่อนเคยทำงานแยก deno_core ออกมาพอสมควร เลยเข้าใจได้ว่าทำไมถึงย้ายไปใช้ raw rusty_v8
    ใน deno_core มี โค้ดแบบ legacy อยู่มาก พอแก้ไขทีไรก็มักทำให้เทสต์พังบ่อย

    • ขอบคุณมาก! deno_core ยังเป็น codebase ที่ยอดเยี่ยมอยู่ และเรายังคงดูแลมันผ่าน openworkers-runtime-deno
      แต่เราเปลี่ยนมาใช้ rusty_v8 เพื่อควบคุมภายในของ runtime ได้ละเอียดขึ้น
      และมีแผนจะ เติมฟีเจอร์ที่ยังขาดกลับเข้าไป ใน deno runtime ภายหลัง

  • ถ้าเป็นโปรเจ็กต์ที่ช่วยลด vendor lock-in ก็สนับสนุนเต็มที่
    อยากให้บริการคลาวด์ถูกกดดันให้ตั้งราคาตามความเป็นจริงเสียที
    ตอนนี้แม้แต่ฟีเจอร์พื้นฐานอย่าง NAT ก็ยังคิดราคาแพงเกินไป
    แน่นอนว่าคลาวด์สะดวก แต่ปัญหาคือ ต้นทุนที่สูงเมื่อเทียบกับการทำเองแบบ DIY

    • Cloudflare Workers runtime เป็นโอเพนซอร์สอยู่แล้ว: cloudflare/workerd
    • ช่วงนี้ราคา RAM ที่สูงขึ้นทำให้กังวลว่าการ self-hosting จะยิ่งยากขึ้นไหม
      ถ้าบริษัทใหญ่กว้านซื้อทรัพยากรไปหมด คนทั่วไปก็อาจโฮสต์เองได้ยากขึ้น
    • คำพูดที่ว่า NAT มีค่าใช้จ่าย ‘แพงกว่าฟรี’ ฟังดูน่าสนใจดี
      แต่ในความเป็นจริงแล้ว หลายประเทศมี ต้นทุนการดูแลระบบเองสูงกว่า
      เพราะมันไม่ได้จบแค่การติดตั้ง แต่ยังมีค่าคนดูแลและค่ามอนิเตอร์ระบบที่สูงพอสมควร

  • น่าจะดีถ้าเอกสารระบุให้ชัดว่าตอนนี้ยังมีฟีเจอร์ไหนที่ใช้ไม่ได้หรือมี roadmap อย่างไร

    • เป็นข้อเสนอที่ดีมาก! ฟีเจอร์ที่ยังไม่ได้ทำตอนนี้คือ Durable Objects, WebSockets, HTMLRewriter และ cache API
      ลำดับถัดไปคือ ฟีเจอร์บันทึก/เล่นซ้ำการทำงานสำหรับดีบัก และจะเพิ่มส่วน roadmap ลงในเอกสารด้วย

  • ไดอะแกรมสถาปัตยกรรมแบบ ASCII บน Pixel + Firefox ดูเพี้ยน
    ไดอะแกรมแบบข้อความมีเสน่ห์ก็จริง แต่ในทางปฏิบัติ การเผยแพร่เวอร์ชันที่คอมไพล์เป็นภาพ น่าจะใช้งานได้จริงกว่า

    • ขอบคุณที่แจ้ง! เราเพิ่มเวอร์ชัน ASCII แบบย่อสำหรับมือถือแล้วเพื่อแก้ปัญหานี้
    • บน iPhone 11 Safari ของฉันมันเรนเดอร์ได้สมบูรณ์แบบ

  • เป็นไอเดียผลิตภัณฑ์ที่ยอดเยี่ยมทั้งในเชิงเทคนิคและเชิงโครงสร้าง
    โดยเฉพาะ โมเดลที่นำโปรเจ็กต์โอเพนซอร์สของผู้ให้บริการรายใหญ่มาตอบแทนกลับด้วยโอเพนซอร์ส ที่ชอบมาก
    พูดอีกแบบคือ แทนที่พวกเขาจะหยิบโอเพนซอร์สไปทำเชิงพาณิชย์ ฝั่งเราก็นำโมเดลของพวกเขากลับมาเปิดเป็นโอเพนซอร์สแทน — คิดว่านี่แหละคือแนวทางที่ถูกต้อง

  • ดูเหมือนกระแส “จะเป็นอย่างไรถ้าเราโฮสต์คลาวด์ไว้บนคอมพิวเตอร์ของตัวเองโดยตรง?” กำลังกลับมาอีกครั้ง
    ช่วงนี้เห็น เทรนด์ self-hosting แบบนี้ในหลายที่
    วิดีโอบรรยาย ที่เกี่ยวข้องก็น่าสนใจ

    • แต่คิดว่าแบบนั้นเรียกว่า ‘คลาวด์’ ได้ยากแล้ว
      แก่นของคลาวด์คือ elasticity
      คือสามารถเพิ่มหรือลดจำนวนอินสแตนซ์ตามความต้องการ และจ่ายเท่าที่ใช้จริง
      self-hosting แม้จะมีเครื่องมือ deploy ที่สะดวก แต่สุดท้ายก็ต้องรับต้นทุนของทั้งเซิร์ฟเวอร์อยู่ดี
      ถ้าโหลดคงที่หรือคาดการณ์ได้ก็โอเค แต่ถ้าไม่ใช่ก็จะไม่มีประสิทธิภาพ
      (ถ้าจะเปรียบก็เหมือนความต่างระหว่างการนั่งรถบัสกับการเป็นเจ้าของรถตู้)
    • คุณค่าของ FaaS (Function-as-a-Service) ไม่ได้อยู่ที่คำว่า ‘คลาวด์’ แต่คือการให้ เฟรมเวิร์กที่ขับเคลื่อนด้วยอีเวนต์
      นักพัฒนาสามารถโฟกัสกับการเขียน event handler ได้ และถ้ามี queue หรือ durable execution รวมด้วยก็จะยิ่งทรงพลัง
      ท้ายที่สุด FaaS คือเครื่องมือระดับสูงที่ช่วย abstract โค้ด boilerplate ออกไป