วิธีรัน Claude Code บน server ให้ปลอดภัย

ความหมายของการรัน Claude Code บน server อย่างปลอดภัย

เพื่อให้รัน Claude Code บน server ได้อย่างปลอดภัย ควรเปิดการแจ้งเตือนขออนุญาต (permission prompts) ไว้เสมอ, รันผ่าน user ที่ไม่มีสิทธิ์ระดับสูง (unprivileged user) และกำหนดขอบเขตที่แท้จริงสำหรับการทำงานแบบ unattended แทนการใช้ความเชื่อใจ: โดยใช้ sandbox ที่มากับระบบ, container หรือ VPS แบบใช้แล้วทิ้งที่ไม่มีข้อมูลสำคัญใดๆ อยู่เลย การใช้ flag --dangerously-skip-permissions จะเป็นการยกเลิกขั้นตอนการขออนุมัติระหว่าง model และ shell ของคุณ การแลกเปลี่ยนนี้อาจยอมรับได้สำหรับการทำงานแบบ unattended แต่ต้องอยู่ภายใต้ขอบเขตที่จำกัดความเสียหายหากมีคำสั่งที่ผิดพลาดเกิดขึ้นเท่านั้น คู่มือนี้จะอธิบายว่า flag ดังกล่าวเปลี่ยนการทำงานอย่างไร และวิธีสร้างขอบเขตดังกล่าวโดยแบ่งเป็นระดับความปลอดภัยที่เพิ่มขึ้นตามลำดับ

สิ่งที่ Claude Code สามารถทำได้บนเครื่องของคุณ

Claude Code คือ coding agent ที่ทำงานใน terminal ของคุณ สามารถอ่านไฟล์, เขียนไฟล์ และรัน shell commands ในฐานะ user ที่เป็นผู้เริ่มรัน นี่คือคุณค่าหลักของเครื่องมือนี้: มันสามารถ clone repository, แก้ไข code, รัน test, อ่านผลลัพธ์ความผิดพลาด และแก้ไข code วนลูปได้โดยที่คุณไม่ต้องพิมพ์คำสั่งเอง หากคุณยังไม่ได้ติดตั้งบน server การรัน Claude Code บน VPS ด้วย tmux จะครอบคลุมเรื่องการติดตั้งและการจัดการ session หน้าเว็บนี้จะอธิบายถึงอำนาจที่คุณมอบให้มันเมื่อติดตั้งเสร็จแล้ว

ความเสี่ยงนั้นเหมือนกับการอ่านประโยคเดิมซ้ำเป็นครั้งที่สอง Process ที่รัน shell commands ในฐานะ user ของคุณสามารถทำทุกอย่างที่ user ของคุณทำได้ มันสามารถอ่าน ~/.ssh/id_ed25519, ~/.aws/credentials และทุกไฟล์ .env ที่ user ของคุณสามารถเปิดได้ มันสามารถรัน curl และส่งข้อมูลไปยัง host ใดก็ได้ที่ server สามารถเชื่อมต่อถึง และสามารถรัน git push --force ได้ ตัว agent ไม่มีเจตนาของตัวเอง อันตรายเกิดจากการที่งานผิดพลาด หรือข้อความที่มันอ่านขณะทำงานมีคำสั่งที่เขียนโดยผู้อื่นแฝงมา เช่น หน้าเว็บที่มันไปดึงมา หรือ comment ใน issue ที่ถูกสั่งให้แก้ไข กรณีหลังนี้เรียกว่า prompt injection และเป็นเหตุผลที่คำกล่าวที่ว่า "model มักจะสมเหตุสมผล" ไม่สามารถใช้เป็นแผนความปลอดภัยได้ คุณต้องวางแผนรับมือกับการทำงานที่ผิดพลาด ไม่ใช่การทำงานปกติ

ระบบการขออนุญาตในภาษาที่เข้าใจง่าย

