---
doc-schema-version: 1
read_when:
    - คุณกำลังโฮสต์ OpenClaw สำหรับผู้ใช้หรือองค์กรหลายราย
    - คุณต้องเลือกขอบเขตการแยกสำหรับเวิร์กโหลดของผู้เช่า
summary: โฮสต์โดเมนความเชื่อถือของผู้เช่าหลายรายโดยใช้เซลล์ Gateway ของ OpenClaw ที่แยกจากกันหนึ่งเซลล์ต่อผู้เช่า
title: การโฮสต์แบบหลายผู้เช่า
x-i18n:
    generated_at: "2026-07-16T19:09:14Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: 383d32331b45d40db6fb4ff8242dd9a3cf8898a3ccab19f0372cd06bbd83fc05
    source_path: gateway/multi-tenant-hosting.md
    workflow: 16
---

# การโฮสต์แบบหลายผู้เช่า

โมเดลความปลอดภัยเริ่มต้นของ OpenClaw กำหนดขอบเขตผู้ดำเนินการที่เชื่อถือได้หนึ่งขอบเขตต่อ Gateway ไม่ใช่การแยกผู้เช่าหลายรายที่ไม่ไว้วางใจกันภายใน Gateway ที่ใช้ร่วมกันเพียงตัวเดียว ดังนั้น การโฮสต์ผู้ใช้หรือองค์กรที่ไม่ได้อยู่ในขอบเขตความไว้วางใจเดียวกันจึงต้องเรียกใช้อินสแตนซ์ OpenClaw ที่สมบูรณ์แยกกันสำหรับผู้เช่าแต่ละราย

`openclaw fleet` เรียกอินสแตนซ์ที่แยกแต่ละรายการว่า **เซลล์** เซลล์คือ Gateway แบบเต็มที่ทำงานในคอนเทนเนอร์ที่เสริมความปลอดภัย พร้อมสถานะ ข้อมูลประจำตัว พื้นที่ทำงาน บัญชีช่องทาง โทเค็น และพอร์ตโฮสต์ที่รับฟังเฉพาะลูปแบ็กเป็นของตนเอง

Fleet ยังอยู่ในขั้น **ทดลอง**: คำสั่ง แฟล็ก และโปรไฟล์คอนเทนเนอร์อาจเปลี่ยนแปลงระหว่างรุ่นได้โดยไม่มีช่วงเวลาแจ้งเลิกใช้ล่วงหน้า

Fleet ผ่านการทดสอบบนโฮสต์ Linux และ macOS แล้ว ปัจจุบันยังไม่ได้ทดสอบโฮสต์ Windows

## เหตุใดผู้เช่าแต่ละรายจึงต้องมีเซลล์

ผู้ดำเนินการที่ผ่านการยืนยันตัวตนภายใน Gateway หนึ่งตัวมีบทบาทในระนาบควบคุมที่เชื่อถือได้ รหัสเซสชันใช้เลือกการกำหนดเส้นทาง แต่ไม่ได้อนุญาตสิทธิ์ให้ผู้เช่ารายหนึ่งเข้าถึงหรือกระทำต่อผู้เช่าอีกราย การแซนด์บ็อกซ์เอเจนต์สามารถลดผลกระทบจากเนื้อหาที่ไม่น่าเชื่อถือและการเรียกใช้เครื่องมือได้ แต่ไม่ได้เปลี่ยน Gateway ที่ใช้ร่วมกันหนึ่งตัวให้เป็นขอบเขตการอนุญาตสิทธิ์ระหว่างผู้เช่า

ใช้หนึ่งเซลล์ต่อผู้เช่า เพื่อให้แต่ละโดเมนความไว้วางใจมีกระบวนการ Gateway คอนเทนเนอร์ โครงสร้างสถานะถาวร และข้อมูลประจำตัว Gateway แยกจากกัน ซึ่งเป็นไปตาม[โมเดลความปลอดภัยของ Gateway](/th/gateway/security): อย่าวางผู้ใช้ที่ไม่ไว้วางใจกันไว้ร่วมกันในกระบวนการ OpenClaw เดียวหรือภายใต้ผู้ใช้ระบบปฏิบัติการเดียวกัน

## สถาปัตยกรรม

