แยกและยืนยันเว็บไซต์อิสระ

การแยกระบบหยุดการอัปเดตที่ CMS จัดการ ไม่ใช่การลบ CMS หรือข้อมูล คง installation เดิมไว้จนเจ้าของยอมรับผลแบบอิสระ สัญญาการแยกระบบ กำหนดสิ่งที่ส่งออก ส่วน เอกสารอ้างอิง API ของแบ็กเอนด์อิสระ เป็นเอกสาร API ของแบ็กเอนด์ที่สร้างเพียงชุดเดียว

สิ่งที่ต้องพร้อม

ใช้ซอร์ส snapshot ที่ตรวจแล้ว และระบุเว็บไซต์ รีโพซิทอรี published snapshot กับฐานข้อมูลปลายทาง อ่าน ตารางการยืนยันตัวตน GitHub การส่งมอบ commit ที่สร้างในเครื่องแบบที่ระบบจัดการใช้ App ที่ตั้งค่าไว้ npm run backend:deliver ใช้ device flow และหน้าผู้ดูแลสร้างซอร์สไม่ได้ (source_build_runtime_unavailable) npm run backend:generate ไม่ต้องมีข้อมูลรับรอง GitHub และไม่ดีพลอย

ก่อนดีพลอยใด ๆ ให้จัดการข้อจำกัดที่ทราบของระบบอิสระ การดีพลอยทุกครั้ง ทั้งแบบที่ระบบจัดการและแบบจากรีโพซิทอรีอย่างเดียว เขียน ACCESS_CONFIG เป็นการรวมกันของ digest ของ read token ที่ CMS ออกให้ซึ่ง commit ไว้ใน access/read-tokens.json กับ vars.ACCESS_CONFIG ใน wrangler.jsonc ของคุณ เมื่อไม่มีเลย จะเขียนรายการว่างที่ถูกต้อง ({ version: 1, siteId, tokens: [] }) route ที่ต้องใช้ read token จะปฏิเสธจนกว่าจะมี token ถูกส่งไป และการดีพลอยจะปฏิเสธค่าที่ Worker ใช้เริ่มทำงานไม่ได้ token ของ CMS ที่ถูกเพิกถอนยังคงถูกยอมรับจนกว่าคุณจะสร้างใหม่และดีพลอย การแยกตัวไม่ได้ลบ digest ที่ commit ไว้: ดู หยุดการเชื่อม CMS README ที่สร้างอาจยังอธิบายสัญญาเก่าแบบหนึ่งโมเดลและอ่านอย่างเดียว ความเข้ากันได้กับ edge ไม่ได้รับประกันแบบครอบคลุมสำหรับส่วนขยาย Prisma ที่เพิ่มเข้ามาหรือ route ที่สร้าง ให้ทำตาม เอกสารอ้างอิง API ฉบับปัจจุบัน ไม่ใช่ README ที่สร้างไว้ซึ่งล้าสมัย และเก็บข้อมูลสำรองที่ตรวจแล้ว

สร้างและตรวจทาน

รูปแบบเรียก CLI แบบรวมในรีโพซิทอรีต้นทางคือ:

npm run backend:deliver -- --site <site-id> --repo <owner/name> --source <cms.db> --dest <output-directory> --db <target.db>

นี่เป็นการเขียนและดีพลอยที่ต้องได้รับอนุญาตจากผู้ดูแล ไม่ใช่คำสั่งตรวจอย่างเดียว ตั้ง environment ที่จำเป็นและยืนยันเจ้าของรีโพซิทอรีก่อนใช้ ตรวจไฟล์ generated, owned และ shared โมเดลที่ครอบคลุม คำแปล ความสัมพันธ์ และ published snapshot คง src/owned/ และการตั้งค่า dependency ร่วมไว้ การย้ายสื่อเป็นการดำเนินการแยกที่ต้องเลือกอย่างชัดเจน และต้องเข้าถึงต้นทางและปลายทาง ไซต์ที่อ้างถึงไฟล์ส่วนตัวยังต้องมีกลุ่มต้นทางส่วนตัวและบัคเก็ตปลายทางส่วนตัวของตัวเอง (ชื่อ EXIT_MEDIA_SOURCE_PRIVATE_ และ EXIT_MEDIA_DESTINATION_PRIVATE_ ใน exit --help) หากไม่มี การรันจะถูกปฏิเสธก่อนคัดลอกอะไร และไฟล์ส่วนตัวจะไม่ถูกเขียนลงบัคเก็ตสาธารณะเลย ผูกบัคเก็ตนั้นกับ Worker เป็น PRIVATE_FILES หากต้องการให้บริการด้วย npm run serve:local แทน ให้ตั้ง EXIT_MEDIA_DESTINATION_PRIVATE_DIRECTORY (ไดเรกทอรี absolute ที่มีอยู่ ใช้แทนบัคเก็ต) และเริ่มเซิร์ฟเวอร์ด้วย PRIVATE_FILES_DIRECTORY ที่ชี้ไปยังไดเรกทอรีนั้น ตราบใดที่ยังไม่ได้ตั้ง เซิร์ฟเวอร์จะตอบ 503 private_files_unavailable การสร้างอย่างเดียวไม่ได้ย้ายสื่อมาอยู่ในความดูแลของคุณ