โดยพื้นฐาน Claude Code จะถามก่อนดำเนินการ การอ่านไฟล์ภายในโปรเจกต์จะทำอย่างเงียบๆ แต่การแก้ไขไฟล์หรือการรัน shell command จะแสดงการแก้ไขหรือคำสั่งนั้นให้คุณเห็นก่อนและรอการยืนยัน คุณสามารถอนุมัติทีละคำสั่ง หรืออนุมัติการกระทำประเภทนั้นตลอดทั้ง session การอนุมัติเหล่านี้มีขอบเขตเฉพาะใน session นั้น: หากปิด CLI เมื่อเริ่ม session ใหม่ ระบบจะกลับมาใช้โหมดระมัดระวังอีกครั้ง สำหรับกฎที่คุณต้องการให้คงอยู่ถาวร ไฟล์ settings จะเก็บรายการ allow, ask, และ deny ไว้ ตัวอย่างเช่น: allow git status, ask เมื่อเจอ git push, deny การอ่าน .env กฎ deny จะมีลำดับความสำคัญสูงสุดเสมอ

การออกแบบนี้ตั้งอยู่บนสมมติฐานว่ามีมนุษย์คอยเฝ้าหน้าจอ terminal ซึ่งเป็นเรื่องจริงสำหรับ laptop แต่สำหรับ server จุดสำคัญคือมักจะไม่มีใครเฝ้าหน้าจอ คุณเริ่มงานที่ใช้เวลานานใน tmux แล้วไปนอน และหาก agent หยุดเพื่อถามคำถามตอนตี 2 งานจะไม่มีความคืบหน้าจนกว่าจะถึงเช้า การหยุดรอทำให้เสียทั้งเงินและเวลา เพราะ session ของ Claude Code ที่ว่างงานจะสูญเสีย warm prompt cache และการทำงานรอบถัดไปต้องเสียเวลาสร้างมันขึ้นมาใหม่ นี่คือเหตุผลที่แท้จริงที่คนเลือกใช้ skip flag บน server และปัญหาที่มันแก้คือปัญหาที่เกิดขึ้นจริง ส่วนที่เหลือของคู่มือนี้คือวิธีแก้ปัญหานี้โดยไม่ต้องละทิ้งระบบป้องกันทั้งหมด

สิ่งที่ --dangerously-skip-permissions เปลี่ยนแปลง

claude --dangerously-skip-permissions จะปิดขั้นตอนการขออนุมัติ การแก้ไขไฟล์จะเกิดขึ้นโดยไม่มีการถาม การรัน shell commands จะเกิดขึ้นโดยไม่มีการถาม และการตรวจสอบ protected-path ที่ปกติจะป้องกันตำแหน่งที่สำคัญจะถูกข้ามไปด้วย กฎ deny ที่คุณตั้งไว้โดยเฉพาะยังคงใช้งานได้ และการกระทำที่รุนแรงบางอย่างจะยังคงหยุดเพื่อถามสรุปการทำงานคือ: ไม่ว่า model จะตัดสินใจรันอะไร สิ่งนั้นจะถูกรันทันที

มี 2 ข้อเท็จจริงเกี่ยวกับ flag นี้ที่สำคัญสำหรับ server ประการแรก มันจะถูกบล็อกเมื่อ Claude Code รันในฐานะ root หรือใช้ sudo บน Linux และ macOS เนื่องจาก root ที่ไม่มีการถามจะสามารถแก้ไขไฟล์หรือ service ใดก็ได้บนเครื่อง ตัว agent จำเป็นต้องมี account ที่ไม่มีสิทธิ์สูงของตัวเองอยู่แล้ว และ flag นี้ช่วยบังคับใช้กฎนั้น ประการที่สอง flag นี้ไม่ได้เปลี่ยนพฤติกรรมของ model แต่อย่างใด มันเพียงแค่ตัดมนุษย์ออกจากวงจรการตัดสินใจและไม่เปลี่ยนสิ่งอื่น ดังนั้นทุกความผิดพลาดที่ prompt ปกติจะตรวจจับได้ จะถูกรันทันทีเมื่อใช้ flag นี้

ดังนั้น นี่คือการคำนวณตามความเป็นจริง หากคุณข้ามการขออนุญาต คำถามด้านความปลอดภัยจะเปลี่ยนจาก "agent จะทำสิ่งที่ผิดพลาดหรือไม่" เป็น "การกระทำที่ผิดพลาดหนึ่งครั้งจะสร้างความเสียหายได้มากเพียงใด" คุณจะเลิกพยายามควบคุมทุกการตัดสินใจ และเริ่มควบคุมขอบเขตความเสียหาย (blast radius) การจำกัดขอบเขตคือคำตอบ ซึ่งแบ่งได้เป็นระดับต่างๆ

