SSD Nodes Learn Hosting plans →
คู่มือ Matt Connorโดย Matt Connor · อัปเดตเมื่อ 2026-08-28

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

เรียนรู้วิธีติดตั้ง Dify บน VPS ด้วย Docker Compose โดยใช้ RAM ขั้นต่ำ 4 GB พร้อมคำแนะนำการตั้งค่าไฟล์ .env และการสร้างบัญชีผู้ดูแลระบบที่ /install เพื่อป้องกันการเข้าถึงจากบุคคลภายนอก

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

Dify เป็นแพลตฟอร์มแบบ self-host สำหรับสร้างแอปพลิเคชันบนพื้นฐานของโมเดลภาษาขนาดใหญ่ (LLM) คุณจะได้รับเว็บอินเทอร์เฟซสำหรับออกแบบแอปแชท, เอเจนต์ และไปป์ไลน์การดึงข้อมูล (retrieval pipelines) รวมถึง API สำหรับเรียกใช้งานจากโค้ดของคุณเอง และเป็นศูนย์กลางในการจัดการ prompt, ชุดข้อมูล และคีย์ของโมเดล นี่คือเครื่องมือที่ทีมขนาดเล็กเลือกใช้เพื่อให้ทุกคนทำงานบนฐานข้อมูลส่วนตัวที่ใช้ร่วมกัน แทนที่จะกระจาย API key ไว้ตามสคริปต์ต่างๆ

การรันระบบด้วยตนเองหมายถึงต้องดูแลหลายส่วนที่ทำงานร่วมกัน Dify ถูกแจกจ่ายเป็นชุดของ Docker container ได้แก่ API server, background worker, web frontend, Postgres database, Redis cache และ vector database ซึ่งเชื่อมต่อกันด้วย Docker Compose ทั้งหมดนี้ซับซ้อนกว่า binary เดียว แต่ Compose จัดการการเชื่อมต่อให้ และ VPS ที่มี RAM เหลือประมาณสองสาม gigabytes ก็สามารถรันได้อย่างราบรื่น หาก VPS นั้นต้องรันบริการอื่นด้วย ควรกำหนดขนาดจากค่าที่วัดได้จริง ไม่ใช่จากตัวเลขที่ประกาศไว้ เพราะ ขีดจำกัด RAM จริงของ PhotoPrism และ Immich สูงกว่าค่าขั้นต่ำที่เผยแพร่ไว้อย่างมาก และ photo server ที่ใช้เครื่องเดียวกันจะทำให้ database และ vector store ของ Dify ขาดทรัพยากรก่อน

การแย่งใช้ CPU ก็ส่งผลในลักษณะเดียวกัน: คลัง Jellyfin ที่ปรับหน้าตาให้เหมือนร้านวิดีโอในยุค 90s แทบไม่ใช้ทรัพยากรในการให้บริการขณะผู้ใช้เพียงเรียกดู artwork แต่ทันทีที่มีการเริ่ม transcode คิวของ worker ของ Dify จะต้องรอตามหลังงานนั้น ข้อดีคือจำนวน container ของ Dify คงที่ ไม่ว่าคุณจะสร้างแอปไว้กี่รายการ รูปแบบค่าใช้จ่ายจึงควบคุมได้ง่ายกว่า OpenBot ซึ่งให้ AI coworker แต่ละรายมี container และ browser เป็นของตนเอง และการเพิ่มผู้ใช้งานใหม่แต่ละรายจะดันขีดจำกัด RAM ขั้นต่ำให้สูงขึ้นอีกครั้ง

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

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

คุณต้องมี VPS ที่รัน Ubuntu 24.04 พร้อมติดตั้ง Docker และ Docker Compose plugin รวมถึงผู้ใช้ที่มีสิทธิ์ sudo หรือเป็นสมาชิกของกลุ่ม docker หากคุณยังไม่คุ้นเคยกับ Docker สามารถศึกษา พื้นฐานของ Docker Compose บน VPS ซึ่งครอบคลุมขั้นตอนการติดตั้งและคำสั่งหลักที่คู่มือนี้ใช้เป็นพื้นฐาน นอกจากนี้ควรมีชื่อโดเมนที่ชี้มายังเซิร์ฟเวอร์ของคุณ เนื่องจากคุณควรใช้งาน TLS หน้า Dify แทนการเรียกผ่าน IP address โดยตรง

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

Dify เก็บการตั้งค่า Docker ไว้ใน repository หลัก ให้ทำการ clone repository ดังกล่าวและย้ายเข้าไปยังไดเรกทอรี docker:

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env

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

openssl rand -base64 42

นำค่าที่ได้ไปวางใน SECRET_KEY และกำหนดค่ารหัสผ่านที่แข็งแกร่งและไม่ซ้ำกันในทุกช่องรหัสผ่านภายในไฟล์ดังกล่าว

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