Fleet CLI เป็นตัวควบคุมวงจรชีวิตที่ทำงานฝั่งโฮสต์ โดยบันทึกเซลล์ไว้ในฐานข้อมูลสถานะของ OpenClaw และสั่งให้รันไทม์ Docker หรือ Podman ภายในเครื่องสร้าง ตรวจสอบ เริ่ม หยุด แทนที่ และนำคอนเทนเนอร์ออก ไม่รองรับปลายทางรันไทม์ระยะไกล เนื่องจากพาธที่ผูกเมานต์และ URL ลูปแบ็กของ Fleet เป็นของโฮสต์ภายในเครื่อง Fleet ไม่ทำหน้าที่พร็อกซีข้อความของผู้เช่าและไม่เพิ่มเส้นทางข้อมูลระดับแอปพลิเคชันที่ใช้ร่วมกันระหว่างเซลล์

แต่ละเซลล์เรียกใช้อิมเมจ `ghcr.io/openclaw/openclaw` อย่างเป็นทางการบนเครือข่ายบริดจ์ที่ผู้ใช้กำหนดของตนเอง บริดจ์ที่แยกกันป้องกันการรับส่งข้อมูลโดยตรงผ่าน IP ของคอนเทนเนอร์ระหว่างเซลล์ ขณะที่ยังคงให้เข้าถึง NAT ขาออกสำหรับผู้ให้บริการและช่องทางต่าง ๆ ได้ โดยค่าเริ่มต้น การรับส่งข้อมูลขาออกไม่มีข้อจำกัด เซลล์ Podman สามารถใช้ `--network internal` เพื่อบล็อกการรับส่งข้อมูลขาออกโดยยังคงพอร์ต Gateway แบบลูปแบ็กที่เผยแพร่ไว้ เครือข่ายภายในของ Docker ทำให้พอร์ตที่เผยแพร่นั้นใช้งานไม่ได้ Fleet จึงปฏิเสธการใช้ร่วมกันดังกล่าว สำหรับ Docker ให้บังคับใช้นโยบายการรับส่งข้อมูลขาออกด้วยกฎไฟร์วอลล์ของโฮสต์ เช่น เชน `DOCKER-USER` แทน Gateway ของเซลล์รับฟังบนพอร์ต `18789` ภายในคอนเทนเนอร์ ขณะที่รันไทม์เผยแพร่พอร์ตดังกล่าวเฉพาะไปยัง `127.0.0.1:<allocated-port>` บนโฮสต์ ผู้ดำเนินการสามารถวางรีเวิร์สพร็อกซี อุโมงค์ SSH หรือเครือข่ายส่วนตัวที่ได้รับอนุมัติไว้หน้าปลายทางลูปแบ็กนั้นเมื่อจำเป็นต้องเข้าถึงจากระยะไกล