Sandbox ของ Claude Code ที่มากับระบบ

ก่อนจะไปดูระดับต่างๆ โปรดทราบว่าปัจจุบัน Claude Code มาพร้อมกับ OS-level sandbox สำหรับคำสั่งที่รัน ซึ่งช่วยลดเหตุผลที่คนต้องใช้ skip flag ไปได้มาก บน Linux ระบบจะใช้ bubblewrap สำหรับการแยก filesystem และใช้ socat เพื่อส่ง network traffic ผ่าน proxy ภายใน sandbox คำสั่งสามารถเขียนไฟล์ได้เฉพาะใน directory ของโปรเจกต์และ directory ชั่วคราวของ session เท่านั้น และสามารถเชื่อมต่อ network ได้ผ่าน proxy ที่ตรวจสอบทุก domain เทียบกับ allow list เท่านั้น เมื่อคำสั่งต้องการเข้าถึง domain ใหม่เป็นครั้งแรก Claude Code จะถามคุณ

เปิดใช้งานด้วยคำสั่ง /sandbox ภายใน session สำหรับ Ubuntu และ Debian ให้ติดตั้ง 2 package ที่จำเป็นก่อน:

sudo apt install bubblewrap socat

บน Ubuntu 24.04 และเวอร์ชันที่ใหม่กว่า นโยบาย AppArmor เริ่มต้นจะขัดขวางไม่ให้ bubblewrap สร้าง user namespaces ที่จำเป็น แผงควบคุม sandbox จะแจ้งให้ทราบหากมีบางอย่างขาดหายไป และเอกสารการทำ sandboxing ของ Claude Code จะมี AppArmor profile สั้นๆ ที่ใช้แก้ไขปัญหานี้

sandbox มีโหมด auto-allow: คำสั่งใน sandbox จะรันได้โดยไม่มีการถาม เพราะขอบเขตที่บังคับใช้ทำหน้าที่แทนการถามไปแล้ว คำสั่งที่ไม่สามารถรันใน sandbox ได้จะกลับไปใช้ขั้นตอนการขออนุญาตแบบปกติ ดังนั้นการกระทำที่ผิดปกติจริงๆ จะยังคงมีการถาม สำหรับ workflow ส่วนใหญ่บน server นี่คือตัวแทนที่ถูกต้องแทนการใช้ skip flag เพราะคุณจะได้รับการถามน้อยลงมากจากการใช้ขอบเขตที่บังคับโดย OS แทนที่จะไม่มีเลย

จงยอมรับข้อจำกัดของมัน ตามปกติแล้วคำสั่งใน sandbox ยังสามารถอ่านไฟล์ส่วนใหญ่ใน filesystem ได้ รวมถึงไฟล์ credential เว้นแต่คุณจะ deny path เหล่านั้น ซึ่งการตั้งค่า sandbox.credentials มีไว้เพื่อการนี้โดยเฉพาะ network proxy จะตรวจสอบเพียงชื่อ domain และไม่ได้ตรวจสอบเนื้อหา traffic ดังนั้นการ allow แบบกว้างๆ เช่น github.com ยังคงเปิดช่องให้ส่งข้อมูลออกได้ Docker ไม่สามารถทำงานภายใน sandbox นี้ได้ sandbox ช่วยยกระดับความปลอดภัยขึ้นมาก แต่มันไม่ใช่ขอบเขตการแยกส่วนที่สมบูรณ์ นี่คือเหตุผลที่ระดับความปลอดภัยด้านล่างยังคงมีความสำคัญ

บันไดการจำกัดขอบเขต (The containment ladder)

สามระดับ โดยเรียงจากระดับการแยกส่วนที่น้อยไปมาก เลือกระดับต่ำสุดที่เหมาะสมกับสิ่งที่มีอยู่บนเครื่องของคุณ

ระดับที่ 1: unprivileged user เฉพาะทาง Agent จะได้รับ account ของตัวเอง, home directory ของตัวเอง, project directory ของตัวเอง และไม่มีสิทธิ์ sudo:

sudo adduser --disabled-password --gecos "" agent