ยืนยันคอมมิตที่สร้างอย่างแน่นอน

จากรีโพซิทอรีที่สร้าง ใช้ตัวติดตั้ง dependency ที่ตรวจสอบแล้วและคำสั่งตรวจที่มีอยู่ หลังดีพลอยที่ได้รับอนุญาต เก็บ API_BEARER_TOKEN ใน environment แล้วเรียก:

node scripts/install-dependencies.mjs
npm run typecheck
npm run build
npm run verify:media
npm run verify:deployment -- --origin 'https://site.example.com' --expect-commit <full-commit-sha>

verify:media ตรวจ snapshot และ projection ของหน้าที่คอมมิตแล้วหาการอ้างอิงสื่อที่ CMS เป็นเจ้าของ ไม่ใช่การทดสอบว่าไบต์ของสื่อพร้อมใช้งานจากระยะไกล verify:deployment ใช้ bearer token เทียบเนื้อหาที่ดีพลอยกับ snapshot ที่คอมมิตในทุกตารางที่มี route รวมถึงคอมมิตที่คาดไว้ ต้องผ่านสำหรับรีวิชันของรีโพซิทอรีที่คุณจะถือครอง ไม่ใช่แค่ตอบสถานะว่าระบบทำงาน

หากมี apps/site ที่สร้างไว้ ให้เรียก node scripts/install-dependencies.mjs apps/site, npm run --prefix apps/site check และ npm run --prefix apps/site build ด้วย เปิดหน้าที่ดีพลอยตัวอย่างในทุกภาษาที่ต้องใช้ และตรวจการเข้าถึงสื่อแยกต่างหาก การตรวจแบ็กเอนด์ที่ผ่านไม่ได้ยืนยันเว็บไซต์ด้านภาพ

Compatibility flag ของ Worker เว็บไซต์

route ของ Blog หน้าค้นหา และหน้าที่มีส่วน «รายการล่าสุด» ส่วน «ค้นหาในเว็บไซต์» หรือความคิดเห็นของผู้เยี่ยมชม อ่านเนื้อหาที่เผยแพร่จาก /v1 บน host ของเว็บไซต์เองตอนที่มี request Cloudflare ส่ง request ไปยัง host เดียวกันนี้ไปที่ public Worker ของ Dee Wan ก็ต่อเมื่อ Worker ของเว็บไซต์เปิด global_fetch_strictly_public เท่านั้น โปรเจกต์ใหม่ได้ flag นี้ใน apps/site/wrangler.jsonc ไฟล์นั้นเป็นของคุณ: Dee Wan เขียนไฟล์นี้เฉพาะเมื่อยังไม่มี และไม่เขียนทับเลย ส่วน «รายการล่าสุด» ในส่วนที่ใช้ร่วมกันที่แสดงในพื้นที่จะถูกตรึงไว้ตอนสร้างเว็บไซต์ และไม่อ่านอะไรตอน request โดยอ่านเฉพาะโมเดลสาธารณะ: โมเดลส่วนตัวจะแสดง collection_model_missing สรุปของรายการจะฝัง embed จากต้นทางที่ยอมรับไว้ตอนสร้างเว็บไซต์ การเปลี่ยนการมองเห็นของโมเดลหรือต้นทาง embed ต้องสร้างเว็บไซต์ใหม่

เมื่อเว็บไซต์ที่สร้างอ่านข้อมูลแบบนี้ (บันทึกไว้ใน apps/site/public-reads.json ที่สร้าง) การสร้างและการดีพลอยจะตรวจ apps/site/wrangler.jsonc ที่คุณมีอยู่ ถ้า compatibility_flags ไม่มี flag นี้ หรือไม่ใช่รายการของ string ทั้งสองขั้นตอนจะปฏิเสธด้วย public_fetch_compatibility_flag_required ระบุชื่อไฟล์และ flag และไม่เปลี่ยนแปลงอะไร ให้เพิ่ม "global_fetch_strictly_public" ลงใน compatibility_flags เองแล้วรันอีกครั้ง ทั้งการสร้างใน CMS และการดีพลอยอ่านไฟล์นี้เป็น JSONC จึงยอมรับคอมเมนต์และจุลภาคท้าย ไฟล์ที่ไม่ใช่ JSONC ที่ถูกต้องจะถูกปฏิเสธในแบบเดียวกัน เว็บไซต์ที่ไม่มี Blog ปิดการค้นหาในเว็บไซต์ และไม่มีหน้าที่ให้บริการตอน request ไม่มีข้อกำหนดนี้

