วิธีติดตั้ง Dify บน VPS ด้วย Docker Compose ทีละขั้นตอน

Dify คืออะไรและคุณกำลังตัดสินใจติดตั้งอะไร

Dify เป็นแพลตฟอร์มแบบ self-host สำหรับสร้างแอปพลิเคชันบน Large Language Models คุณจะได้รับเว็บอินเทอร์เฟซสำหรับออกแบบแอปแชท, เอเจนต์ และไปป์ไลน์การดึงข้อมูล (retrieval pipeline) รวมถึง API สำหรับเรียกใช้งานจากโค้ดของคุณเอง และเป็นศูนย์กลางในการจัดการพรอมต์, ชุดข้อมูล และคีย์สำหรับโมเดล นี่เป็นเครื่องมือประเภทที่ทีมขนาดเล็กเลือกใช้เพื่อให้ทุกคนทำงานบนฐานข้อมูลส่วนตัวที่ใช้ร่วมกัน แทนที่จะกระจาย API keys ไว้ตามสคริปต์ต่างๆ หากคำอย่าง agent, tool call และ retrieval pipeline ยังฟังดูไม่ชัดเจน การ ทำความเข้าใจแนวคิดเหล่านี้ตั้งแต่ต้น จะช่วยให้หน้าจอตัวสร้างของ Dify ดูเหมือนส่วนควบคุมที่คุ้นเคย แทนที่จะเป็นแผงสวิตช์ที่ไม่มีป้ายกำกับ

การรันด้วยตัวเองหมายถึงการจัดการกับส่วนประกอบจำนวนมาก ณ เดือนตุลาคม 2026 สแต็กเริ่มต้นตามเอกสารของ Dify ประกอบด้วยคอนเทนเนอร์ที่รันต่อเนื่อง 15 รายการ บวกกับงานแบบครั้งเดียวที่ทำหน้าที่ตั้งค่าสิทธิ์ไฟล์แล้วจบการทำงาน โดย 7 รายการเป็นบริการของ Dify เอง ได้แก่ API server, websocket server, background worker, scheduler, web frontend, plugin daemon และ agent backend ส่วนอีก 8 รายการเป็นส่วนประกอบที่ต้องพึ่งพา ได้แก่ ฐานข้อมูล Postgres, แคช Redis, ฐานข้อมูลเวกเตอร์ Weaviate, nginx front door, code sandbox 2 รายการ และ SSRF proxy 2 รายการ Docker Compose จะเชื่อมต่อทั้งหมดเข้าด้วยกัน ซึ่งถือเป็นสแต็กขนาดใหญ่ โดยความต้องการขั้นต่ำตามเอกสารของ Dify คือ RAM 4 GiB และ CPU 2 คอร์ หาก VPS นั้นต้องรันบริการอื่นด้วย ให้คำนวณขนาดจากตัวเลขที่วัดผลได้จริงแทนตัวเลขที่โฆษณาไว้ เพราะ RAM ขั้นต่ำที่ใช้จริงของ PhotoPrism และ Immich นั้นสูงกว่าค่าขั้นต่ำที่ระบุไว้มาก และเซิร์ฟเวอร์รูปภาพที่แชร์ทรัพยากรอยู่จะทำให้ฐานข้อมูลและที่เก็บเวกเตอร์ของ Dify ขาดแคลนทรัพยากรก่อน การแย่งชิง CPU ก็ส่งผลเช่นเดียวกัน: คลังสื่อ Jellyfin ที่ปรับแต่งให้เหมือนร้านวิดีโอในยุค 90 แทบไม่ใช้ทรัพยากรขณะเรียกดูภาพปก แต่ทันทีที่มีการ transcode งานของ Dify จะถูกต่อคิวรอหลังบริการนั้น ข้อดีคือจำนวนคอนเทนเนอร์ของ Dify จะคงที่เสมอไม่ว่าคุณจะสร้างแอปบนนั้นกี่แอปก็ตาม ซึ่งเป็นรูปแบบค่าใช้จ่ายที่คาดการณ์ได้ง่ายกว่า OpenBot ที่พนักงาน AI แต่ละคนต้องมีคอนเทนเนอร์และเบราว์เซอร์ของตัวเอง ซึ่งจะทำให้ความต้องการ RAM ขั้นต่ำเพิ่มขึ้นทุกครั้งที่มีการเพิ่มผู้ใช้งานใหม่

