Self-Hosting Windmill ในปี 2026: Worker, PostgreSQL, Isolation และการอัปเกรดอย่างปลอดภัย
บทความต่อยอดฉบับปัจจุบันที่เน้นการใช้งานจริง โดยแปลงเอกสารจากผู้ให้บริการให้เป็นการควบคุมงาน การตัดสินใจย้ายระบบ และเกณฑ์การปล่อยระบบที่ตรวจสอบได้
สิ่งที่เปลี่ยนไปในปี 2026
เรากลับมาทบทวนหัวข้อนี้เพราะขอบเขตการดำเนินงานเปลี่ยนไป หลักการที่ใช้ได้ในระยะยาวยังคงมีคุณค่า แต่เวอร์ชันปัจจุบันทำให้ทางลัดบางอย่างในอดีตไม่ครบถ้วนหรือมีความเสี่ยง บทความนี้เริ่มจากเอกสารทางการที่มีอยู่ ณ วันที่ 14 กรกฎาคม 2026 แยกข้อเท็จจริงออกจากการตัดสินใจเฉพาะระบบ และถือว่าการแก้ไขค่ากำหนดทุกครั้งเป็นการเปลี่ยนแปลงระบบ production ที่ต้องควบคุม
แหล่งข้อมูลปฐมภูมิปัจจุบัน
แนวทางใช้บทความฉบับปรับปรุง
เริ่มจากอ่านแหล่งข้อมูลปฐมภูมิ บันทึกเวอร์ชันที่ใช้งานจริง และกำหนดผลลัพธ์ที่สังเกตได้ก่อนแก้ไขค่าใด ๆ ทดสอบการเปลี่ยนแปลงที่เล็กที่สุดและย้อนกลับได้ในสภาพแวดล้อมที่ใกล้เคียงของจริง คำสั่งที่ทำงานสำเร็จไม่ใช่เกณฑ์ยอมรับเพียงอย่างเดียว ต้องตรวจสอบสถานะบริการ ความสมบูรณ์ของข้อมูล latency ขอบเขตความปลอดภัย และเวลาที่ใช้ในการ rollback ด้วย ลำดับการวินิจฉัยจากบทความเดิมที่ยังใช้ได้จะคงไว้เป็นพื้นฐาน แต่ตัวอย่างที่ขึ้นกับเวอร์ชันต้องเทียบกับเอกสารปัจจุบันเสมอ
ก่อนปล่อยระบบ ให้บันทึกความแตกต่างของ configuration เตรียม backup หรือ snapshot ที่เคยทดสอบการกู้คืนแล้ว และระบุคำสั่งสำหรับย้อนกลับการเปลี่ยนแปลง มอบหมายคนหนึ่งให้เฝ้าดูช่วง production แรก และอีกคนให้มีอำนาจอนุมัติการยกระดับปัญหาเมื่อค่าชี้วัดเปลี่ยนไปในทิศทางที่ไม่ถูกต้อง Alert ควรอธิบายความเสี่ยงที่ผู้ใช้มองเห็น ไม่ใช่เพียงระบุ component ที่ส่งสัญญาณ ในช่วง readback ให้เปรียบเทียบอัตราข้อผิดพลาด ความลึกของ queue การใช้ทรัพยากรจนเต็ม latency ในการประมวลผล และความครบถ้วนของข้อมูลกับ baseline ที่ตกลงกันไว้ ต้องตรวจสอบทั้งค่าเฉลี่ยและพฤติกรรมส่วนปลาย เพราะค่าเฉลี่ยที่ดูคงที่อาจซ่อนความล้มเหลวที่กระทบงานส่วนน้อยแต่สำคัญ ปิดการเปลี่ยนแปลงได้ต่อเมื่อ delayed job, retry, scheduled task และ downstream export ทำงานครบแล้ว การแก้ไขด้วยมือทุกขั้นตอนต้องถูกบันทึก หากไม่มีใน runbook แสดงว่า runbook ยังไม่สมบูรณ์
- การตัดสินใจ Self-Hosting: เมื่อ SaaS มีค่าใช้จ่ายมากกว่าโครงสร้างพื้นฐานของตัวเอง
- การกู้คืนจากภัยพิบัติสำหรับบริการที่โฮสต์เอง: กลยุทธ์การสำรองข้อมูลของเรา
- การโฮสต์ Database หลายอินสแตนซ์บนเซิร์ฟเวอร์เครื่องเดียว
พื้นฐานการดำเนินงาน
แพลตฟอร์มอัตโนมัติสำหรับเวิร์กโฟลว์เป็นสิ่งจำเป็นสำหรับทีมพัฒนาสมัยใหม่ แต่โซลูชันคลาวด์อย่าง Windmill Cloud อาจมีราคาแพงขึ้นเมื่อการใช้งานเติบโต เราจะแสดงวิธีตั้งค่า Windmill instance ของคุณเองบน Ubuntu ด้วย Docker Compose และการบูรณาการ Traefik โดยเอาชนะปัญหาการยืนยันตัวตน PostgreSQL ที่สำคัญซึ่งอาจทำให้การติดตั้งของคุณล้มเหลว
สิ่งที่คุณจะสร้าง
เมื่อจบบทเรียนนี้ คุณจะมี:
- การติดตั้ง Windmill ที่ทำงานได้อย่างสมบูรณ์พร้อม HTTPS
- ใบรับรอง SSL อัตโนมัติผ่าน Let’s Encrypt ผ่าน Traefik
- ฐานข้อมูล PostgreSQL ระดับ production พร้อมการยืนยันตัวตนที่เหมาะสม
- การกำหนดค่า worker ที่เพิ่มประสิทธิภาพทรัพยากร
- บูรณาการกับโครงสร้างพื้นฐาน Docker ที่มีอยู่
- การตั้งค่าระดับ production สำหรับระบบอัตโนมัติเวิร์กโฟลว์ระดับมืออาชีพ
ค่าใช้จ่ายรายเดือน: €4.51 (เซิร์ฟเวอร์ CX11) + ค่าโดเมน – โครงสร้างพื้นฐานเดียวกันที่สามารถรองรับเครื่องมืออัตโนมัติหลายตัว
ข้อกำหนดเบื้องต้น
- เซิร์ฟเวอร์ Ubuntu 24.04 LTS ที่ติดตั้ง Docker และ Docker Compose แล้ว
- การตั้งค่า Traefik reverse proxy ที่มีอยู่ (ดูคู่มือการตั้งค่า n8n ของเราสำหรับการกำหนดค่า Traefik)
- ชื่อโดเมนที่ชี้ไปยัง IP เซิร์ฟเวอร์ของคุณ
- แนะนำ RAM อย่างน้อย 4GB และ 2 vCPUs
- การเข้าถึง SSH และความรู้พื้นฐาน command line
ทำความเข้าใจ Windmill
Windmill เป็นเอนจินเวิร์กโฟลว์โอเพนซอร์สที่ให้:
- ตัวแก้ไขเวิร์กโฟลว์แบบ visual พร้อมรองรับ TypeScript/Python/Go
- การจัดตาราง job และการจัดการการรัน
- ความสามารถในการบูรณาการ API
- ฟีเจอร์การทำงานร่วมกันเป็นทีม
- โฮสต์ด้วยตัวเองได้โดยไม่มีขีดจำกัดการใช้งาน
ต่างจากแนวทางแบบ node ของ n8n ตรงที่ Windmill เน้นเวิร์กโฟลว์ที่ใช้โค้ดเป็นหลักด้วยสภาพแวดล้อมการพัฒนาที่ทรงพลัง
ขั้นตอนที่ 1: การเตรียมเซิร์ฟเวอร์และโครงสร้างไดเรกทอรี
ก่อนอื่น มาเตรียมสภาพแวดล้อมเซิร์ฟเวอร์ของเรา เราจะใช้หลักการตั้งชื่อตามอาหารสำหรับ Windmill instances เพื่อหลีกเลี่ยงการขัดแย้ง:
หลักการตั้งชื่อ: ใช้ชื่ออาหารง่ายๆ สำหรับ Windmill instance หลายตัว:
- Instance แรก: pizza
- Instance เพิ่มเติม: pasta, salad, soup, burger ฯลฯ
- ช่วยหลีกเลี่ยงการขัดแย้งและทำให้การจัดการง่ายขึ้น
ขั้นตอนที่ 2: การกำหนดค่าสภาพแวดล้อม
สร้างไฟล์สภาพแวดล้อมที่ปลอดภัยด้วยข้อมูลรับรองที่เหมาะสม:
สำคัญ: แทนที่ windmill.yourdomain.com ด้วยโดเมนจริงของคุณ!
ขั้นตอนที่ 3: การกำหนดค่า Docker Compose
สร้างการกำหนดค่า Docker Compose หลัก:
สำคัญ: อัปเดตโดเมนใน Traefik labels ให้ตรงกับการตั้งค่าของคุณ!
ขั้นตอนที่ 4: ปัญหารหัสผ่าน PostgreSQL (ปัญหาสำคัญ)
นี่คือจุดที่การติดตั้ง Windmill ส่วนใหญ่ล้มเหลว และต้องใช้การแก้ไขปัญหาอย่างมากเพื่อระบุสาเหตุหลัก:
ปัญหา: อักขระพิเศษในรหัสผ่าน
เมื่อใช้ openssl rand -base64 32 เพื่อสร้างรหัสผ่าน คุณมักจะได้อักขระพิเศษเช่น =, @, #, % ฯลฯ อักขระเหล่านี้ทำให้การยืนยันตัวตน PostgreSQL ล้มเหลวในสภาพแวดล้อม Docker แม้จะ escape อย่างถูกต้องแล้วก็ตาม
ตัวอย่างรหัสผ่านที่มีปัญหา:
โซลูชัน: รหัสผ่านแบบ Hex เท่านั้น
ใช้รหัสผ่านแบบ hex เท่านั้นที่ไม่มีอักขระพิเศษ:
ปัญหาการกำหนดค่า PostgreSQL เพิ่มเติม
- การกำหนดค่าผู้ใช้: ใช้ postgres เป็นผู้ใช้ค่าเริ่มต้น ไม่ใช่ผู้ใช้กำหนดเองเช่น windmill_user
- การคงอยู่ของ Volume: PostgreSQL จะไม่สนใจตัวแปรสภาพแวดล้อม POSTGRES_PASSWORD เมื่อ data volumes ที่มีอยู่มีข้อมูลรับรองที่แตกต่างกัน
- รูปแบบ URL: รวม ?sslmode=disable ใน URL ฐานข้อมูลสำหรับสภาพแวดล้อม Docker
ขั้นตอนที่ 5: การติดตั้งและเริ่มต้น
มาติดตั้ง Windmill ด้วยการกำหนดค่าที่แก้ไขแล้วของเรา:
คุณควรเห็นผลลัพธ์เช่น:
ขั้นตอนที่ 6: การแก้ไขปัญหาที่พบบ่อย
ปัญหา 1: การยืนยันตัวตน PostgreSQL ล้มเหลว
อาการ:
วิธีแก้ไข:
ปัญหา 2: Container ไม่เริ่มต้น
อาการ:
- Container ออกทันที
- ข้อผิดพลาดการจัดสรรทรัพยากร
วิธีแก้ไข:
ปัญหา 3: ปัญหาใบรับรอง SSL
อาการ:
- HTTPS ไม่ทำงาน
- ข้อผิดพลาดใบรับรอง
วิธีแก้ไข:
ขั้นตอนที่ 7: การเข้าถึงและการตั้งค่าเบื้องต้น
เมื่อการติดตั้งเสร็จสมบูรณ์:
- เข้าถึง Windmill: https://windmill.yourdomain.com
- ข้อมูลรับรองค่าเริ่มต้น:
อีเมล: [email protected]
- รหัสผ่าน: changeme
- ดำเนินการตั้งค่าให้เสร็จ:
เปลี่ยนรหัสผ่าน admin
- กำหนดค่า base URL
- ตั้งค่าบัญชีผู้ใช้
ขั้นตอนที่ 8: การเพิ่มประสิทธิภาพทรัพยากร
การจัดสรรหน่วยความจำ (สำหรับเซิร์ฟเวอร์ 8GB)
การกำหนดค่าของเราจัดสรรทรัพยากรอย่างมีประสิทธิภาพ:
- Windmill Server: ~800MB
- Windmill Worker: 2GB (จำกัด)
- PostgreSQL: ~500MB
- สำรองสำหรับระบบ: ~4.7GB
การจัดสรร CPU (สำหรับเซิร์ฟเวอร์ 4 vCPU)
- Worker: 1 vCPU (จำกัด)
- บริการอื่นๆ: 3 vCPUs (แชร์)
กฎการขยายขนาด: 1 worker ต่อ vCPU พร้อม RAM 1-2GB แต่ละตัว
ขั้นตอนที่ 9: การเตรียมความพร้อมสำหรับ Production
สร้างสคริปต์สำรองข้อมูล
ตั้งค่าการตรวจสอบ
กำหนดค่าการอัปเดตอัตโนมัติ
ขั้นตอนที่ 10: การกำหนดค่าขั้นสูง
การบูรณาการกับ SMTP ที่มีอยู่
หากคุณมี mailserver (เช่นจากการตั้งค่า n8n ของเรา) บูรณาการมัน:
Windmill หลาย Instance
สำหรับทีมที่ต้องการสภาพแวดล้อมที่แยกจากกัน:
ข้อพิจารณาด้านความปลอดภัย
การแยกเครือข่าย
- PostgreSQL เข้าถึงได้เฉพาะภายในเครือข่าย Docker เท่านั้น
- ไม่มีการเปิดพอร์ตฐานข้อมูลภายนอก
- การยุติ HTTPS ที่ระดับ Traefik
ขีดจำกัดทรัพยากร
- Worker containers มีขีดจำกัด CPU และหน่วยความจำ
- ป้องกันการโจมตีแบบใช้ทรัพยากรจนหมด
- กำหนดค่าได้ตามความจุของเซิร์ฟเวอร์
ความปลอดภัย SSL
- ใบรับรอง Let’s Encrypt อัตโนมัติ
- การ redirect จาก HTTP ไปยัง HTTPS
- การกำหนดค่า TLS สมัยใหม่
การตรวจสอบและบำรุงรักษา
การตรวจสุขภาพรายสัปดาห์
การบำรุงรักษารายเดือน
รายละเอียดค่าใช้จ่ายและการเปรียบเทียบ
ค่าใช้จ่ายรายเดือน
การตั้งค่าแบบ self-hosted:
- Hetzner CX21 (4GB RAM): €8.46/เดือน
- ค่าโดเมน: ~€1/เดือน
- รวม: ~€9.50/เดือน
การเปรียบเทียบกับ Windmill Cloud:
- แผน Team: $30/เดือนต่อผู้ใช้
- ประหยัด: $250+ ต่อปีสำหรับทีมขนาดเล็ก
ประโยชน์ด้านประสิทธิภาพ
ข้อได้เปรียบของการโฮสต์ด้วยตัวเอง:
- การรันเวิร์กโฟลว์ไม่จำกัด
- ไม่มีการจำกัดอัตราจากภายนอก
- ควบคุมข้อมูลได้อย่างเต็มที่
- การบูรณาการแบบกำหนดเอง
- ความยืดหยุ่นในการขยายทรัพยากร
เอกสารอ้างอิงการแก้ไขปัญหา
การวินิจฉัยอย่างรวดเร็ว
รูปแบบข้อผิดพลาดที่พบบ่อย
- “password authentication failed” → ใช้รหัสผ่านแบบ hex ล้าง volumes
- “connection refused” → ตรวจสอบการกำหนดค่าเครือข่าย
- “certificate errors” → ตรวจสอบ DNS และการตั้งค่า Traefik
- “out of memory” → ปรับขีดจำกัดทรัพยากร worker
การขยายโครงสร้างพื้นฐาน Windmill
การขยายแนวนอน
สำหรับสภาพแวดล้อมปริมาณสูง:
การขยายแนวตั้ง
อัปเกรดทรัพยากรเซิร์ฟเวอร์:
- CX31 (8GB RAM): €16.07/เดือนสำหรับภาระงานหนัก
- CX41 (16GB RAM): €29.75/เดือนสำหรับการใช้งานระดับองค์กร
การบูรณาการกับโครงสร้างพื้นฐานที่มีอยู่
การทำงานร่วมกับ n8n
หากคุณรัน n8n อยู่แล้ว (จากบทเรียนก่อนหน้าของเรา):
- Windmill จัดการเวิร์กโฟลว์ที่ใช้โค้ดเป็นหลัก
- n8n จัดการระบบอัตโนมัติแบบ visual ง่ายๆ
- ทั้งคู่แชร์ Traefik proxy เดียวกัน
- ฐานข้อมูลที่แยกจากกันป้องกันการขัดแย้ง
บริการที่แชร์กัน
ใช้ประโยชน์จากโครงสร้างพื้นฐานที่มีอยู่:
- Traefik: จัดการ SSL สำหรับทุกบริการ
- Mailserver: SMTP ที่แชร์กันสำหรับการแจ้งเตือน
- การตรวจสอบ: การบันทึกและตัวชี้วัดแบบรวมศูนย์
- การสำรองข้อมูล: กลยุทธ์การสำรองข้อมูลแบบรวมศูนย์
สรุป
การโฮสต์ Windmill ด้วยตัวเองให้ระบบอัตโนมัติเวิร์กโฟลว์ระดับองค์กรในราคาเพียงเศษเสี้ยวของต้นทุนการโฮสต์บนคลาวด์ กุญแจสู่ความสำเร็จคือการทำความเข้าใจข้อกำหนดการยืนยันตัวตนของ PostgreSQL และการใช้รหัสผ่านแบบ hex เท่านั้นเพื่อหลีกเลี่ยงปัญหาอักขระพิเศษที่อาจทำให้การติดตั้งล้มเหลว
ประโยชน์หลักของการตั้งค่านี้
- คุ้มค่า: ประหยัดเงินหลายร้อยต่อปีเทียบกับโซลูชันคลาวด์
- พร้อมสำหรับ production: จัดการภาระงานระดับองค์กรอย่างน่าเชื่อถือ
- ปลอดภัย: HTTPS เครือข่ายที่แยกจากกัน และขีดจำกัดทรัพยากร
- ขยายขนาดได้: เพิ่ม worker และทรัพยากรได้ง่ายตามต้องการ
- เป็นส่วนตัว: โค้ดและข้อมูลของคุณไม่เคยออกจากโครงสร้างพื้นฐานของคุณ
การกำหนดค่านี้ได้รับการทดสอบในสภาพแวดล้อม production และให้ความน่าเชื่อถือที่จำเป็นสำหรับระบบอัตโนมัติเวิร์กโฟลว์ที่สำคัญทางธุรกิจ ขั้นตอนการแก้ไขปัญหาจัดการปัญหาจริงที่พบระหว่างการปรับใช้ โดยเฉพาะปัญหาการยืนยันตัวตน PostgreSQL ที่ส่งผลกระทบต่อการติดตั้งแบบ self-hosted จำนวนมาก
สำหรับข้อกำหนดเวิร์กโฟลว์ที่ซับซ้อนหรือการปรับใช้ระดับองค์กร พิจารณาปรึกษาผู้เชี่ยวชาญเพื่อเพิ่มประสิทธิภาพกรณีการใช้งานเฉพาะของคุณและรับประกันการจัดสรรทรัพยากรที่เหมาะสมที่สุด
ขั้นตอนถัดไป
- สำรวจเทคนิคการแก้ไขปัญหา webhook ที่ใช้ได้กับ Windmill
- ทบทวนการเพิ่มประสิทธิภาพ payload สำหรับการจัดการชุดข้อมูลขนาดใหญ่
- พิจารณาการบูรณาการกับการติดตั้ง n8n ที่มีอยู่
เกี่ยวกับ tva
tva ดูแลการจัดการโครงสร้างพื้นฐานแบบครบวงจรของระบบฐานข้อมูล สภาพแวดล้อมคลาวด์ และห่วงโซ่อุปทานระดับโลก แนวทางที่เป็นระบบของเราผสมผสานโปรโตคอลความปลอดภัยที่เข้มงวดกับการเพิ่มประสิทธิภาพการทำงาน ในขณะที่บริการที่ปรึกษาเชิงกลยุทธ์ช่วยให้สามารถประสานงานขีดความสามารถด้านดิจิทัลและสินทรัพย์ทางกายภาพได้อย่างแม่นยำ – รักษามาตรฐานสูงสุดของความเป็นเลิศในการดำเนินงานและการปฏิบัติตามกฎระเบียบตลอดทุกการมีส่วนร่วม
เยี่ยมชม tva.sg สำหรับข้อมูลเพิ่มเติมเกี่ยวกับบริการของเราและบทเรียนระบบอัตโนมัติเพิ่มเติม
จากการตั้งค่าสู่การตัดสินใจด้านการดำเนินงาน
คำถามสำคัญไม่ใช่เพียงว่าแพลตฟอร์มตั้งค่าได้หรือไม่ แต่ทีมต้องอธิบายผู้รับผิดชอบ ตรวจจับการเปลี่ยนแปลงที่ไม่ตั้งใจ กู้คืนระบบโดยไม่ต้องแก้ปัญหาเฉพาะหน้า และพิสูจน์ผลลัพธ์ที่ต้องการได้ เราจึงผูกทุกการเปลี่ยนแปลงเข้ากับเจ้าของงาน baseline เส้นทาง rollback และช่วงเวลาตรวจสอบ วิธีนี้เปลี่ยนการแก้ไขครั้งเดียวให้เป็นความสามารถในการดำเนินงานที่เชื่อถือได้ บันทึกชุดเดียวกันยังเป็นจุดเริ่มต้นที่เชื่อถือได้สำหรับผู้รับผิดชอบคนถัดไป และทำให้การปรับปรุงครั้งต่อไปเป็นการตัดสินใจจากข้อมูลวัดผล ไม่ใช่การคาดเดารอบใหม่