GetNotes Tools
denoland/celld
Tool นี้คืออะไร
celld เป็น daemon แบบโอเพนซอร์สที่ช่วยให้คุณรัน Cloudflare Workers และ Durable Objects แบบ self-hosted บนเครื่องของคุณเอง โดยใช้ Object Storage เป็นแหล่งความจริงเดียว ทำให้เกิดระบบกระจายศูนย์ที่ทนทานและปรับขนาดได้โดยไม่ต้องมี control plane หรือ consensus เหมาะสำหรับนักพัฒนาที่ต้องการความยืดหยุ่นในการโฮสต์และจัดการแอปพลิเคชันแบบกระจายศูนย์ด้วยสถาปัตยกรรมที่ออกแบบมาเพื่อลดความขัดแย้ง.
ข้อมูลโปรเจกต์
ดาว
3.1K
Forks
98
License
Apache-2.0
อัปเดต GitHub ล่าสุด
5 ส.ค. 2569
เพิ่มใน GetNotes
17 ส.ค. 2569
Repository
denoland/celld
รูปแบบ
Ecosystem
Rust
แปลและเรียบเรียงโดย AI
เนื้อหาฉบับภาษาไทย
ใช้อ่านเพื่อทำความเข้าใจเบื้องต้น โปรดตรวจสอบรายละเอียดสำคัญกับเอกสารต้นฉบับด้านล่าง
celld
Durable Objects แบบ Self-hosted และกระจายศูนย์
celld เป็น daemon แบบโอเพนซอร์สที่รัน Cloudflare Workers และ Durable Objects บนเครื่องของคุณเอง แต่ละอ็อบเจกต์เป็นฐานข้อมูล SQLite ของตัวเอง celld ระบุอ็อบเจกต์ด้วยชื่อและจำลองข้อมูลไปยัง bucket ที่คุณเป็นเจ้าของ bucket สามารถเป็นแบบ S3-compatible หรือ Google Cloud Storage ก็ได้ โหนดต่างๆ ประสานงานกันผ่าน bucket นั้นเพียงอย่างเดียว โดยไม่มี control plane และไม่มี consensus เนื่องจากทุกอ็อบเจกต์เป็นฐานข้อมูลขนาดเล็กของตัวเอง แอปพลิเคชันจึงถูกแบ่งส่วน (shard) โดยโครงสร้าง — ความขัดแย้งและความล้มเหลวแบบ blast-radius ของฐานข้อมูลที่ใช้ร่วมกันถูกออกแบบมาเพื่อป้องกัน ไม่ใช่แค่จัดการ เซลล์ที่ไม่มีโหนดใดถืออยู่จะอยู่ในสถานะไม่ทำงาน (inactive) และเซลล์ที่ไม่ทำงานนี้แทบไม่มีค่าใช้จ่ายเลย เรียนรู้เพิ่มเติมได้ที่ celld.dev หรืออ่าน เอกสารประกอบ
วิธีการทำงาน
โหนด celld ทุกตัวจะฝัง V8 และรัน Wrangler bundles กลุ่มโหนด (fleet) ใช้ bucket เดียวกัน ซึ่งประกอบด้วยการปรับใช้ (deployments), สถานะของเซลล์ (cell state) และบันทึกการเป็นเจ้าของขนาดเล็ก bucket สามารถเป็นแบบ S3-compatible หรือ Google Cloud Storage ก็ได้ การใช้ Object-storage compare-and-swap ช่วยให้มั่นใจว่ามีโหนดเพียงหนึ่งเดียวเท่านั้นที่เป็นเจ้าของเซลล์ในแต่ละครั้ง โดยไม่จำเป็นต้องมี membership protocol, failure detector หรือ consensus service
celld จำลองฐานข้อมูล SQLite ของแต่ละเซลล์ไปยัง bucket อย่างต่อเนื่อง เมื่อเซลล์ย้าย หรือเมื่อเซลล์ที่ไม่ทำงานเริ่มทำงาน เจ้าของใหม่จะกู้คืนฐานข้อมูลนั้นและดำเนินการต่อ bucket เป็นแหล่งความจริงที่คงทนถาวร; โหนดต่างๆ สามารถถูกแทนที่ได้
การติดตั้ง
ตัวติดตั้งจะดาวน์โหลดไบนารี celld (สามารถตรวจสอบแหล่งที่มาได้ด้วย gh attestation verify):
curl -fsSL https://celld.dev/install.sh | shเพิ่ม ~/.local/bin ลงใน PATH ของคุณ หากตัวติดตั้งร้องขอ
โปรเจกต์ Worker ที่ปรับใช้ด้วย celld deploy จำเป็นต้องมี esbuild อยู่ใน PATH; ส่วนโปรเจกต์ที่เป็น asset-only ไม่จำเป็น
ตัวติดตั้งจะเก็บแต่ละรีลีสไว้ใต้ ~/.local/lib/celld/releases และชี้ symlink หนึ่งตัวไปยังรีลีสปัจจุบัน หากต้องการลบ celld ให้ลบ symlink และรีลีสต่างๆ:
rm `which celld` && rm -rf ~/.local/lib/celldคอนเทนเนอร์
อิมเมจรีลีสประกอบด้วยไบนารี celld และเผยแพร่สำหรับ Linux x86-64 และ ARM64:
docker run --rm ghcr.io/denoland/celld --versionคงสถานะภายในของรันไทม์และส่งผ่านสภาพแวดล้อมข้อมูลรับรอง AWS มาตรฐาน:
docker volume create celld-state
docker run --rm --network host \
-e AWS_ACCESS_KEY_ID \
-e AWS_SECRET_KEY \
-e AWS_SESSION_TOKEN \
-e CELLD_WATCH=/var/lib/celld/state \
-v celld-state:/var/lib/celld \
ghcr.io/denoland/celld \
--bucket s3://my-cells-bucket \
--endpoint https://ACCOUNT.r2.cloudflarestorage.com \
--region auto \
--listen 0.0.0.0:8080 \
--internal-listen 10.0.0.12:8081 \
--advertise node-a.internal:8081ละทิ้ง --endpoint และ --region สำหรับ AWS S3 เปิดเผยพอร์ต 8080 ผ่าน load balancer และเก็บพอร์ต 8081 ไว้ในเครือข่ายส่วนตัว
การรัน
celld ใช้ AWS credential chain มาตรฐาน ปรับใช้ไปยัง S3-compatible bucket จากนั้นเริ่ม celld โดยใช้ bucket เดียวกัน:
celld deploy . \
--bucket s3://my-cells-bucket
celld \
--bucket s3://my-cells-bucket \
--listen 0.0.0.0:8080 \
--internal-listen 10.0.0.12:8081 \
--advertise 10.0.0.12:8081ใช้ --endpoint สำหรับบริการ S3-compatible อื่นๆ และ --region เมื่อไม่สามารถอนุมานได้ bucket ที่ขึ้นต้นด้วย gs:// จะเลือก Google Cloud Storage จากนั้น celld จะใช้ Cloud Storage XML API พร้อม generation preconditions การยืนยันตัวตนใช้ Application Default Credentials celld จะปฏิเสธ --endpoint ของ S3 สำหรับ bucket ที่เป็น gs:// และจะละเว้น storage region:
celld deploy . --bucket gs://my-cells-bucket
celld --bucket gs://my-cells-bucket --listen 0.0.0.0:8080 \
--internal-listen 10.0.0.12:8081 --advertise 10.0.0.12:8081กลุ่มโหนด (fleet) รันแอปพลิเคชันเดียว และทุกโหนดจะโหลดการปรับใช้ที่คอมมิตสำเร็จล่าสุดจาก deploy/current.json รัน celld --help เพื่อดูคำสั่งทั้งหมด อ็อบเจกต์การปรับใช้ใช้ประเภทที่ระบุไว้ใน crates/celld/protocol.rs celld deploy จะเรียกใช้ esbuild จาก PATH สำหรับโค้ด Worker, ยอมรับ Wrangler config subset ที่รองรับ—รวมถึง static assets ที่ปรับใช้ร่วมกันหรือ asset-only—และเขียนอ็อบเจกต์เหล่านั้นโดยตรง ทุกโหนดจะค้นหาเจ้าของและ peers จาก bucket leases; ไม่มีบริการบัญชีหรือบริการเข้าร่วม
Peer HTTP และ operator API ใช้ internal listener วางทุก advertised address บนเครือข่ายส่วนตัวที่เชื่อถือได้ หรือ overlay ที่เข้ารหัส เช่น WireGuard หรือ Tailscale อย่าเผยแพร่ internal port celld จะปฏิเสธ public IP โดยตรง เว้นแต่คุณจะระบุ --unsafe-public-advertise advertised address ที่ระบุอย่างชัดเจนต้องมี internal-listener address ที่ระบุอย่างชัดเจน celld ไม่สามารถตรวจสอบ hostname หรือ translated port ได้ ดังนั้นคุณต้องกำหนดเส้นทาง advertised address ไปยัง internal listener โหนดปัจจุบันตัวแรกจะสร้าง fleet/peer-auth.json ใน bucket คำขอ peer ทั้งหมดจะถูกกำหนดเวอร์ชันโปรโตคอล, ผูกกับเนื้อหา (body-bound), ยืนยันตัวตนด้วย HMAC, จำกัดเวลา (clock-bounded) และป้องกันการเล่นซ้ำ (replay-protected) ด้วย fleet secret นั้น ถือว่าการเข้าถึง bucket และข้อมูลรับรองของมันเป็นการเข้าถึงระดับผู้ดูแลระบบของ fleet
การดำเนินการกลุ่มโหนด (fleet)
celld diagnose จะแจกแจง node lease ทั้งหมดโดยค่าเริ่มต้น จากนั้นทำการตรวจสอบโดยตรงแบบลงนาม (signed direct probe) กับ peer ที่ใช้งานอยู่แต่ละตัว:
celld diagnose --bucket s3://my-cells-bucketรายงานจะยังคงตรวจสอบต่อไปหลังจากความล้มเหลวแต่ละครั้ง และแยกแยะระหว่างบันทึกที่หมดอายุ, advertise address ที่ผิดรูปแบบหรือไม่ปลอดภัย, peer ที่เข้าถึงไม่ได้ และโปรโตคอลที่ไม่เข้ากัน นอกจากนี้ยังแสดงตัวอย่าง resident-cell, WebSocket, RSS, CPU, file-descriptor, pressure และ shedding ของแต่ละโหนด ส่งตัวเลือก --peer NODE_ID หนึ่งตัวหรือมากกว่าเพื่อจำกัดการตรวจสอบ
กำหนดขีดจำกัด resident-cell แบบ hard limit บนแต่ละโหนดที่โหลด:
CELLD_MAX_RESIDENT_CELLS=1000 \
celld --bucket s3://my-cells-bucket --listen 0.0.0.0:8080 \
--internal-listen 10.0.0.12:8081 --advertise node-a.internal:8081celld เปิดใช้งานเกณฑ์หน่วยความจำที่ 80% ของหน่วยความจำที่ใช้งานได้โดยค่าเริ่มต้น ตั้งค่า CELLD_MAX_RSS_MB เพื่อเปลี่ยนเกณฑ์ หรือตั้งค่าเป็น 0 เพื่อปิดใช้งาน memory pressure
เอกสารโปรเจกต์
อ่านเอกสารต้นฉบับ
README วิธีติดตั้ง วิธีใช้งาน และข้อกำหนดจาก repository ต้นฉบับ
celld
Self-hosted, distributed Durable Objects.
celld is an open-source daemon that runs Cloudflare Workers and Durable Objects on your own machines. Each object is its own SQLite database. celld addresses an object by name and replicates it to a bucket that you own. The bucket can be S3-compatible or Google Cloud Storage. The nodes coordinate through that bucket alone, with no control plane and no consensus. Because every object is its own small database, applications shard by construction — the contention and blast-radius failures of one shared database are designed out, not managed. A cell that no node holds is inactive, and an inactive cell costs nearly nothing. Learn more at celld.dev or read the documentation.
How it works
Every celld node embeds V8 and executes Wrangler bundles. The fleet shares
one bucket, which contains deployments, cell state, and small ownership
records. The bucket can be S3-compatible or Google Cloud Storage. Object-storage compare-and-swap ensures that exactly one node owns a
cell at a time, without a membership protocol, failure detector, or consensus
service.
celld continuously replicates each cell's SQLite database to the bucket. When a cell moves, or when an inactive cell activates, its new owner restores that database and resumes execution. The bucket is the durable source of truth; nodes are replaceable.
Install
The installer downloads the celld binary (provenance is verifiable with
gh attestation verify):
curl -fsSL https://celld.dev/install.sh | shPut ~/.local/bin on your PATH if the installer asks you to.
Worker projects deployed with celld deploy need
esbuild on PATH; asset-only projects do not.
The installer keeps each release under ~/.local/lib/celld/releases and points
one symlink at the current one. To remove celld, delete the symlink and the
releases:
rm `which celld` && rm -rf ~/.local/lib/celldContainer
The release image contains the celld binary and is published for Linux
x86-64 and ARM64:
docker run --rm ghcr.io/denoland/celld --versionPersist the runtime's local state and pass the standard AWS credential environment through:
docker volume create celld-state
docker run --rm --network host \
-e AWS_ACCESS_KEY_ID \
-e AWS_SECRET_ACCESS_KEY \
-e AWS_SESSION_TOKEN \
-e CELLD_WATCH=/var/lib/celld/state \
-v celld-state:/var/lib/celld \
ghcr.io/denoland/celld \
--bucket s3://my-cells-bucket \
--endpoint https://ACCOUNT.r2.cloudflarestorage.com \
--region auto \
--listen 0.0.0.0:8080 \
--internal-listen 10.0.0.12:8081 \
--advertise node-a.internal:8081Drop --endpoint and --region for AWS S3. Expose port 8080 through the load
balancer, and keep port 8081 on the private network.
Run it
celld uses the standard AWS credential chain. Deploy to an S3-compatible bucket, then start celld against the same bucket:
celld deploy . \
--bucket s3://my-cells-bucket
celld \
--bucket s3://my-cells-bucket \
--listen 0.0.0.0:8080 \
--internal-listen 10.0.0.12:8081 \
--advertise 10.0.0.12:8081Use --endpoint for another S3-compatible service and --region when it
cannot be inferred. A gs:// bucket selects Google Cloud Storage. celld then
uses the Cloud Storage XML API with generation preconditions. Authentication
uses Application Default Credentials. celld rejects an S3 --endpoint for a
gs:// bucket, and it ignores the storage region:
celld deploy . --bucket gs://my-cells-bucket
celld --bucket gs://my-cells-bucket --listen 0.0.0.0:8080 \
--internal-listen 10.0.0.12:8081 --advertise 10.0.0.12:8081A fleet runs one application, and every node loads its
latest successfully committed deployment from deploy/current.json. Run
celld --help for the complete command line.
Deployment objects use the documented types in crates/celld/protocol.rs. celld deploy invokes esbuild from PATH for Worker code, accepts the supported
Wrangler config subset—including co-deployed or asset-only static
assets—and writes those objects directly. Every node discovers owners and
peers from bucket leases; there is no account or join service.
Peer HTTP and the operator API use the internal listener. Put every advertised
address on a trusted private network or an encrypted overlay such as WireGuard
or Tailscale. Do not publish the internal port. celld rejects a literal public
IP unless you supply --unsafe-public-advertise. An explicit advertised
address requires an explicit internal-listener address. celld cannot verify a
hostname or a translated port, so you must route the advertised address to the
internal listener. The first current node creates fleet/peer-auth.json in the
bucket. All peer requests are
protocol-versioned, body-bound, HMAC-authenticated, clock-bounded, and
replay-protected with that fleet secret. Treat access to the bucket and its
credentials as fleet administrator access.
Operate a fleet
celld diagnose enumerates every node lease by default, then performs a signed
direct probe of each live peer:
celld diagnose --bucket s3://my-cells-bucketThe report keeps checking after an individual failure and distinguishes
expired records, malformed or unsafe advertise addresses, unreachable peers,
and incompatible protocols. It also prints each node's coarse resident-cell,
WebSocket, RSS, CPU, file-descriptor, pressure, and shedding sample. Pass one
or more --peer NODE_ID options to restrict the check.
Set a hard resident-cell limit on each loaded node:
CELLD_MAX_RESIDENT_CELLS=1000 \
celld --bucket s3://my-cells-bucket --listen 0.0.0.0:8080 \
--internal-listen 10.0.0.12:8081 --advertise node-a.internal:8081celld enables a memory threshold at 80% of the available memory by default. Set
CELLD_MAX_RSS_MB to change the threshold, or set it to 0 to disable memory
pressure shedding. celld measures the memory that the cells hold, and not the
resident set size of the process. The two differ, because the memory allocator
keeps some freed pages instead of returning them to the operating system.
Shedding a cell cannot return those pages, so a threshold on the resident set
size holds a node in pressure after the node gives every cell back. The /state
route reports both numbers.
celld also applies an absolute cap to the resident set size of the process. The cap is 95% of the available memory. It protects the node when the allocator holds memory that shedding cannot return, because the operating system stops a process that uses more memory than the machine has. The node logs a warning when this cap applies.
The cap is a share of the machine, and celld does not derive it from the
threshold. A CELLD_MAX_RSS_MB at or above 95% of the available memory therefore reaches
the cap. The cap is then the effective limit. The node decides on its resident
set size, and celld reports this at startup. CELLD_MAX_RSS_MB=0
disables the threshold and the cap together. When celld cannot read the size of
the available memory, it applies a cap of 125% of an explicit threshold.
Under pressure, celld durably replicates and fences the least-recently used idle cells. It then publishes the cells as unowned without resetting their epochs. Those cells become inactive, and celld refuses to reacquire new unowned cells.
Each limit releases separately. The threshold releases when the memory in use falls to 80% of the threshold. The cap releases when the resident set size falls to 80% of the cap. A crossing of one limit therefore does not hold the node against the other.
A spare receives no assignment. It acquires a released cell through the same bucket protocol when normal traffic reaches it. celld does not shed a cell with active work or a live host WebSocket.
Contributions
Pull requests are disabled. Coding agents make it too easy to send a large, low-context change that costs maintainers more time than it saves. Thoughtful contributions are welcome; please understand the code, keep the patch focused, and respect the review time you are asking for.
Send a git format-patch attachment to ry@deno.com.
Contributor License Agreement: By emailing a patch, you certify that you have the right to submit it and assign to Deno Land Inc. all rights in the patch that you can assign. Where a right cannot be assigned, you grant Deno Land Inc. a perpetual, irrevocable, worldwide, royalty-free, transferable, sublicensable license to use, modify, combine, relicense, redistribute, or publish the patch, in whole or in part, with or without attribution.
License
See the limitations and security pages before operating a public fleet.