หยุดการเชื่อม CMS

หลังยอมรับผลเท่านั้น จึงลบ build webhook ของ CMS และหยุดขอดีพลอยที่ CMS จัดการ ตรวจหรือปิด workflow รีโพซิทอรีที่ดึงนิยาม CMS เพื่อไม่ให้สร้างใหม่โดยไม่ตั้งใจ ตั้ง previewApiOrigin ของเว็บไซต์ที่สร้างเป็น null เมื่อไม่ใช้พรีวิวร่างจาก CMS แล้ว API อิสระและหน้าที่ build แบบ static ควรทำงานต่อได้เมื่อ CMS ใช้งานไม่ได้ แต่ route ใน สิ่งที่ยังขึ้นกับ Dee Wan ทำงานต่อไม่ได้ หากไม่มี public Worker ของ Dee Wan route ของ Blog และหน้าค้นหาจะตอบ 503 และส่วน «รายการล่าสุด» จะแสดงข้อผิดพลาดของมัน หากไม่มี intake Worker จะส่งความคิดเห็นและฟอร์มไม่ได้

read token ที่ CMS ออกให้ยังอยู่หลังการแยกตัว digest ของมันยังอยู่ใน access/read-tokens.json ที่ commit ไว้ และการดีพลอยจากรีโพซิทอรีอย่างเดียวทุกครั้งยังเพิ่มมันลงใน ACCESS_CONFIG การเพิกถอน token ใน CMS จะไม่ไปถึงรีโพซิทอรีนี้อีก ตรวจไฟล์นี้หลังแยกตัว หากต้องการเลิกยอมรับ token ให้ลบรายการของมัน หรือลบทั้งไฟล์ แล้ว commit และดีพลอย หากไม่มีไฟล์ การดีพลอยจะใช้เฉพาะ vars.ACCESS_CONFIG หรือรายการว่าง ไฟล์นี้อยู่ในโซน generated ดังนั้นขณะที่ยังเชื่อมต่ออยู่ ให้เพิกถอนใน CMS แล้วสร้างใหม่แทน

npm run backend:deliver เสนอแผนแยกหลังยืนยัน แต่ไม่ตัดการเชื่อมสุดท้ายให้โดยอัตโนมัติ อย่าลบข้อมูลต้นทาง bucket หรือข้อมูลรับรองในขั้นตอนนี้ สำหรับย้อนกลับ ให้เก็บคอมมิตที่ยอมรับก่อนหน้าและสถานะฐานข้อมูลกับสื่อที่ตรงกัน คอมมิตโค้ดเก่าเพียงอย่างเดียวไม่สร้างข้อมูลที่เปลี่ยนภายหลังกลับมา

ซอร์สอ้างอิง: scripts/exit-start.ts, backend/src/lib/graduate/regenerate-template.ts, backend/src/lib/graduate/deployment-files.ts และ backend/src/lib/graduate/media-custody.ts การดีพลอยจริงและการยอมรับด้านภาพยังเป็นความรับผิดชอบของผู้ดูแล

ก่อนปลดระวาง CMS

การแยกตัวยังคงให้การติดตั้ง Dee Wan ทำงานอยู่ การปลดระวางเป็นอีกขั้นตอนหนึ่ง ตรวจแต่ละข้อก่อน:

• API ที่สร้างขึ้น npm run verify:deployment ผ่านสำหรับคอมมิตที่คุณจะเก็บไว้ API อ่านเฉพาะฐานข้อมูล D1 ของตัวเอง
• หน้า static สร้างจาก pages.json ที่ commit ไว้ และไม่อ่านอะไรตอน request
• บล็อก การค้นหาในเว็บไซต์ รายการล่าสุด และความคิดเห็น เมื่อเว็บไซต์มีอย่างใดอย่างหนึ่ง apps/site/public-reads.json จะมี "requestTimePublicReads": true สิ่งเหล่านี้อ่าน /v1 จาก public Worker ของ Dee Wan ทุกครั้งที่มี request และจะหยุดทำงานเมื่อไม่มี Worker นั้น
• ฟอร์มและการส่งความคิดเห็น ส่งไปที่ /v1/interactions/* บน host ของคุณ ซึ่ง intake Worker ของ Dee Wan เป็นผู้ตอบ admin Worker ของ Dee Wan เป็นผู้ส่งต่อข้อมูลฟอร์ม
• พรีวิว previewApiOrigin เป็น null หรือคุณยอมรับว่า /preview จะหยุดทำงาน
• managed renderer หากคุณดีพลอย managed-renderer/ มันอ่าน /v1 ทุกครั้งที่มี request
• public Worker และ intake Worker รู้ว่า route ใดบน host ของคุณชี้ไปที่ Worker ของ Dee Wan: /v1/* และ /v1/interactions/*
• การครอบครองสื่อ npm run verify:media ผ่าน คือไม่มี projection ที่ commit ไว้ชี้ไปที่สื่อของ Dee Wan อีก หากไม่ได้ย้ายสื่อด้วย --media สื่อยังให้บริการโดย Dee Wan
• ปลั๊กอิน แบ็กเอนด์ที่สร้างขึ้นไม่มีโฮสต์ปลั๊กอิน บล็อกของปลั๊กอินใน rich text บน route ที่ให้บริการตอน request อ่านนิยามจาก /v1/_rich-blocks
• read token คุณตรวจ access/read-tokens.json แล้วตามที่อธิบายข้างต้น
• นิยาม หากต้องการสร้างใหม่ภายหลัง ให้ดึงและเก็บ definitions.json ไว้ขณะที่ CMS ยังทำงาน ดู การสร้างใหม่ในเครื่อง

การยืนยันตัวตนของอาร์ติแฟกต์ระหว่างการส่งมอบ

ก่อนส่งมอบ ให้ตรวจวิธี Better Auth ระดับแบ็กเอนด์และนโยบายสิทธิ์ตรงตัว โมเดลที่ไม่มีนโยบายใช้ service ส่งค่าผู้ให้บริการที่เลือกผ่านที่เก็บ secret ของเป้าหมาย หรือตัวแปร environment ARTIFACT_* ในเครื่อง การส่งมอบสร้าง BETTER_AUTH_SECRET ใหม่ให้อาร์ติแฟกต์ และเข้ารหัสค่าของรีโพซิทอรีโดยใช้ชื่อขึ้นต้น ARTIFACT_ secret ที่มีอยู่แล้วในเป้าหมายจะถูกเก็บไว้ ผู้ให้บริการที่ไม่ได้เลือกไม่ต้องมีข้อมูลรับรอง hostname เป้าหมายที่ตรวจแล้วกำหนด callback ของ OAuth และ magic link อย่าคัดลอกข้อมูลรับรองหรือบัญชีของ CMS

เก็บตาราง auth ของอาร์ติแฟกต์และประวัติ migration ของตารางเหล่านั้นไว้กับข้อมูลสำรองฐานข้อมูล ตารางเหล่านี้ไม่มี CRUD API ที่สร้างให้ การปิด auth ต้องใช้ destination ใหม่ การเปลี่ยน dependency หรือ method binding ต้องสร้างใหม่ การอ่านสาธารณะตรวจแบบ anonymous ส่วนการอ่านแบบ session-only ต้องมี session จริงของเป้าหมายที่ส่งผ่าน ARTIFACT_VERIFY_SESSION_COOKIE หากไม่มี session จะได้ verify_session_required ไม่ใช่ผลยืนยันที่ผ่าน ในการดีพลอยครั้งแรก ให้ตั้งค่าเริ่มต้นเป้าหมาย สมัครผ่าน auth route ของเป้าหมาย แล้วตรวจซ้ำด้วย session นั้น อย่าเก็บค่า session ในซอร์ส รายงาน หรือ ledger callback ของผู้ให้บริการ อีเมล และการยอมรับ deployment จริงต้องใช้สภาพแวดล้อมที่ได้รับอนุญาตของผู้นำไปใช้เอง

ขั้นตอนถัดไป

วางแผนวิธีกู้คืนฐานข้อมูลและสื่อด้วย การกู้คืนแบ็กเอนด์อิสระ

---

ยังไม่เปิดตัว (pre-MVP) และยังไม่มีเวอร์ชันเสถียร
คอมมิตซอร์สโค้ด: fe23db481c422b40e317b92fc98116b4c0c26a87 (มีการแก้ไขที่ยังไม่คอมมิต)
วันที่สร้างเอกสาร (UTC): 2026-10-18T09:22:34.630Z
คอมมิตสำหรับอัปเกรด: ระบุไม่ได้: มีการแก้ไขที่ยังไม่คอมมิต. บันทึกการเปลี่ยนแปลง