เนื่องจาก Dify เก็บ API keys ของโมเดลและเอกสารส่วนตัวที่คุณอัปโหลดเพื่อใช้ในการดึงข้อมูล คุณควรปฏิบัติกับเซิร์ฟเวอร์ที่รัน Dify ว่าเป็นข้อมูลที่มีความสำคัญสูงตั้งแต่นาทีแรก คู่มือนี้จะแนะนำวิธีการติดตั้งและทำ hardening ให้กับเซิร์ฟเวอร์ในแบบเดียวกับที่คุณทำกับบริการอื่นๆ ที่เก็บข้อมูลความลับไว้

ข้อกำหนดเบื้องต้น

คุณต้องมี VPS ที่รัน Ubuntu 24.04 พร้อม RAM อย่างน้อย 4 GiB และ CPU 2 คอร์, ติดตั้ง Docker พร้อมปลั๊กอิน Docker Compose (Dify ต้องการ Compose เวอร์ชัน 2.24.0 ขึ้นไป) และผู้ใช้ที่มีสิทธิ์ sudo หรือเป็นสมาชิกของกลุ่ม docker คำสั่ง clone ด้านล่างยังใช้ git, curl และ jq อีกด้วย หากคุณยังไม่คุ้นเคยกับ Docker พื้นฐานของ Docker Compose บน VPS จะครอบคลุมถึงการติดตั้งและคำสั่งหลักที่คู่มือนี้ใช้เป็นฐาน คุณควรมีชื่อโดเมนที่ชี้มายังเซิร์ฟเวอร์ เนื่องจากคุณควรใช้ TLS หน้า Dify แทนการใช้ IP address โดยตรง

ขั้นตอนที่ 1: รับ Dify และไฟล์ Compose

Dify เก็บการตั้งค่า Docker ไว้ใน repository หลัก ให้ทำการ clone รุ่นล่าสุด (ไม่ใช่ branch สำหรับพัฒนา) แล้วย้ายเข้าไปยังไดเรกทอรี docker:

git clone --branch "$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | jq -r .tag_name)" https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env

หากการ clone ล้มเหลวด้วยข้อผิดพลาด "Remote branch null" แสดงว่าการค้นหาผ่าน GitHub API ไม่พบข้อมูล ให้เลือกเวอร์ชันจากหน้า releases แล้วระบุให้กับ --branch ด้วยตนเอง

ไฟล์ .env คือการตั้งค่าหลัก โปรดอ่านไฟล์นี้ก่อนเริ่มดำเนินการใดๆ ค่าที่สำคัญที่สุดในลำดับแรกคือค่าที่กำหนดรหัสผ่านและข้อมูลลับ ได้แก่ SECRET_KEY, รหัสผ่าน Postgres และรหัสผ่าน Redis ส่วน SECRET_KEY จะว่างเปล่ามาตั้งแต่ต้น หากคุณปล่อยไว้เช่นนั้น Dify จะสร้างคีย์ขึ้นมาเองและเก็บไว้ในไดเรกทอรีจัดเก็บข้อมูล สำหรับรหัสผ่านนั้นเป็นอีกเรื่องหนึ่ง ไฟล์ตัวอย่างได้กำหนด difyai123456 เดียวกันสำหรับทั้ง Postgres และ Redis รวมถึงกำหนดคีย์ที่ตายตัวและเป็นที่รู้จักโดยทั่วไปสำหรับ code sandbox, plugin daemon และ Weaviate การปล่อยให้ค่าเหล่านี้เป็นไปตามที่มากับซอฟต์แวร์ถือเป็นสาเหตุที่พบบ่อยที่สุดที่ทำให้ Dify ที่ติดตั้งเองถูกบุกรุก หากคุณต้องการกำหนด secret key ของคุณเอง ให้สร้างขึ้นมาใหม่:

openssl rand -base64 42

นำค่าที่ได้ไปวางใน SECRET_KEY และกำหนดค่าที่รัดกุมและไม่ซ้ำใครสำหรับทุกฟิลด์รหัสผ่านและคีย์ในไฟล์ นอกจากนี้รหัสผ่าน Redis ยังปรากฏอยู่ใน CELERY_BROKER_URL ด้วย ดังนั้นต้องเปลี่ยนค่าในไฟล์นั้นด้วย มิฉะนั้น worker จะไม่สามารถเชื่อมต่อกับ Redis ได้

ขั้นตอนที่ 2: เริ่มการทำงาน

สั่งให้ stack เริ่มทำงาน:

docker compose up -d

docker-compose up -d

การรันครั้งแรกจะมีการดึง image หลายรายการและเริ่มต้นฐานข้อมูล ดังนั้นโปรดรอสักครู่ ตรวจสอบว่า container ทั้งหมดอยู่ในสถานะ healthy:

docker compose ps

docker-compose ps

บริการที่ทำงานต่อเนื่องทุกตัวควรมีสถานะเป็น running ส่วนงานกำหนดสิทธิ์ที่รันครั้งเดียวจะหยุดทำงานหลังจากเสร็จสิ้นภารกิจ Dify ให้บริการหน้าเว็บผ่าน container nginx ที่มาพร้อมกันบนพอร์ต 80 โดยค่าเริ่มต้น ในการเข้าใช้งานครั้งแรกที่ http://YOUR_SERVER/install คุณจะต้องสร้างบัญชีผู้ดูแลระบบ ให้ดำเนินการทันทีโดยไม่ชักช้า ก่อนที่ผู้อื่นจะเข้าถึงพอร์ตดังกล่าวได้ เนื่องจากจนกว่าบัญชีนั้นจะถูกสร้างขึ้น ใครก็ตามที่โหลดหน้านี้สามารถอ้างสิทธิ์และเข้าควบคุม instance ของคุณได้

ขั้นตอนที่ 3: อย่าเปิดเผยบริการโดยตรง ให้ติดตั้ง TLS และไฟร์วอลล์ไว้ด้านหน้า

นี่คือจุดที่การติดตั้งแบบรวดเร็วส่วนใหญ่มักหยุดลง และเป็นจุดที่เหตุการณ์ไม่พึงประสงค์ส่วนใหญ่เริ่มต้นขึ้น Nginx ของ Dify เองนั้นฟังการเชื่อมต่อที่พอร์ต 80 แบบไม่มีการเข้ารหัสบนทุกอินเทอร์เฟซ และเปิดพอร์ต 443 ไว้ด้วย คุณไม่ควรปล่อยให้ข้อมูลการเข้าสู่ระบบของผู้ดูแลระบบและคีย์ของโมเดลถูกส่งผ่าน HTTP แบบปกติ และคุณไม่ควรให้บริการภายในเข้าถึงได้จากภายนอก

ให้จำกัดการเข้าถึงเซิร์ฟเวอร์ด้วยไฟร์วอลล์แบบ default-deny ที่อนุญาตเฉพาะ SSH และทราฟฟิกเว็บเท่านั้น:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

โปรดจำไว้ว่าไฟร์วอลล์ที่ครอบคลุมเฉพาะ IPv4 อาจทิ้งพอร์ตเดิมให้เปิดอยู่บน IPv6 ซึ่งเป็น ช่องโหว่ของไฟร์วอลล์ IPv6 ที่ทำให้ผู้ใช้งานแบบ self-host จำนวนมากพลาดท่า ให้ตรวจสอบว่าทั้งสอง stack ถูกกรองแล้ว นอกจากนี้ พอร์ตที่ Docker เปิดใช้งานจะถูกจัดการโดยกฎไฟร์วอลล์ของ Docker เอง ไม่ใช่ ufw และค่าเริ่มต้นของ stack จะเปิดพอร์ตดีบั๊กของ plugin daemon ที่พอร์ต 5003 บนทุกอินเทอร์เฟซ ให้ตั้งค่า EXPOSE_PLUGIN_DEBUGGING_PORT ใน .env เป็น 127.0.0.1:5003 เว้นแต่คุณจะต้องการดีบั๊กปลั๊กอินจากเครื่องอื่นจริงๆ