ขอบเขตของ account จะช่วยกัน agent ออกจากไฟล์ของคุณ: ทั้ง SSH keys และโปรเจกต์อื่นๆ บนเครื่อง นอกจากนี้ยังทำให้ skip flag ใช้งานได้ เพราะ flag นี้จะปฏิเสธการรันในฐานะ root นี่คือหลักการเดียวกับ การรันทุก service ในฐานะ unprivileged user ที่นำมาใช้กับ agent สิ่งที่ระดับ 1 ไม่สามารถจำกัดได้คือ: network และทุกสิ่งที่บนเครื่องสามารถอ่านได้โดยทุกคน (world-readable)

ระดับที่ 2: container Anthropic ได้เผยแพร่ devcontainer อ้างอิงที่รัน Claude Code ในฐานะ non-root user พร้อมกฎ firewall ที่จำกัด host ที่ agent สามารถเข้าถึงได้ และ container ที่คุณสร้างเองก็ทำงานได้เช่นกัน Filesystem จะถูกจำกัดเหลือเพียง volumes ที่คุณ mount และการส่งข้อมูลออกจะถูกจำกัดตามกฎของ container นี่คือระดับกลางที่เหมาะสมเมื่อ server มี service อื่นที่คุณต้องการดูแล ความจำกัดของมันคือ container ใช้ kernel ร่วมกับ host และการ mount ที่ผิดพลาดเพียงครั้งเดียวสามารถทำลายขอบเขตได้ หากคุณส่ง /var/run/docker.sock ให้ container มันจะสามารถเข้าถึง host ได้ทั้งหมด

ระดับที่ 3: VPS เฉพาะทาง ระดับที่แข็งแกร่งที่สุดคือวิธีที่ตรงไปตรงมาที่สุด: มอบเครื่องทั้งเครื่องที่ไม่มีข้อมูลสำคัญใดๆ ให้กับ agent VPS ขนาดเล็กมีค่าใช้จ่ายเพียงไม่กี่ดอลลาร์ต่อเดือน ตั้งค่าด้วย คู่มือการใช้งาน VPS ใหม่ใน 10 นาทีแรก ทำ snapshot ของสถานะที่สะอาดไว้ แล้วปล่อยให้ agent ทำงาน ไม่มีสิ่งอื่นอยู่ในนั้น ไม่มี SSH key ส่วนตัว มีเพียง deploy key ที่จำกัดสิทธิ์เฉพาะ repository เดียว ไม่มี cloud credentials ไม่มีข้อมูล production เมื่อการรันผิดพลาด หรือเมื่อคุณต้องการเริ่มใหม่ ให้ restore snapshot หรือทำลายและสร้างเครื่องใหม่ในไม่กี่นาที ขอบเขตความเสียหายก็คือค่าเช่าเครื่อง นี่คือการตั้งค่าที่ทำให้ --dangerously-skip-permissions ไม่น่ากลัวอีกต่อไป เพราะผลลัพธ์ที่เลวร้ายที่สุดที่เกิดขึ้นจริงคือการสร้าง server ใหม่และ token หนึ่งตัวที่ถูกยกเลิก

ระดับต่างๆ สามารถซ้อนทับกันได้ การใช้ agent ใน sandbox, รันในฐานะ unprivileged user, บน VPS แบบใช้แล้วทิ้ง แทบไม่มีค่าใช้จ่ายเพิ่มขึ้นและทำให้เรื่องราวความผิดพลาดกลายเป็นเรื่องธรรมดา ความธรรมดานี่แหละคือเป้าหมาย

ปกป้อง credentials

กฎที่สำคัญที่สุดสำหรับทุกอย่าง: user ของ agent ต้องไม่สามารถอ่านความลับ (secrets) ที่เป็นของสิ่งอื่นได้

มอบ API key ให้กับ agent เท่านั้น ห้ามมอบให้สิ่งอื่น นำไปใส่ในไฟล์ที่เป็นของ user ของ agent โดยใช้ mode 600 และโหลดเมื่อ shell เริ่มทำงาน:

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