สถานะถาวรของ Gateway มาจาก `<state-dir>/fleet/cells/<tenant>/` และเมานต์ไว้ที่ `/home/node/.openclaw` คีย์เข้ารหัสโปรไฟล์การยืนยันตัวตนมาจากพาธโฮสต์ `<state-dir>/fleet/auth-profile-secrets/<tenant>/` ที่แยกต่างหาก และเมานต์ไว้ที่ `/home/node/.config/openclaw` ซึ่งตรงกับ[รูปแบบการจัดเก็บข้อมูลถาวรของ Docker](/th/install/docker#storage-and-persistence)อย่างเป็นทางการ คีย์ไม่ได้ซ้อนอยู่ภายใต้จุดเมานต์สถานะทั่วไป บัญชีช่องทางของผู้เช่าแต่ละรายสิ้นสุดการเชื่อมต่อภายในเซลล์ที่เป็นเจ้าของบัญชีนั้น Fleet ไม่มีบัญชีช่องทางที่ใช้ร่วมกันหรือตัวกำหนดเส้นทางข้อความขาเข้าแบบใช้ร่วมกัน

อิมเมจอย่างเป็นทางการใช้ผู้ใช้ `node` ที่ไม่ใช่รูทและมี UID 1000 เป็นค่าเริ่มต้น Fleet ใช้การแมปผู้ใช้ที่เข้ากันได้กับโฮสต์เพื่อให้การผูกเมานต์แบบส่วนตัวยังคงเขียนได้: Podman ใช้ `keep-id`, Docker แบบ rootful ใช้ข้อมูลประจำตัวที่ไม่ใช่รูทของผู้เรียกใช้ และ Docker แบบ rootless แมปรูทของคอนเทนเนอร์ไปยังผู้ใช้เดมอนที่ไม่มีสิทธิ์พิเศษ Docker และ Podman ใช้การติดป้ายกำกับใหม่แบบส่วนตัว `:Z` เมื่อ SELinux ของโฮสต์ทำงานอยู่ โปรไฟล์คอนเทนเนอร์หลีกเลี่ยงคุณสมบัติโฮสต์ที่มีสิทธิ์พิเศษและรองรับการทำงานแบบ rootless ได้ดี แต่การทำงานแบบ rootless เป็นตัวเลือกและข้อกำหนดเบื้องต้นของรันไทม์บนโฮสต์ ไม่ใช่สิ่งที่ Fleet เปิดใช้งานให้อัตโนมัติ

## ขอบเขตความไว้วางใจ

การทำงานแบบหลายผู้เช่าปกป้องผู้เช่าจากกันและกัน ผู้เช่าทุกรายไว้วางใจผู้ดำเนินการ Fleet และโฮสต์ การต้านทานโฮสต์ที่ถูกเจาะระบบไม่ใช่เป้าหมายของระบบนี้

ซึ่งหมายความว่าผู้ดูแลโฮสต์สามารถตรวจสอบการกำหนดค่าและสภาพแวดล้อมของคอนเทนเนอร์ อ่านข้อมูลเซลล์ที่เมานต์ไว้ แทนที่อิมเมจ หรือเข้าสู่คอนเทนเนอร์ได้ ผู้ดูแลสามารถมองเห็นโทเค็น Gateway และค่าที่ส่งผ่าน `--env` ได้จากการตรวจสอบ Docker หรือ Podman ดังนั้นจึงควรใช้มาตรการควบคุมโฮสต์ นโยบายการเข้าถึงระดับผู้ดูแล การเฝ้าติดตาม การสำรองข้อมูล และตัวจัดการข้อมูลลับที่ได้รับอนุมัติอย่างเหมาะสม

ค่าพื้นฐานนี้ป้องกันการเปิดเผยเครือข่ายด้วยไวลด์การ์ดโดยไม่ตั้งใจและนำกลไกทั่วไปที่ใช้ยกระดับสิทธิ์จากคอนเทนเนอร์ออก แต่ไม่ได้ทำให้โฮสต์ที่ไม่น่าเชื่อถือมีความปลอดภัย

## ลำดับขั้นการแยก

เลือกขอบเขตที่เหมาะกับผู้เช่าที่โฮสต์:

1. **ค่าพื้นฐานของคอนเทนเนอร์ที่เสริมความปลอดภัย** Fleet ยกเลิกความสามารถทั้งหมดของ Linux เปิดใช้ `no-new-privileges` กำหนดขีดจำกัด PID หน่วยความจำ CPU และขนาดดิสก์ของเลเยอร์ที่เขียนได้ซึ่งเป็นตัวเลือก ใช้จุดเมานต์ถาวรและเครือข่ายแยกสำหรับแต่ละเซลล์ และเผยแพร่เฉพาะไปยังลูปแบ็กของโฮสต์ เครือข่ายบริดจ์ไม่จำกัดการรับส่งข้อมูลขาออก ให้ใช้ `--network internal` ของ Podman หรือนโยบายไฟร์วอลล์ของโฮสต์ Docker เมื่อเซลล์ต้องไม่เริ่มการเชื่อมต่อขาออก นี่คือโปรไฟล์เริ่มต้นสำหรับผู้เช่าที่ไว้วางใจผู้ดำเนินการและโฮสต์
2. **การแยกด้วยคอนเทนเนอร์หรือ VM ที่แข็งแกร่งกว่า** สำหรับเวิร์กโหลดที่มีความเสี่ยงสูงกว่า ให้กำหนดค่า Docker หรือ Podman ให้ใช้รันไทม์การแยก OCI ที่แข็งแกร่งกว่า เช่น gVisor หรือ Kata Containers หรือวางเซลล์ใน microVM การดำเนินการนี้เป็นการกำหนดค่ารันไทม์หรือโครงสร้างพื้นฐาน ตัวเลือก `--runtime docker|podman` ของ Fleet ใช้เลือก CLI ของคอนเทนเนอร์ ไม่ใช่แบ็กเอนด์การแยก OCI โปรดดู[รันไทม์คอนเทนเนอร์ทางเลือก](https://docs.docker.com/engine/daemon/alternative-runtimes/)ของ Docker และ[คู่มือรันไทม์ Docker VM](/th/install/docker-vm-runtime)
3. **เครื่องแยกสำหรับผู้เช่าที่ไม่ไว้วางใจกัน** อย่าวางผู้เช่าที่ไม่ไว้วางใจกันไว้ร่วมกันในกระบวนการ OpenClaw เดียวหรือภายใต้ผู้ใช้ระบบปฏิบัติการเดียวกัน เมื่อผู้เช่าไม่ไว้วางใจผู้ดำเนินการโฮสต์รายเดียวกันหรือต้องการขอบเขตการดูแลระบบที่แข็งแกร่งกว่า ให้ใช้ VM หรือโฮสต์จริงแยกกันพร้อมการดูแลรันไทม์แยกกัน

ไม่มีขั้นใดในลำดับนี้ที่เปลี่ยนโมเดลความไว้วางใจของแอปพลิเคชัน OpenClaw: Gateway หนึ่งตัวยังคงเป็นโดเมนผู้ดำเนินการที่เชื่อถือได้หนึ่งโดเมน

## เริ่มต้นอย่างรวดเร็ว

สร้างเซลล์ คำสั่งจะแสดงโทเค็น Gateway ที่สร้างขึ้นเพียงครั้งเดียว ดังนั้นให้จัดเก็บทันที:

```bash
openclaw fleet create acme
```

เปิด URL `http://127.0.0.1:<port>` ที่รายงานบนโฮสต์ Fleet ยืนยันตัวตนด้วยโทเค็นของผู้เช่ารายนั้น และกำหนดค่าข้อมูลประจำตัวของผู้ให้บริการและบัญชีช่องทางภายในเซลล์

ตรวจสอบสถานะคอนเทนเนอร์และความพร้อมใช้งานของ Gateway:

```bash
openclaw fleet status acme
```

อัปเกรดโดยคงพอร์ตโฮสต์ ข้อมูลที่เมานต์ โปรไฟล์ทรัพยากร สภาพแวดล้อมที่ผู้ใช้ระบุ และโทเค็น Gateway ไว้:

```bash
openclaw fleet upgrade acme
```

นำคอนเทนเนอร์และแถวรีจิสทรีออกโดยยังคงข้อมูลผู้เช่าไว้:

```bash
openclaw fleet rm acme --force
```

หากต้องการลบข้อมูลถาวรของผู้เช่าด้วย ให้เพิ่ม `--purge-data` การล้างข้อมูลต้องใช้ `--force` ไม่สามารถย้อนกลับได้ และจะตรวจสอบว่าพาธที่แก้ไขสมบูรณ์แล้วยังคงอยู่ภายในขอบเขตก่อนลบสิ่งใด:

```bash
openclaw fleet rm acme --purge-data --force
```

โปรดดู[เอกสารอ้างอิง CLI ของ `openclaw fleet`](/cli/fleet)สำหรับคำสั่งและตัวเลือกทั้งหมด

## ขอบเขตปัจจุบัน

Fleet ไม่มีความสามารถต่อไปนี้:

- บัญชีช่องทางที่ใช้ร่วมกันหรือตัวกำหนดเส้นทางขาเข้าแบบใช้ร่วมกัน
- กระบวนการโฮสต์แบบลดขนาดสำหรับผู้เช่าแต่ละรายแทนอินสแตนซ์ OpenClaw ที่สมบูรณ์
- โฮสต์เซลล์ระยะไกลที่จัดการโดยตัวควบคุมเดียว
- พอร์ทัลบริการตนเองสำหรับผู้เช่า ระนาบการเรียกเก็บเงิน หรือ UI การดูแลระบบแบบมอบหมายสิทธิ์

ความสามารถเหล่านี้จำเป็นต้องมีสัญญาที่ชัดเจนสำหรับข้อมูลประจำตัว การกำหนดเส้นทาง การอนุญาตสิทธิ์ และโดเมนความล้มเหลว อย่าจำลองความสามารถเหล่านี้ด้วยการใช้ Gateway หนึ่งตัวหรือข้อมูลประจำตัวของ Gateway ร่วมกันระหว่างผู้เช่า Fleet เป็นตัวควบคุมวงจรชีวิตสำหรับโฮสต์เดียว ส่วนฟลีตหลายเครื่องที่อยู่ภายใต้การกำกับดูแลด้านข้อมูลประจำตัวต้องมีชั้นระนาบควบคุมแยกต่างหาก

## เนื้อหาที่เกี่ยวข้อง

- [`openclaw fleet`](/cli/fleet)
- [ความปลอดภัยของ Gateway](/th/gateway/security)
- [Gateway หลายตัว](/th/gateway/multiple-gateways)
- [Docker](/th/install/docker)
- [Podman](/th/install/podman)