สำหรับ TLS วิธีที่สะอาดที่สุดคือการผูกพอร์ตเว็บของ Dify ไว้กับ loopback และรัน reverse proxy พร้อมใบรับรอง Let's Encrypt ไว้ด้านหน้า เพื่อให้สิ่งเดียวที่อยู่บนอินเทอร์เน็ตสาธารณะคือพร็อกซีที่สื่อสารผ่าน HTTPS เท่านั้น .env ของ Dify ช่วยให้คุณเปลี่ยนพอร์ตที่เปิดเผยได้ ให้ตั้งค่าให้ผูกกับ 127.0.0.1 และชี้พร็อกซีของคุณไปที่พอร์ตนั้น ทำเช่นเดียวกันกับ EXPOSE_NGINX_SSL_PORT เนื่องจาก Nginx ของ Dify จะจองพอร์ตโฮสต์ 443 ไว้โดยค่าเริ่มต้น และพร็อกซีของคุณจำเป็นต้องใช้พอร์ตนี้ แนวคิดเรื่องการเสริมความปลอดภัยให้กับ agent ใน การรัน AI agent บน VPS อย่างปลอดภัย ก็สามารถนำมาปรับใช้ได้เช่นกัน: ให้เก็บส่วนประกอบต่างๆ ไว้บน loopback, เปิดเผยเฉพาะสิ่งที่จำเป็นต้องเป็นสาธารณะ และให้ประตูด่านหน้าที่มีความปลอดภัยสูงเป็นผู้จัดการเรื่อง TLS ในกรณีที่อินเทอร์เฟซของเครื่องมือมีไว้สำหรับคุณเพียงคนเดียวและไม่จำเป็นต้องใช้ใบรับรอง ให้ข้ามการใช้พร็อกซีและเข้าถึงผ่าน SSH tunnel แทน เช่นเดียวกับที่ การทำ self-host เครื่องมือสแกนความปลอดภัย open-kritt เก็บแดชบอร์ดไว้ที่ loopback และส่งต่อมายังแล็ปท็อปของคุณแทนที่จะเปิดเผยสู่สาธารณะ หากทีมงานทั้งหมดต้องการใช้ Dify แต่ไม่ต้องการเปิดเผยสู่สาธารณะ การใช้ overlay network จะช่วยขยายแนวคิดนี้ให้กว้างกว่าแค่แล็ปท็อปเครื่องเดียว: การประกาศ subnet ส่วนตัวของเซิร์ฟเวอร์ไปยัง tailnet ของคุณ ช่วยให้อุปกรณ์ที่ได้รับอนุญาตทุกเครื่องเข้าถึงตัวสร้างบนที่อยู่ส่วนตัวได้ ในขณะที่ไฟร์วอลล์ยังคงปิดกั้นทุกอย่างยกเว้น SSH หากคุณดูแลเซิร์ฟเวอร์นี้ผ่าน coding agent แทนการทำด้วยตนเอง ให้กำหนดขอบเขตว่ามันสามารถทำอะไรได้บ้างโดยไม่ต้องมีการควบคุมดูแลก่อนที่จะมอบสิทธิ์ให้มัน เพราะ โหมดสิทธิ์ที่คุณตั้งค่าไว้ใน Claude Code จะเป็นตัวตัดสินว่ามันจะหยุดถามคุณก่อนที่จะเขียนทับ .env หรือรีสตาร์ท stack หรือไม่ หากคุณจบลงด้วยการเปิด session หนึ่งเพื่อดู log ของคอนเทนเนอร์ในขณะที่อีก session หนึ่งแก้ไข config ของพร็อกซี ทั้งสอง session สามารถส่งข้อความถึงกันได้บนเครื่องเดียวกัน ซึ่งสะดวกกว่าการคัดลอกผลลัพธ์ระหว่างเทอร์มินัลทุกครั้งที่คุณรีสตาร์ท stack

