โดย เปรียบเทียบทางเลือก n8n แบบ self-hosted ตัวไหนน่าใช้ที่สุด
เปรียบเทียบ Activepieces, Windmill, Node-RED, Automatisch และ Huginn กับ n8n ในด้านสัญญาอนุญาต การใช้ RAM ฐานข้อมูล และปัญหาการสำรองข้อมูลที่มักทำให้การกู้คืนระบบล้มเหลว
สิ่งที่ควรใช้แทน n8n
ทางเลือกของ n8n แบบ self-hosted ที่คุ้มค่าแก่การใช้งานบน VPS (virtual private server) ได้แก่ Activepieces, Windmill, Node-RED, Automatisch และ Huginn โดย Activepieces เป็นตัวเลือกที่ใกล้เคียงที่สุดสำหรับการใช้งาน n8n ในรูปแบบที่คนส่วนใหญ่ใช้ และมีแกนหลักเป็นสัญญาอนุญาตแบบ MIT ส่วน Windmill เหมาะสำหรับทีมที่ต้องการเขียน Python หรือ TypeScript มากกว่าการลากวางกล่องบน canvas สำหรับ Node-RED นั้นมีขนาดเล็กและไม่จำเป็นต้องใช้ฐานข้อมูลเลย
ผู้อ่านจำนวนมากควรใช้งานเครื่องมือเดิมต่อไป เนื่องจากสัญญาอนุญาตของ n8n อนุญาตให้ใช้ภายในองค์กรได้ ดังนั้นหากคุณรัน workflow สำหรับบริษัทของคุณเอง สัญญาอนุญาตก็ไม่ใช่ปัญหา นอกจากนี้การย้ายระบบยังมีต้นทุนแฝง ไม่มีเครื่องมือใดในรายการนี้ที่สามารถอ่านไฟล์ export ของ n8n ได้ คุณจึงต้องสร้าง workflow ใหม่ทั้งหมดด้วยตนเองและกรอกข้อมูล credential ใหม่ทุกรายการ การติดตั้ง n8n เป็นงานแยกต่างหาก ซึ่งครอบคลุมอยู่ใน การติดตั้ง n8n บน VPS ด้วย Docker และ HTTPS และ n8n เปรียบเทียบกับ Zapier และ Make จะอธิบายว่าเครื่องมือกลุ่มนี้เปรียบเทียบกับบริการแบบ hosted ได้อย่างไร
เหตุผลที่ผู้คนมองหาทางเลือกอื่นแทน n8n แบบ self-hosted
มีสองเหตุผลที่ถูกหยิบยกขึ้นมาพูดถึงอยู่บ่อยครั้ง
เหตุผลแรกคือเรื่องใบอนุญาต n8n เผยแพร่ภายใต้ Sustainable Use License v1.0 ซึ่งทางโครงการเรียกว่าเป็น fair-code ไม่ใช่ open source ใบอนุญาตนี้ให้สิทธิ์ในการ "ใช้หรือแก้ไขซอฟต์แวร์เพื่อวัตถุประสงค์ทางธุรกิจภายในของคุณเอง หรือเพื่อการใช้งานส่วนบุคคลที่ไม่ใช่เชิงพาณิชย์เท่านั้น" และห้ามไม่ให้ให้บริการซอฟต์แวร์นี้แก่ผู้อื่นในเชิงพาณิชย์ ไฟล์และโฟลเดอร์ที่มี .ee อยู่ในชื่อจะอยู่ภายใต้ n8n Enterprise License แยกต่างหาก หากคุณต้องการรันระบบอัตโนมัติในนามของลูกค้าที่จ่ายเงิน นี่ถือเป็นข้อจำกัดที่สำคัญ แต่หากคุณเป็นทีมปฏิบัติการภายใน สิ่งนี้จะไม่มีผลกระทบใดๆ ต่อการทำงานประจำวันของคุณ
เหตุผลที่สองคือเรื่องหน่วยความจำ n8n เป็นกระบวนการ Node.js และข้อมูลเวิร์กโฟลว์จะถูกเก็บไว้ในหน่วยความจำระหว่างการทำงาน เอกสารของ n8n ได้ระบุสาเหตุไว้ดังนี้: ปริมาณข้อมูล JSON, ขนาดของข้อมูลไบนารี, จำนวนโหนดในเวิร์กโฟลว์, โหนด Code, การรันแบบ manual (ซึ่งจะคัดลอกข้อมูลซ้ำอีกครั้งสำหรับตัวแก้ไข) และเวิร์กโฟลว์อื่นๆ ที่ทำงานอยู่ในเวลาเดียวกัน วิธีแก้ไขที่ระบุไว้ในเอกสารไม่ใช่การเปลี่ยนไปใช้ผลิตภัณฑ์อื่น แต่คือการใช้ queue mode ร่วมกับ worker process แยกต่างหาก รวมถึงการใช้ Postgres แทนไฟล์ SQLite เริ่มต้นที่ ~/.n8n/database.sqlite สำหรับงานขนาดใหญ่ควรใช้วิธี batching เนื่องจากโหนด Loop Over Items ที่ส่งข้อมูลไปยัง sub-workflow จะเก็บข้อมูลไว้ในหน่วยความจำเพียงส่วนเดียวในแต่ละครั้ง ลองใช้วิธีเหล่านี้ก่อนที่คุณจะตัดสินใจย้ายเวิร์กโฟลว์ทั้งหกสิบรายการไปที่อื่น
ทางเลือกของ n8n สำหรับการ self-host ที่ยังมีการดูแลรักษาอยู่
ข้อความในใบอนุญาตนั้นอ่านง่าย ทุกคนจึงมักเปรียบเทียบกันที่ใบอนุญาต แต่สุขภาพของโครงการเป็นสิ่งที่มองข้ามได้ง่าย นี่คือโครงการจำนวน 6 โครงการในการเปรียบเทียบนี้ โดยระบุวันที่ของ release ล่าสุดที่มีการติดแท็กไว้ ณ วันที่ 4 สิงหาคม 2026
The data behind this chart
[
{
"tool": "n8n",
"licence": "Sustainable Use License",
"latest_release": "2.33.3",
"released": "2026-07-31",
"days_since_release": 4
},
{
"tool": "Activepieces",
"licence": "MIT core, commercial ee",
"latest_release": "0.86.3",
"released": "2026-07-17",
"days_since_release": 18
},
{
"tool": "Windmill",
"licence": "AGPLv3 source, CE image",
"latest_release": "v1.778.0",
"released": "2026-08-04",
"days_since_release": 0
},
{
"tool": "Node-RED",
"licence": "Apache 2.0",
"latest_release": "5.0.4",
"released": "2026-07-30",
"days_since_release": 5
},
{
"tool": "Automatisch",
"licence": "AGPL-3.0, commercial ee",
"latest_release": "v0.15.0",
"released": "2025-08-08",
"days_since_release": 361
},
{
"tool": "Huginn",
"licence": "MIT",
"latest_release": "v2022.08.18",
"released": "2022-08-18",
"days_since_release": 1447
}
]มีสองรายการที่ทำให้ตัวเลือกในรายการสั้นลง Automatisch มีการติดแท็ก release ล่าสุดเมื่อ v0.15.0 ซึ่งผ่านมาแล้ว 361 วัน และ branch หลักไม่มีการ commit ใดๆ เลยตั้งแต่ 15 มกราคม 2026 ส่วน Huginn มีการติดแท็ก release ล่าสุดเมื่อ 1447 วันที่แล้ว แต่ log การ commit ยังคงมีการเคลื่อนไหวในเดือนนี้ ซึ่งเป็นรูปแบบที่ตรงกันข้ามกัน คือโค้ดมีการพัฒนาแต่ไม่มีการออก release ดังนั้นการใช้งานจึงหมายถึงการรัน image ที่ไม่มีการติดแท็ก
โปรดตรวจสอบเรื่องนี้ด้วยตนเองก่อนที่จะเชื่อการเปรียบเทียบใดๆ รวมถึงการเปรียบเทียบนี้ด้วย ให้เปิดหน้า releases ของโครงการบน GitHub จากนั้นดูรายการ commit ของ branch หลัก โครงการที่มี release ใหม่แต่ log การ commit เงียบเหงาคือโครงการที่กำลังประคองตัวไปเรื่อยๆ ส่วนโครงการที่มีการ commit ใหม่ๆ แต่ไม่มีการออก release มาหลายปี คือโครงการที่กำลังขอให้คุณรันโค้ดที่ไม่มีใครรับรองเวอร์ชันให้
Activepieces: ตัวเลือกที่ใกล้เคียงที่สุดและมีแกนหลักเป็น MIT
Activepieces เป็นตัวเลือกที่เทียบเคียงกันได้โดยตรง มันเป็นเครื่องมือสร้างเวิร์กโฟลว์แบบภาพ (visual builder) ที่ประกอบด้วยทริกเกอร์และขั้นตอนต่างๆ ซึ่งทางผู้พัฒนาเรียกว่า pieces โดยใน README ระบุว่ามีให้ใช้งานมากกว่า 280 รายการ แต่ละ piece ยังถูกเปิดเผยออกมาในรูปแบบของ MCP (model context protocol) server เพื่อให้ไคลเอนต์ LLM (large language model) สามารถเรียกใช้ตัวเชื่อมต่อเดียวกันนี้เป็นเครื่องมือได้ แกนหลักของซอฟต์แวร์ใช้สัญญาอนุญาตแบบ MIT อย่างไรก็ตาม มีสองไดเรกทอรีคือ packages/ee/ และ packages/server/api/src/app/ee ที่ใช้สัญญาอนุญาตเชิงพาณิชย์ ซึ่งการใช้งานสิ่งที่อยู่ภายในไดเรกทอรีเหล่านี้บนเซิร์ฟเวอร์ของคุณเองจำเป็นต้องมีข้อตกลงการชำระเงิน
โปรดอ่านรายละเอียดการแบ่งส่วนนี้ก่อนที่คุณจะย้ายระบบ เพราะขอบเขตของมันกว้างกว่าโครงการ MIT ส่วนใหญ่ หน้าการกำหนดราคาของ Activepieces ระบุว่า Community Edition เป็น "โอเพนซอร์ส ใช้งานได้ฟรีตลอดไป โดยไม่มีการจำกัดจำนวนการรัน ผู้ใช้งาน หรือเวิร์กโฟลว์" แต่ได้แยกฟีเจอร์อย่าง Agents and Chat, Projects, การเข้าถึง API และเลเยอร์การจัดการทั้งหมด (เช่น single sign-on, บทบาทผู้ใช้, audit logs, secret managers, การปรับแต่งแบรนด์, Git sync) ออกไป ดังนั้น Community Edition จึงเป็นเอนจินระบบอัตโนมัติที่สมบูรณ์แบบพร้อมเวิร์กโฟลว์และผู้ใช้ไม่จำกัด แต่ไม่ใช่แพลตฟอร์มที่คุณจะสั่งการผ่าน API ได้ หากแผนของคุณคือการสร้างเวิร์กโฟลว์ผ่านโปรแกรม แผนนั้นจำเป็นต้องมีใบอนุญาต
รูปแบบการรันไทม์ประกอบด้วยคอนเทนเนอร์แอปพลิเคชันหนึ่งตัว, คอนเทนเนอร์ worker หนึ่งตัวหรือมากกว่า, Postgres และ Redis โดยมี AP_DB_TYPE=POSTGRES และ AP_REDIS_TYPE=STANDALONE เป็นค่าเริ่มต้น นอกจากนี้ยังมีโหมดคอนเทนเนอร์เดี่ยวที่มาพร้อมกับฐานข้อมูลแบบฝังตัวและคิวภายในกระบวนการ (AP_DB_TYPE=PGLITE ร่วมกับ AP_REDIS_TYPE=MEMORY) ซึ่งเอกสารระบุว่า "มีไว้สำหรับการใช้งานส่วนตัวหรือการทดสอบเท่านั้น" โปรดปฏิบัติตามคำแนะนำนั้นอย่างเคร่งครัด โหมดเหล่านี้ไม่สามารถรันมากกว่าหนึ่งอินสแตนซ์ได้ ดังนั้นการขยายระบบจากโหมดนี้จึงถือเป็นการย้ายระบบ ไม่ใช่แค่การปรับเปลี่ยน flag เพียงอย่างเดียว
Windmill: เน้นเขียนโค้ดเป็นหลัก และมีน้ำหนักมากกว่าที่เห็น
Windmill รันสคริปต์ภาษา Python, TypeScript, Go, Bash และ SQL แล้วนำมาประกอบกันเป็น flow หากระบบอัตโนมัติของคุณเน้นการเขียนโค้ดเป็นหลักโดยมีส่วนเชื่อมต่อเพียงเล็กน้อย เครื่องมือนี้จะตอบโจทย์ได้ดีกว่าการใช้ node canvas ใดๆ
เรื่องใบอนุญาตต้องให้ความสำคัญ ซอร์สโค้ดเป็น AGPLv3 เมื่อคอมไพล์โดยไม่เปิดใช้ enterprise feature flag ส่วนอิมเมจที่เผยแพร่ที่ ghcr.io/windmill-labs/windmill คือ Community Edition ซึ่งรวมโค้ดที่ไม่ใช่โอเพนซอร์สแต่สามารถใช้งานได้ฟรีภายใต้โควตาที่กำหนด หน้าการกำหนดราคาของ Windmill ระบุโควตาไว้ที่ 50 ผู้ใช้, 3 พื้นที่ทำงาน (workspace) และพื้นที่จัดเก็บข้อมูลวัตถุใน workspace ขนาด 10 GiB โดยไม่จำกัดจำนวนการรัน สำหรับบุคคลเดียวหรือทีมขนาดเล็ก เพดานนี้ถือว่าสูงมาก ดังนั้นคำถามในทางปฏิบัติจึงไม่ใช่เรื่องโควตา แต่เป็นเรื่องที่ binary ที่คุณรันไม่ใช่ build แบบ AGPL
น้ำหนักของระบบเป็นอีกประเด็นที่ต้องพิจารณา docker-compose.yml ของ Windmill มาพร้อมกับฐานข้อมูล Postgres 16, เซิร์ฟเวอร์หนึ่งตัว, worker เริ่มต้นสามตัวที่จำกัดหน่วยความจำตัวละ 2048M, native worker และ Caddy proxy กฎทั่วไปที่ระบุไว้ในเอกสารคือ "1 worker ต่อ 1vCPU และ RAM 1-2 GB" คุณสามารถลดจำนวน replica ลงได้บนเครื่องขนาดเล็ก แต่คุณควรทราบว่าการทำเช่นนั้นจะส่งผลอย่างไร เพราะ worker คือส่วนที่รันงานของคุณจริงๆ
ฟีเจอร์ AI ของ Windmill ถูกระบุไว้ในเอกสารว่าเป็นตัวช่วยในขั้นตอนการพัฒนา เช่น การสร้างโค้ด, การสร้าง flow, การแชท และการกรอกแบบฟอร์ม คุณจำเป็นต้องเพิ่ม resource ของผู้ให้บริการโมเดลในการตั้งค่า workspace ก่อน หากสิ่งที่คุณต้องการคือขั้นตอนที่เป็น agent ซึ่งทำงานตามกำหนดการและเรียกใช้เครื่องมือต่างๆ node AI Agent ของ n8n ยังคงเป็นเส้นทางที่ตรงไปตรงมากว่า และ การสร้าง AI agent ใน n8n ได้ครอบคลุมรูปแบบการทำงานดังกล่าวไว้แล้ว
Node-RED: ตัวเลือกขนาดเล็กที่ไม่มีฐานข้อมูล
Node-RED ใช้สัญญาอนุญาต Apache 2.0 ซึ่งเป็นสัญญาอนุญาตที่เปิดกว้างที่สุดในการเปรียบเทียบนี้ โดยทำงานเป็นกระบวนการ Node.js หนึ่งกระบวนการร่วมกับ volume /data ไม่มีการใช้ Postgres หรือ Redis ให้กำหนดเวอร์ชันเป็น nodered/node-red:5.0.4 ซึ่งเป็นเวอร์ชันล่าสุดในปัจจุบัน
Node-RED พัฒนามาจากการเชื่อมต่ออุปกรณ์ IoT (Internet of Things) จึงมีลักษณะการทำงานแบบขับเคลื่อนด้วยเหตุการณ์ (event-shaped) มากกว่าแบบเชื่อมต่อ (connector-shaped) โหนดสำหรับบริการของบุคคลที่สามมาจากคลังชุมชนและมีคุณภาพแตกต่างกันไป ซึ่งเป็นสิ่งที่ต้องแลกกับขนาดที่เล็กกะทัดรัด ทั้งนี้ไม่มีขั้นตอนสำหรับ AI agent ระดับเฟิร์สคลาส สำหรับ VPS ขนาดเล็กที่จัดการ webhooks และ traffic ของ message-queue นี่คือตัวเลือกที่เบาที่สุดในบรรดาทั้งหมดที่ใช้งานได้จริง และสามารถเริ่มทำงานได้ภายในเวลาไม่กี่วินาที
Huginn และ Automatisch: ตรวจสอบ commit log ก่อน
Huginn ใช้สัญญาอนุญาต MIT เขียนด้วย Ruby on Rails และต้องการ MySQL หรือ PostgreSQL ระบบนี้ทำงานโดยใช้แนวคิดของ agent ที่คอยเฝ้าดูแหล่งข้อมูลและส่งเหตุการณ์ออกมา ซึ่งเป็นรูปแบบที่ต่างจาก flow canvas และไม่มีฟีเจอร์ด้าน LLM แม้ว่าโค้ดจะยังมีการ commit อยู่ แต่ release ล่าสุดที่มีการ tag ไว้คือเดือนสิงหาคม 2022 ดังนั้นการใช้งานจึงหมายถึงการใช้ image ghcr.io/huginn/huginn ที่ build จาก branch หลัก ให้เลือกใช้ Huginn เมื่อรูปแบบ agent ตรงกับปัญหาของคุณ ไม่ใช่เพื่อใช้แทน n8n ในภาพรวม
Automatisch ใช้สัญญาอนุญาต AGPL-3.0 ยกเว้นไฟล์ .ee ของมัน โดยมีลักษณะคล้าย n8n เวอร์ชันที่เรียบง่ายกว่า ซึ่งใช้ Postgres, Redis และมีรายการแอปที่รองรับจำนวนไม่มากนัก นี่คือเครื่องมือที่บทความสอนการติดตั้งแบบ single-deploy มักแนะนำให้ใช้ อย่างไรก็ตาม ประวัติการ release บ่งบอกว่าควรชะลอการใช้งานไปก่อน การที่ไม่มีการ release มาหนึ่งปีและไม่มีการ commit มาครึ่งปีไม่ใช่เหตุผลให้ตื่นตระหนกหากคุณใช้งานอยู่แล้ว แต่เป็นเหตุผลที่ไม่ควรเริ่มการติดตั้งใช้งานจริง (production) รายการใหม่บนเครื่องมือนี้
ต้นทุน RAM ที่แท้จริงของ Activepieces stack
ปริมาณหน่วยความจำขณะว่างและขณะทำงานจริงไม่ใช่ตัวเลขที่ใครจะระบุให้คุณได้ เนื่องจากขึ้นอยู่กับ flow ของคุณเองและปริมาณข้อมูลที่ไหลผ่าน สิ่งที่คุณสามารถอ่านได้คือเกณฑ์ที่ผู้ให้บริการแนะนำให้จัดสรร Activepieces ได้ระบุรูปแบบไว้ดังนี้ และประโยคข้างต้นมีความสำคัญมากกว่าตัวเลข: "worker ที่มี concurrency-1 จะทำงานตลอดระยะเวลาของ flow (สูงสุด 10 นาที) ดังนั้นให้คำนวณขนาดตามจำนวน flow ที่ทำงานพร้อมกัน ไม่ใช่ตามอัตราการ trigger"
The data behind this chart
[
{
"label": "App container",
"vcpu": 1,
"ram_gb": 1
},
{
"label": "Worker (each)",
"vcpu": 0.5,
"ram_gb": 1
},
{
"label": "Postgres",
"vcpu": 2,
"ram_gb": 4
},
{
"label": "Redis",
"vcpu": 1,
"ram_gb": 1
}
]worker หนึ่งตัวใช้ 0.5 vCPU และ 1 GB โดยจะรัน flow ได้เพียงหนึ่งรายการในแต่ละช่วงเวลา ส่วน Postgres ถูกกำหนดขนาดไว้ที่ 4 GB ไฟล์ compose ของโปรเจกต์มีการตั้งค่า worker ไว้ 5 replicas ดังนั้นตามขนาดที่ระบุไว้ stack ใน repository นี้จึงต้องการหน่วยความจำประมาณ 11 GB ก่อนที่คุณจะเริ่มรัน flow ใดๆ ที่ซับซ้อน บทเรียนสอนการใช้งานเครื่องมือเดี่ยวๆ มักจะคัดลอกไฟล์นั้นไปใช้และเรียกมันว่าการติดตั้งขนาดเล็ก
บน VPS ขนาด 4 GB ให้รัน worker สองตัว เก็บ Postgres ไว้ใน compose project เดียวกัน แล้วทำการวัดผล docker stats --no-stream จะแสดงข้อมูลหนึ่งบรรทัดต่อคอนเทนเนอร์พร้อมค่า resident memory จริง ซึ่งแม่นยำกว่าตัวเลขใดๆ ที่ผู้ให้บริการหรือบล็อกต่างๆ นำเสนอ หากคอนเทนเนอร์มีการใช้หน่วยความจำเพิ่มขึ้นโดยไม่มีขีดจำกัด ให้จำกัดค่าดังกล่าวไว้ โดย การจำกัดหน่วยความจำใน Docker Compose จะแสดงไวยากรณ์ที่ต้องใช้
ไฟล์ compose สำหรับ Activepieces บน VPS หนึ่งเครื่อง
ให้ระบุเวอร์ชันของ tag ไว้เสมอ การใช้ latest อาจทำให้ docker compose pull ปรับเปลี่ยนโครงสร้างฐานข้อมูลของคุณได้โดยไม่มีการแจ้งเตือน เวอร์ชัน 0.86.3 คือเวอร์ชันที่โปรเจกต์ระบุไว้ในไฟล์ compose ของตนเอง ณ วันที่ 4 สิงหาคม 2026
สร้าง secret สองรายการขึ้นมาก่อน โดยใช้ความยาวตามที่เอกสารระบุไว้
openssl rand -hex 16 # AP_ENCRYPTION_KEY, encrypts stored connections
openssl rand -hex 32 # AP_JWT_SECRET, signs session tokensเขียน .env ไว้ข้างไฟล์ compose:
AP_ENGINE_EXECUTABLE_PATH=dist/packages/engine/main.js
AP_ENVIRONMENT=prod
AP_FRONTEND_URL=https://automation.example.com
AP_ENCRYPTION_KEY=REPLACE_WITH_HEX_16
AP_JWT_SECRET=REPLACE_WITH_HEX_32
AP_DB_TYPE=POSTGRES
AP_POSTGRES_DATABASE=activepieces
AP_POSTGRES_HOST=postgres
AP_POSTGRES_PORT=5432
AP_POSTGRES_USERNAME=postgres
AP_POSTGRES_PASSWORD=REPLACE_WITH_A_LONG_RANDOM_PASSWORD
AP_REDIS_TYPE=STANDALONE
AP_REDIS_HOST=redis
AP_REDIS_PORT=6379
AP_EXECUTION_MODE=UNSANDBOXED
AP_TELEMETRY_ENABLED=falseAP_FRONTEND_URL ต้องเป็นที่อยู่ HTTPS สาธารณะ เพราะหากไม่กำหนด Activepieces จะพยายามใช้ IP สาธารณะของคุณในการสร้าง URL สำหรับ webhook ซึ่ง webhook ทุกรายการที่คุณส่งให้บุคคลที่สามจะถูกสร้างขึ้นจากค่านั้น หากค่ายังคงชี้ไปที่ localhost URL ที่คุณนำไปวางในบริการอื่นจะไม่มีทางเข้าถึงเซิร์ฟเวอร์ของคุณได้
services:
app:
image: ghcr.io/activepieces/activepieces:0.86.3
restart: unless-stopped
ports:
- '127.0.0.1:8080:80'
depends_on:
- postgres
- redis
env_file: .env
environment:
- AP_CONTAINER_TYPE=APP
volumes:
- ./cache:/usr/src/app/cache
worker:
image: ghcr.io/activepieces/activepieces:0.86.3
restart: unless-stopped
depends_on:
- app
env_file: .env
environment:
- AP_CONTAINER_TYPE=WORKER
deploy:
replicas: 2
volumes:
- ./cache:/usr/src/app/cache
postgres:
image: pgvector/pgvector:0.8.0-pg14
restart: unless-stopped
env_file: .env
environment:
- POSTGRES_DB=${AP_POSTGRES_DATABASE}
- POSTGRES_USER=${AP_POSTGRES_USERNAME}
- POSTGRES_PASSWORD=${AP_POSTGRES_PASSWORD}
volumes:
- postgres_data:/var/lib/postgresql/data
redis:
image: redis:7.0.7
restart: unless-stopped
volumes:
- redis_data:/data
volumes:
postgres_data:
redis_data:ไฟล์ดังกล่าวคือไฟล์ compose ของโปรเจกต์เองโดยมีการเปลี่ยนแปลง 4 จุด ได้แก่ ลดจำนวน worker จาก 5 เหลือ 2, พอร์ตที่เปิดใช้งานจะผูกกับ 127.0.0.1 แทนที่จะเป็นทุกอินเทอร์เฟซ, ลบชื่อ container แบบระบุตายตัวออกเนื่องจากบริการที่มีการทำ replica ไม่สามารถใช้ชื่อซ้ำกันได้ และลบบล็อก network ที่ระบุไว้ออกเนื่องจาก compose จะสร้าง network ให้โดยอัตโนมัติอยู่แล้ว
docker compose up -d
docker compose psทุกบริการควรแสดงสถานะ Up รวมถึง container ประเภท worker สองรายการ หาก container มีการรีสตาร์ทวนซ้ำ ให้ตรวจสอบสาเหตุใน docker compose logs worker ก่อนทำการแก้ไขใดๆ การผูกพอร์ตในลักษณะนี้หมายความว่าจะไม่มีการเข้าถึงแอปจากภายนอกได้จนกว่าคุณจะติดตั้ง reverse proxy ที่รองรับ TLS (transport layer security) ไว้ด้านหน้า ซึ่งครอบคลุมอยู่ในหัวข้อ การรัน Traefik หน้าแอป compose หลายตัว ให้เก็บ .env ไว้ในโหมด 600 และไม่นำขึ้น git ตามที่ระบุใน การจัดการ secret ในไฟล์ env ของ compose
การสำรองข้อมูลที่ทุกคู่มือมักมองข้าม
เครื่องมือเหล่านี้ทั้งหมดจะเข้ารหัสข้อมูลประจำตัวที่จัดเก็บไว้ ดังนั้นการสำรองข้อมูลฐานข้อมูลเพียงอย่างเดียวจึงไม่ใช่การสำรองข้อมูลที่สมบูรณ์ คุณจำเป็นต้องมีทั้งไฟล์ดัมพ์และกุญแจที่ใช้ถอดรหัสข้อมูลนั้น กับดักสำคัญคือเครื่องมือส่วนใหญ่จะสร้างกุญแจดังกล่าวให้คุณโดยอัตโนมัติและจัดเก็บไว้ในตำแหน่งที่คุณอาจไม่ได้สำรองข้อมูลไว้
n8n เป็นตัวอย่างที่ชัดเจนที่สุด หากคุณไม่เคยตั้งค่า N8N_ENCRYPTION_KEY ตัว n8n จะ "สร้างกุญแจเข้ารหัสแบบสุ่มโดยอัตโนมัติในการเริ่มทำงานครั้งแรกและบันทึกไว้ในโฟลเดอร์ ~/.n8n" จากนั้นจะใช้กุญแจนั้นเข้ารหัสข้อมูลประจำตัวก่อนที่จะบันทึกลงในฐานข้อมูล หากคุณดัมพ์ Postgres แล้วนำไปกู้คืนในคอนเทนเนอร์ใหม่ที่มี volume ใหม่ เวิร์กโฟลว์ของคุณจะกลับมา แต่ข้อมูลประจำตัวทั้งหมดจะกลายเป็นข้อความที่เข้ารหัสซึ่งไม่มีใครอ่านได้ คุณต้องกำหนดค่าตัวแปรนี้อย่างชัดเจน และตั้งค่าให้เป็นค่าเดียวกันในทุก worker เมื่อคุณรันในโหมด queue
Node-RED ก็มีลักษณะเดียวกัน ข้อมูลประจำตัวจะอยู่ในไฟล์ที่เข้ารหัสแยกต่างหาก และกุญแจจะถูกกำหนดโดย credentialSecret ใน settings.js เมื่อคุณไม่ได้ตั้งค่าไว้ รันไทม์จะสร้างกุญแจแบบสุ่มและบันทึกไว้ภายใต้ _credentialSecret ในที่เก็บการตั้งค่าภายใน /data ไฟล์การตั้งค่ามาตรฐานได้ระบุผลลัพธ์ไว้ว่า "เมื่อคุณตั้งค่าคุณสมบัตินี้แล้ว ห้ามเปลี่ยนแปลง เพราะจะทำให้ Node-RED ไม่สามารถถอดรหัสข้อมูลประจำตัวเดิมของคุณได้และข้อมูลเหล่านั้นจะสูญหาย" ดังนั้นให้สำรองข้อมูลทั้ง volume /data ไม่ใช่แค่ไฟล์ flows เท่านั้น
Activepieces เก็บ AP_ENCRYPTION_KEY ไว้ใน .env ของคุณ ซึ่งระบุไว้ว่าเป็น "กุญแจเลขฐานสิบหกขนาด 32 ตัวอักษร (16 ไบต์) ที่ใช้สำหรับเข้ารหัสการเชื่อมต่อ" Huginn เก็บ APP_SECRET_TOKEN ไว้ในสภาพแวดล้อมของมัน ส่วน Automatisch มีกุญแจสามตัวคือ ENCRYPTION_KEY, WEBHOOK_SECRET_KEY และ APP_SECRET_KEY ในทุกกรณี ข้อมูลลับจะอยู่ในไฟล์สภาพแวดล้อม ซึ่งหมายความว่าไฟล์สภาพแวดล้อมนั้นเป็นส่วนหนึ่งของการสำรองข้อมูล
Windmill เป็นข้อยกเว้นที่ควรทราบ ตัวแปรและข้อมูลลับของมันถูกเข้ารหัสด้วยกุญแจสมมาตรเฉพาะ workspace ซึ่ง Windmill จัดเก็บไว้ในฐานข้อมูลของตัวเอง ดังนั้นการดัมพ์ Postgres เพียงไฟล์เดียวจึงมีข้อมูลครบทั้งสองส่วน ซึ่งสะดวกต่อการกู้คืน แต่ก็หมายความว่าไฟล์ดัมพ์เพียงไฟล์เดียวก็เพียงพอที่จะอ่านข้อมูลลับทั้งหมดได้ ดังนั้นควรปกป้องไฟล์นี้เสมือนว่าเป็นข้อมูลลับเหล่านั้นเอง
สำหรับ stack ของ Activepieces ที่กล่าวมาข้างต้น การสำรองข้อมูลประกอบด้วยสองไฟล์:
cd /srv/activepieces
docker compose exec -T postgres pg_dump -U postgres -Fc activepieces > "ap-$(date +%F).dump"
cp .env "ap-env-$(date +%F).bak"
chmod 600 ap-*.dump ap-env-*.bakจากนั้นให้พิสูจน์ว่าการสำรองข้อมูลใช้งานได้จริง เพราะการสำรองข้อมูลที่ไม่ได้ทดสอบก็เป็นเพียงการคาดเดาเท่านั้น ให้กู้คืนไฟล์ดัมพ์ลงในโปรเจกต์ compose สำรองที่ใช้ AP_ENCRYPTION_KEY ที่แตกต่างออกไปอย่างตั้งใจ จากนั้นรัน flow ที่ใช้การเชื่อมต่อที่บันทึกไว้ มันจะล้มเหลวเพราะข้อความที่เข้ารหัสในฐานข้อมูลถูกสร้างขึ้นด้วยกุญแจอีกตัวหนึ่ง ให้ทำซ้ำขั้นตอนการกู้คืนโดยใช้กุญแจจริงจาก .env แล้ว flow เดียวกันนั้นจะทำงานได้ การทดสอบทั้งสองครั้งนี้เป็นหลักฐานเดียวที่ยืนยันว่าการสำรองข้อมูลของคุณคือการสำรองข้อมูลที่แท้จริง ให้ส่งไฟล์ทั้งสองออกจากเซิร์ฟเวอร์ตามกำหนดเวลาด้วย การสำรองข้อมูลด้วย restic จาก VPS เนื่องจากการสำรองข้อมูลไว้บนดิสก์ลูกเดียวกันจะสูญหายไปพร้อมกับดิสก์หากเกิดความเสียหาย
เมื่อใดที่ควรใช้งาน n8n ต่อไป
ให้ใช้งานต่อหากงานนั้นเป็นงานภายในบริษัทของคุณเอง เนื่องจากเป็นสิ่งที่ Sustainable Use License อนุญาตไว้อย่างชัดเจน ให้ใช้งานต่อหากคุณเน้นความหลากหลาย เนื่องจาก n8n รองรับการเชื่อมต่อมากกว่า 1500 รายการ หรือหากคุณพึ่งพา AI Agent node ที่สร้างบน LangChain ซึ่งไม่มีเครื่องมืออื่นใดในที่นี้เทียบเท่าในแง่ของขั้นตอนการทำงานแบบสำเร็จรูป การขับเคลื่อนเวิร์กโฟลว์ n8n ด้วย Claude แสดงให้เห็นว่าสิ่งนี้มีลักษณะการทำงานอย่างไรในทางปฏิบัติ
ให้ย้ายไปใช้ Activepieces หากคุณต้องการใบอนุญาตที่ยืดหยุ่นสำหรับแกนหลักของระบบอัตโนมัติและต้องการ stack ที่คุณสามารถอ่านทำความเข้าใจได้ทั้งหมดตั้งแต่ต้นจนจบ ให้ย้ายไปใช้ Windmill หากเวิร์กโฟลว์ของคุณคือโค้ดที่ครอบด้วยส่วนติดต่อผู้ใช้งาน ให้ย้ายไปใช้ Node-RED หากอุปกรณ์มีทรัพยากรจำกัดและงานของคุณมีลักษณะเป็นเหตุการณ์ (event-shaped) อย่าตัดสินใจย้ายเพียงเพราะผลการทดสอบประสิทธิภาพระบุว่า n8n ใช้ทรัพยากรสูง ให้วัดผลจาก instance ของคุณเองก่อน จากนั้นอ่าน สิ่งที่คุ้มค่าต่อการ self-host ในปี 2026 แล้วจึงตัดสินใจเลือกเพียงครั้งเดียว เพราะการย้ายระบบครั้งที่สองมีต้นทุนสูงเท่ากับการย้ายครั้งแรก
FAQ
ทางเลือกของ n8n สำหรับการ self-host ตัวใดที่ใกล้เคียงกับ n8n มากที่สุด?
Activepieces ครับ แนวคิดเหมือนกันคือเป็น visual builder ที่ใช้ trigger เริ่มต้น flow และแต่ละขั้นตอนจะเรียกใช้บริการต่างๆ โดยมีตัวเชื่อมต่อ (connectors) ให้เลือกใช้จำนวนมาก แกนหลักของซอฟต์แวร์เป็น MIT license ทำงานบน Postgres และ Redis ผ่าน Docker และตัว pieces ยังทำหน้าที่เป็น MCP servers สำหรับ LLM clients ได้ด้วย ข้อควรระวังคือการเข้าถึง API และฟีเจอร์ด้าน agent นั้นอยู่ในส่วนของ commercial enterprise ดังนั้นการใช้งาน Community Edition จึงต้องทำผ่านหน้าเว็บอินเทอร์เฟซเป็นหลัก ไม่ใช่การสั่งงานผ่านโปรแกรม
Activepieces เป็น open source จริงหรือไม่?
แกนหลักเป็น open source ภายใต้ MIT license แต่มีสองไดเรกทอรีคือ packages/ee/ และ packages/server/api/src/app/ee ที่เป็นลิขสิทธิ์เชิงพาณิชย์ ซึ่งการใช้งานฟีเจอร์เหล่านั้นบนเซิร์ฟเวอร์ของคุณเองจำเป็นต้องมีใบอนุญาตแบบเสียค่าใช้จ่าย หน้าแสดงราคาของผู้พัฒนาได้ระบุว่า Agents and Chat, Projects, API access, single sign-on, user roles, audit logs, secret managers, branding และ Git sync ไม่รวมอยู่ใน Community Edition ในขณะที่จำนวนการรัน (runs), ผู้ใช้ (users) และ flow ไม่มีการจำกัด ดังนั้นจึงถือว่าเป็น open source สำหรับการสร้างและรันระบบอัตโนมัติ แต่ไม่ใช่ open source ในส่วนของการจัดการทีมและ governance
Activepieces ต้องการ RAM เท่าใดบน VPS?
Activepieces ระบุความต้องการไว้ที่ 0.5 vCPU และ 1 GB สำหรับ worker แต่ละตัว, 1 vCPU และ 1 GB สำหรับ app container, 4 GB สำหรับ Postgres และ 1 GB สำหรับ Redis โดย worker หนึ่งตัวจะจัดการ flow ได้ครั้งละหนึ่งรายการตลอดระยะเวลาที่ flow นั้นทำงาน ดังนั้นคุณควรคำนวณขนาดตามจำนวน flow ที่ทำงานพร้อมกันสูงสุด (peak concurrent flows) ไม่ใช่ตามความถี่ที่ trigger ทำงาน ไฟล์ compose ใน repository มีการตั้งค่า worker ไว้ 5 ตัว ซึ่งต้องใช้ทรัพยากรรวมประมาณ 11 GB การเริ่มต้นด้วย worker 2 ตัวบน VPS ขนาด 4 GB ถือเป็นจุดเริ่มต้นที่เหมาะสม และ docker stats --no-stream จะช่วยยืนยันจำนวนที่แท้จริงสำหรับ flow ของคุณในขณะที่กำลังทำงาน
ต้องสำรองข้อมูลส่วนใดบ้างเพื่อให้การกู้คืนใช้งานได้จริง?
ต้องสำรองข้อมูล database dump และ encryption key ควบคู่กันไป สำหรับ Activepieces คือการทำ pg_dump ของฐานข้อมูล activepieces ร่วมกับไฟล์ .env ที่เก็บ AP_ENCRYPTION_KEY ไว้ สำหรับ n8n คือฐานข้อมูลและ N8N_ENCRYPTION_KEY ซึ่ง n8n สร้างขึ้นให้ภายในโฟลเดอร์ ~/.n8n หากคุณไม่ได้กำหนดค่าไว้เอง สำหรับ Node-RED ให้สำรองข้อมูลทั้ง volume /data เพราะไฟล์ credentials และกุญแจสำหรับถอดรหัสจะอยู่ในนั้นทั้งหมด ยกเว้น Windmill ที่กุญแจ workspace จะถูกเก็บไว้ในฐานข้อมูล Postgres ของตัวมันเอง ดังนั้นการ dump ฐานข้อมูลจะรวมทุกอย่างไว้แล้ว และต้องเก็บรักษาข้อมูลนั้นไว้เป็นความลับเช่นเดียวกับรหัสผ่าน
ฉันสามารถนำเข้า (import) workflow จาก n8n ไปยังเครื่องมืออื่นได้หรือไม่?
ไม่ได้ครับ โปรเจกต์เหล่านี้มีรูปแบบการนำเข้าและส่งออก flow ของตนเอง ไม่รองรับรูปแบบของ n8n การย้ายระบบหมายถึงการต้องสร้าง flow ใหม่ใน builder ตัวใหม่และสร้าง credential ใหม่ทั้งหมดจากบริการต้นทาง งานส่วนนี้คือต้นทุนที่แท้จริงของการเปลี่ยนระบบ ดังนั้นควรนับจำนวน flow ของคุณก่อนตัดสินใจ หากมี 12 flow อาจใช้เวลาเพียงช่วงบ่าย แต่ถ้ามี 200 flow ถือเป็นโปรเจกต์ใหญ่ ซึ่งโดยปกติแล้วการแก้ไขปัญหาการใช้หน่วยความจำของ n8n ด้วย queue mode และ Postgres จะคุ้มค่ากว่าการสร้างใหม่ทั้งหมดครับ