เริ่มการทำงานของ stack ด้วยคำสั่ง:

docker compose up -d

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

docker compose ps

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

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

นี่คือจุดที่การติดตั้งแบบรวดเร็วส่วนใหญ่มักหยุดลง และเป็นจุดที่เหตุการณ์ไม่พึงประสงค์ส่วนใหญ่เริ่มต้นขึ้น nginx ของ Dify จะฟังการเชื่อมต่อที่พอร์ต 80 แบบไม่มีการเข้ารหัสบนทุกอินเทอร์เฟซ คุณคงไม่ต้องการให้ข้อมูลการเข้าสู่ระบบของผู้ดูแลระบบและคีย์โมเดลของคุณถูกส่งผ่าน 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 ถูกกรองการเข้าถึงแล้ว

สำหรับ TLS วิธีที่เป็นระเบียบที่สุดคือ bind พอร์ตเว็บของ Dify กับ loopback แล้วใช้ reverse proxy ที่มี certificate จาก Let's Encrypt อยู่ด้านหน้า ดังนั้นสิ่งเดียวที่เปิดอยู่บน public internet คือ proxy ที่สื่อสารผ่าน HTTPS .env ของ Dify ใช้เปลี่ยนพอร์ตที่เปิดให้เข้าถึงได้ ให้ตั้งค่าให้ bind กับ 127.0.0.1 แล้วกำหนด proxy ให้ส่งต่อไปยังจุดดังกล่าว แนวทาง hardening สำหรับ agent ใน การรัน AI agent อย่างปลอดภัยบน VPS ใช้กับกรณีนี้เช่นกัน: ให้ส่วนประกอบที่มีการรับส่งข้อมูลทำงานบน loopback, เปิดเผยต่อสาธารณะเฉพาะสิ่งที่จำเป็น และให้ front door ที่ผ่านการ harden แล้วเป็นจุดเดียวที่สื่อสารผ่าน TLS หาก interface ของเครื่องมือมีไว้ใช้เฉพาะคุณและไม่จำเป็นต้องมี certificate เลย ให้ข้าม proxy แล้วเข้าถึงผ่าน SSH tunnel ตามแนวทางใน การ self-host open-kritt security scanner ซึ่ง bind dashboard ไว้กับ loopback และ forward ไปยัง laptop ของคุณ แทนการเปิดเผย dashboard ต่อสาธารณะ หากทั้งทีมต้องใช้ Dify แต่ไม่ต้องการให้ public internet เข้าถึง overlay network จะขยายแนวคิดนี้ให้รองรับอุปกรณ์มากกว่า laptop เครื่องเดียว: การประกาศ private subnet ของเซิร์ฟเวอร์ไปยัง tailnet ทำให้อุปกรณ์ที่ได้รับอนุญาตทุกเครื่องเข้าถึง builder ผ่าน private address ได้ ขณะที่ firewall ยังคงปิดกั้นทุกอย่างยกเว้น SSH หากคุณดูแลเครื่องนี้ผ่าน coding agent แทนการดำเนินการด้วยตนเอง ควรกำหนดก่อนว่าจะอนุญาตให้ agent ทำงานโดยไม่มีการกำกับดูแลได้มากเพียงใด ก่อนมอบสิทธิ์ให้ เพราะ permission mode ที่คุณตั้งให้ Claude Code เป็นตัวกำหนดว่า agent จะหยุดถามก่อนเขียน .env ใหม่หรือ restart stack หรือไม่ หากมี session หนึ่ง tail container logs ขณะที่อีก session แก้ไข proxy config session ทั้งสองสามารถส่งข้อความหากันบนเครื่องเดียวกันได้ ซึ่งสะดวกกว่าการคัดลอก output ระหว่าง terminal ทุกครั้งที่ restart stack

ขั้นตอนที่ 4: การอัปเดตแพตช์อยู่เสมอ

Dify มีการพัฒนาอย่างรวดเร็วและมีการอัปเดตเพื่อแก้ไขปัญหาด้านความปลอดภัยอยู่เสมอ การอัปเดตทำได้โดยการดึงข้อมูลใหม่ (pull) และเริ่มการทำงานของคอนเทนเนอร์ใหม่จากไดเรกทอรี docker:

git pull
docker compose pull
docker compose up -d

โปรดอ่านบันทึกประจำรุ่น (release notes) ก่อนทำการอัปเกรดเวอร์ชันหลัก เนื่องจาก Dify อาจมีการเปลี่ยนแปลงโครงสร้าง .env ระหว่างรุ่น ซึ่งตัวแปรใหม่ที่คุณยังไม่ได้ตั้งค่าอาจส่งผลให้คอนเทนเนอร์ไม่สามารถเริ่มทำงานได้

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

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

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

FAQ

ความต้องการของระบบในการโฮสต์ Dify ด้วยตนเองมีอะไรบ้าง

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

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

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

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

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

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

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