ขั้นตอนที่ 4: การรักษาความปลอดภัยด้วยการอัปเดตแพตช์

Dify มีการพัฒนาอย่างรวดเร็วและการอัปเดตจะรวมถึงการแก้ไขช่องโหว่ด้านความปลอดภัย เนื่องจากคุณได้ clone release tag มา การอัปเดตจึงหมายถึงการ checkout ไปยัง tag ถัดไปแทนการดึงข้อมูลจาก branch ให้สำรองข้อมูลฐานข้อมูลก่อน จากนั้นดำเนินการจากไดเรกทอรี docker:

docker compose down
git fetch --tags
git checkout NEW_VERSION
docker compose pull
docker compose up -d

การทำ database migration จะทำงานโดยอัตโนมัติเมื่อเริ่มระบบ และบางรายการไม่สามารถย้อนกลับได้ นี่คือเหตุผลที่ต้องสำรองข้อมูลก่อนเสมอ โปรดอ่านบันทึกประจำรุ่น (release notes) ก่อนการอัปเกรดทุกครั้ง ไม่ใช่เฉพาะรุ่นใหญ่เท่านั้น Dify ระบุว่าขั้นตอนการอัปเกรดจะแตกต่างกันไปในแต่ละรุ่น ตัวอย่างเช่น บันทึกของรุ่น 1.17.1 (กันยายน 2026) ระบุว่าผู้ที่ใช้งาน Weaviate แบบ bundled ร่วมกับข้อมูลที่มีอยู่เดิม ห้ามข้ามไปที่รุ่นนั้นโดยตรง แต่ให้ค่อยๆ อัปเกรดผ่านรุ่นย่อยแต่ละรุ่น นอกจากนี้ Dify ยังมีการเปลี่ยนแปลง schema ใน .env ระหว่างรุ่น ดังนั้นให้เปรียบเทียบ .env.example กับ .env ของคุณหลังจาก checkout tag ใหม่ และนำการตั้งค่าของคุณไปปรับใช้ เนื่องจากตัวแปรใหม่ที่คุณยังไม่ได้ตั้งค่าอาจทำให้ container ไม่สามารถเริ่มทำงานได้

ขั้นตอนที่ 5: สำรองข้อมูลที่ไม่สามารถสร้างใหม่ได้

ข้อมูลสองส่วนบน Dify box ที่ไม่สามารถหาทดแทนได้คือ ฐานข้อมูล Postgres ซึ่งเก็บแอปพลิเคชัน ผู้ใช้ และการตั้งค่าของคุณ และ volume ที่เก็บเอกสารที่อัปโหลดรวมถึงดัชนีเวกเตอร์ ข้อมูลทั้งสองส่วนนี้อยู่ใน Docker volumes ภายใต้ไดเรกทอรี docker ให้ทำ snapshot ข้อมูลเหล่านี้ตามกำหนดเวลา และคัดลอก snapshot ออกจากเซิร์ฟเวอร์ เนื่องจาก snapshot เหล่านี้มีทั้ง API key ของโมเดลและเอกสารที่อัปโหลดทั้งหมดรวมอยู่ในไฟล์เดียว คุณจึงควรเข้ารหัสไฟล์เหล่านั้นก่อนนำออกจากเซิร์ฟเวอร์ ด้วยเหตุผลเดียวกับที่ การสำรองข้อมูล Vaultwarden กลายเป็นจุดอ่อนของเซิร์ฟเวอร์รหัสผ่านที่ปลอดภัย API key ของโมเดลอาจขอใหม่ได้ แต่แอปพลิเคชันที่คุณใช้เวลาสร้างมาเป็นสัปดาห์นั้นไม่สามารถทำได้ เหตุผลเดียวกันนี้ยังใช้กับ agent ทุกตัวที่มีสถานะต้องคงอยู่ยาวนานกว่าเครื่องที่รันมัน: การทำให้ KiroCrew รันเป็น container ตลอดเวลา ขึ้นอยู่กับการทำ snapshot ของหน่วยความจำและตารางเวลาที่จะสูญหายไปในการรีบูตครั้งถัดไป