จากนั้นปิดช่องทางอื่น ใน Debian และ Ubuntu home directory มักถูกสร้างให้ user ทุกคนบนเครื่องอ่านได้ ดังนั้นจงทำให้รัดกุมขึ้น: chmod 750 /home/youruser ตรวจสอบด้วย ls -ld /home/* และแก้ไขทุกอย่างที่ account ของ agent สามารถ list ได้

จำกัดขอบเขตของทุก token GitHub token ที่มีรายละเอียดสูงและจำกัดเฉพาะหนึ่ง repository หรือ deploy key ต่อหนึ่ง repository หมายความว่าหาก credential หลุด จะเสียไปเพียงโปรเจกต์เดียว ไม่ใช่ทั้ง account ของคุณ หากคุณใช้ sandbox ให้เพิ่มการตั้งค่า credential เพื่อ deny ~/.ssh และ ~/.aws แม้แต่สำหรับการอ่าน และเก็บ production credentials ไว้ข้างนอกเครื่องโดยสิ้นเชิง เพราะ agent ไม่สามารถทำข้อมูลหลุดได้หากข้อมูลนั้นไม่เคยอยู่ในเครื่อง

Git คือตาข่ายนิรภัย

ทุกการเปลี่ยนแปลงที่ agent ทำควรสามารถตรวจสอบและย้อนกลับได้ ซึ่ง git มอบทั้งสองอย่างให้ฟรีหาก agent ทำงานบน branch:

git switch -c agent/refactor-auth

ตรวจสอบการทำงานหลังจากนั้นด้วย git diff main...agent/refactor-auth, merge สิ่งที่ดี และลบ branch ทิ้งหากการรันนั้นไม่ได้ผลลัพธ์ที่ต้องการ ปกป้อง main branch ในฝั่ง forge เพื่อไม่ให้ token ของ agent สามารถ push หรือ force-push ได้ ประวัติการ commit ยังทำหน้าที่เป็น audit log ของสิ่งที่เกิดขึ้นขณะที่คุณหลับ ซึ่งมีค่ามากกว่าการเลื่อนดู terminal scrollback ใดๆ

Network คือส่วนหนึ่งของขอบเขตความเสียหาย

Agent สามารถรัน curl ประโยคนี้คือปัญหาการส่งข้อมูลออก (egress) ทั้งหมด: ไม่ว่า agent จะอ่านอะไรได้ มันก็สามารถส่งสิ่งนั้นออกไปที่ไหนก็ได้ และ agent ที่ถูก prompt injection อาจทำเช่นนั้นได้ unprivileged user ธรรมดาไม่สามารถจำกัดเรื่องนี้ได้เลย เพราะ user ใดๆ ก็สามารถเข้าถึงอะไรก็ได้ที่ server เข้าถึงได้ sandbox จำกัดเรื่องนี้ด้วย domain ผ่าน proxy ส่วน container สามารถจำกัดได้ด้วยกฎ firewall ของตัวเอง และ VPS เฉพาะทางจำกัดสิ่งที่สามารถหลุดออกไปได้ตั้งแต่แรก ซึ่งเป็นคำตอบที่แข็งแกร่งที่สุดในสามวิธีนี้

อย่าพยายามแก้ปัญหา egress ด้วย ufw เพียงอย่างเดียว ufw อนุญาต traffic ขาออกทั้งหมดโดยค่าเริ่มต้น และการเขียนกฎขาออกที่ยังต้องอนุญาต apt, npm, git และ Claude API เป็นงานที่ยุ่งยากและอาจพังได้โดยไม่แจ้งเตือน จงเลือกขอบเขตที่ระดับ sandbox, container หรือระดับเครื่องแทน ซึ่งการใช้ domain allow list หรือเครื่องเปล่าๆ จะทำงานได้สะอาดกว่า

หากคุณกำลังสร้าง agent ของคุณเองผ่าน API แทนที่จะรัน Claude Code แนวคิดเดียวกันนี้สามารถนำมาใช้ได้ทันที การสร้าง AI agent ด้วย Claude บน VPS จะครอบคลุมแนวทางนั้น และ agent ของคุณก็ควรได้รับ user เฉพาะ, token ที่จำกัดสิทธิ์ และเครื่องแบบใช้แล้วทิ้งเช่นเดียวกัน

เสริมความแข็งแกร่งให้เครื่องก่อน (Harden the box)

ไม่ว่าคุณจะเลือกระดับใด ตัวเครื่องเองยังคงต้องการพื้นฐานก่อนที่ agent จะเข้ามา: มีเฉพาะ SSH keys, ห้าม login ด้วย root, มี firewall แบบ default-deny และมีการอัปเดตความปลอดภัยอัตโนมัติ สร้างรายการตรวจสอบของคุณที่นี่และทำตามลำดับ:

FAQ

--dangerously-skip-permissions ปลอดภัยที่จะใช้บน server หรือไม่?

ไม่ปลอดภัยด้วยตัวมันเอง flag นี้จะลบการแจ้งเตือนขออนุมัติทั้งหมด ดังนั้นคำสั่งที่ผิดพลาดคำสั่งแรกจะทำงานทันทีที่ model สร้างขึ้นมา มันจะเป็นการแลกเปลี่ยนที่ยอมรับได้ก็ต่อเมื่อขอบเขตความเสียหายถูกจำกัดไว้แล้ว: อย่างน้อยต้องเป็น unprivileged user เฉพาะทาง และสำหรับการทำงานแบบ unattended จริงๆ ต้องเป็น container หรือ VPS แบบใช้แล้วทิ้งที่มีเพียงโปรเจกต์เดียวและ token เดียว อย่าใช้บนเครื่องที่มี production credentials หรือข้อมูลที่คุณไม่สามารถสูญเสียได้

Claude Code มี sandbox หรือไม่?

มี Claude Code มาพร้อมกับ sandbox สำหรับ shell commands ซึ่งเปิดใช้งานด้วยคำสั่ง /sandbox ระบบใช้ bubblewrap บน Linux และ Seatbelt บน macOS จำกัดการเขียนไฟล์ไว้ที่ directory ของโปรเจกต์ และส่งการเข้าถึง network ผ่าน proxy ที่อนุญาตเฉพาะ domain ที่ได้รับอนุมัติเท่านั้น โหมด auto-allow จะรันคำสั่งใน sandbox โดยไม่มีการถาม ซึ่งช่วยลดการขัดจังหวะเหมือนกับ skip flag แต่ยังคงมีขอบเขตที่บังคับโดย OS มันไม่ใช่ขอบเขตการแยกส่วนที่สมบูรณ์ ดังนั้นควรใช้ร่วมกับ user เฉพาะหรือเครื่องเฉพาะสำหรับการรันแบบ unattended

ทำไม skip flag ถึงปฏิเสธการรันในฐานะ root?

เพราะ root ที่ไม่มีการถามสิทธิ์สามารถแก้ไขไฟล์และ service ใดก็ได้ในระบบ Claude Code จึงบล็อก --dangerously-skip-permissions เมื่อรันในฐานะ root หรือใช้ sudo บน Linux และ macOS วิธีแก้ไขไม่ใช่การพยายามฝืนการตรวจสอบนี้ แต่คือการสร้าง unprivileged user สำหรับ agent และรันผ่านทางนั้น ขอบเขตของ account คือชั้นการจำกัดขอบเขตแรกที่ง่ายและถูกที่สุด

Claude Code สามารถอ่าน SSH keys และไฟล์ .env ของฉันได้หรือไม่?

มันสามารถอ่านอะไรก็ได้ที่ user ที่รันมันสามารถอ่านได้ และแม้แต่ policy เริ่มต้นของ sandbox ก็อนุญาตให้เข้าถึง path ของ credential ได้จนกว่าคุณจะ deny ดังนั้นจงรัน agent ในฐานะ user ของตัวเอง, ตั้งค่า home directory ของคุณให้เป็น mode 750 หรือเข้มงวดกว่านั้น, deny path ของ credential ในการตั้งค่า sandbox และเก็บ production secrets ไว้ข้างนอกเครื่องโดยสิ้นเชิง ความลับที่เครื่องไม่เคยมี ย่อมไม่สามารถถูกอ่านหรือทำให้หลุดได้

วิธีที่ปลอดภัยที่สุดในการรัน Claude Code แบบ unattended คืออะไร?

การใช้ VPS เฉพาะทางราคาถูกที่ใช้สำหรับงานของ agent เท่านั้น: เสริมความแข็งแกร่งใน 10 นาที, ทำ snapshot ไว้ในสถานะที่สะอาด, รัน Claude Code ภายใต้ unprivileged user พร้อมเปิด sandbox, ใช้ไฟล์ mode-600 สำหรับ API key, ใช้ deploy key ต่อหนึ่ง repository และทำงานทั้งหมดบน branch ที่คุณต้องตรวจสอบก่อน merge หากการรันผิดพลาด คุณเพียงแค่ยกเลิก token หนึ่งตัวและ restore snapshot และไม่มีทรัพย์สินอื่นของคุณได้รับผลกระทบ