เมื่อคุณต้องการให้ agent ที่คุณสร้างขึ้นที่นี่เข้าถึงข้อมูลนอกเหนือจากชุดข้อมูลของคุณเองและค้นหาข้อมูลบนเว็บแบบสด การชี้เป้าไปยัง instance ของ SearXNG ที่โฮสต์เอง จะช่วยให้กระแสข้อมูลการค้นหาอยู่บนฮาร์ดแวร์ที่คุณควบคุม อย่างไรก็ตาม ควรศึกษาข้อมูลเกี่ยวกับช่องโหว่ prompt injection ที่อาจเกิดขึ้นก่อนเปิดใช้งาน สำหรับ agent ที่มีความเป็นอิสระมากขึ้นและสามารถรันโค้ดได้ โปรดดู การโฮสต์ Agent Zero ด้วยตนเอง และ การสร้าง AI agent ของคุณเองบน VPS ซึ่งครอบคลุมถึงพื้นฐานที่สำคัญสำหรับระบบเหล่านี้ทั้งหมด

FAQ

ความต้องการของระบบสำหรับการ self-host Dify มีอะไรบ้าง?

Dify ระบุความต้องการขั้นต่ำไว้ที่ RAM 4 GiB และ CPU 2 คอร์ พร้อมด้วย Docker Compose เวอร์ชัน 2.24.0 หรือใหม่กว่า ค่ามาตรฐานนี้สะท้อนถึงขนาดของ stack เริ่มต้น ซึ่งประกอบด้วยคอนเทนเนอร์ที่ทำงานต่อเนื่อง 15 รายการ และงานเริ่มต้นระบบหนึ่งครั้ง (ข้อมูล ณ เดือนตุลาคม 2026) ควรจัดสรรพื้นที่ดิสก์ให้เพียงพอสำหรับเอกสารที่อัปโหลดและ vector index รวมถึงเพิ่มหน่วยความจำหากมีบริการอื่นใช้งานบนเซิร์ฟเวอร์เดียวกัน

การเปิดพอร์ต 80 ให้ Dify โดยตรงมีความปลอดภัยหรือไม่?

ไม่ปลอดภัย เว็บเซิร์ฟเวอร์ที่มาพร้อมกับ Dify ทำงานบน HTTP ปกติ ซึ่งเป็นช่องทางเข้าสู่หน้าล็อกอินผู้ดูแลระบบและ API key ของโมเดลของคุณ คุณควรติดตั้ง reverse proxy พร้อมใบรับรองจาก Let's Encrypt ไว้ด้านหน้า ผูกพอร์ตของ Dify ไว้กับ loopback เท่านั้น และให้เฉพาะ HTTPS proxy ที่เชื่อมต่อกับอินเทอร์เน็ต นอกจากนี้ควรใช้งานร่วมกับ firewall ที่ตั้งค่า default-deny ซึ่งครอบคลุมทั้ง IPv4 และ IPv6

วิธีการอัปเดต Dify ที่ติดตั้งด้วยตนเองทำอย่างไร?

ให้สำรองข้อมูลฐานข้อมูลก่อน จากนั้นเข้าไปที่ไดเรกทอรี docker แล้วรันคำสั่ง docker compose down, git fetch --tags, git checkout ตามด้วยแท็กของรุ่นใหม่, docker compose pull และ docker compose up -d โปรดอ่านบันทึกประจำรุ่น (release notes) ก่อนเสมอ เนื่องจากขั้นตอนการอัปเกรดอาจแตกต่างกันในแต่ละรุ่น การย้ายข้อมูล (migration) อาจไม่สามารถย้อนกลับได้ และบางครั้ง Dify อาจเพิ่มตัวแปร .env ใหม่ ซึ่งหากขาดไปอาจทำให้คอนเทนเนอร์ไม่สามารถเริ่มทำงานได้

สิ่งแรกที่ต้องทำหลังจากติดตั้ง Dify คืออะไร?

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