วิธีติดตั้ง n8n บน VPS ด้วย Docker แบบ Self-hosted

อัปเดต 2026-08-22อ่าน ~9 นาที

การลง n8n ด้วย Docker เป็นวิธีที่คนใช้กันมากที่สุด เพราะไม่ต้องมานั่งจัดการเวอร์ชัน Node.js เอง และย้ายเครื่องหรืออัปเดตทีหลังได้ง่ายกว่ามาก แต่สิ่งที่ทำให้หลายคนสะดุดไม่ใช่คำสั่งติดตั้ง — เป็นค่าตั้งค่าไม่กี่ตัวที่ถ้าพลาดแล้ว workflow จะทำงานผิดโดยที่ระบบไม่แจ้งอะไรเลย

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

ทำไมต้องลง n8n บน VPS ไม่ใช่เครื่องตัวเอง

ลง n8n บนโน้ตบุ๊กตัวเองก็ทำได้และเหมาะกับการลองเล่นมาก แต่พอจะใช้งานจริงจะเจอกำแพงสองอย่างที่แก้ไม่ได้ด้วยการตั้งค่า อย่างแรกคือ workflow ที่ตั้งเวลาไว้จะทำงานเฉพาะตอนที่เครื่องเปิดและโปรแกรมรันอยู่เท่านั้น ปิดฝาโน้ตบุ๊กเมื่อไหร่ รอบนั้นก็หายไปเงียบ ๆ ไม่มีการทำย้อนหลังให้

อย่างที่สองหนักกว่า คือ webhook ระบบภายนอกที่จะยิงข้อมูลเข้ามาหา n8n ต้องเรียกที่อยู่ของคุณได้จากอินเทอร์เน็ตจริง ๆ เครื่องที่บ้านอยู่หลังเราเตอร์ ไม่มี IP สาธารณะที่คงที่ และมักถูกผู้ให้บริการอินเทอร์เน็ตกันการเปิดพอร์ตไว้ด้วย จึงทำหน้าที่นี้ได้ยากมากถ้าไม่พึ่งบริการอุโมงค์เพิ่มเติม

VPS แก้ทั้งสองข้อพร้อมกัน เพราะเครื่องเปิดตลอด 24 ชั่วโมงในดาต้าเซ็นเตอร์ที่มีไฟและเน็ตสำรอง และมาพร้อม IP สาธารณะที่ชี้โดเมนเข้ามาได้ ทำให้ทั้ง schedule และ webhook ทำงานตามที่ออกแบบไว้จริง

ถ้ายังไม่คุ้นกับสองเทคโนโลยีนี้ แนะนำอ่าน VPS คืออะไร และ Docker คืออะไร ควบคู่ไปด้วย ส่วนใครที่ยังไม่แน่ใจว่า n8n เหมาะกับงานตัวเองไหม อ่านพื้นฐานได้ที่ n8n คืออะไร ก่อน

💡 ข้อควรรู้: โฮสติ้งเว็บแบบแชร์ทั่วไปลง n8n ไม่ได้ เพราะไม่ได้ให้สิทธิ์รัน Docker หรือ process ที่ทำงานค้างไว้ตลอด — ต้องเป็น VPS หรือเซิร์ฟเวอร์ที่คุณคุมเองเท่านั้น

สเปก VPS ที่ควรใช้สำหรับ n8n

n8n ตัวเดียวที่รัน workflow ไม่หนักถือว่ากินทรัพยากรไม่มาก แต่สิ่งที่ทำให้แรมพุ่งคือจำนวน execution ที่รันพร้อมกัน ขนาดข้อมูลที่ไหลผ่านแต่ละรอบ และ node ที่ต้องประมวลผลหนัก เช่น งานที่เกี่ยวกับ AI หรือการแปลงไฟล์ขนาดใหญ่

อีกจุดที่คนมักประเมินต่ำคือพื้นที่ดิสก์ เพราะประวัติ execution จะสะสมไปเรื่อย ๆ ถ้าไม่ตั้งค่าให้ลบของเก่าทิ้ง ยิ่ง workflow รันบ่อย ฐานข้อมูลก็ยิ่งบวมเร็ว

ตารางด้านล่างคือแพ็กเกจ Cloud VPS ของ Plusweb พร้อมคำแนะนำคร่าว ๆ ว่าเหมาะกับงานระดับไหน โปรดถือเป็นแนวทางประเมินเบื้องต้น ไม่ใช่การรับประกันประสิทธิภาพ เพราะปริมาณงานจริงของแต่ละคนต่างกันมาก

แพ็กเกจ	CPU	RAM	SSD	เหมาะกับ	ราคา
VPS-00	1 vCore	1 GB	15 GB	ทดลองเล่นให้เห็นภาพ ไม่แนะนำสำหรับงานจริง	150฿/เดือน (120฿ รายปี)
VPS-01	1 vCore	3 GB	30 GB	จุดเริ่มต้นที่สมเหตุสมผล — n8n ตัวเดียว workflow ไม่หนัก	250฿/เดือน (200฿ รายปี)
VPS-02	2 vCores	4 GB	60 GB	workflow เยอะขึ้น หรือมี node ที่เกี่ยวกับ AI	350฿/เดือน (280฿ รายปี)
VPS-03	4 vCores	8 GB	100 GB	ใช้งานหนัก รันหลายบริการบนเครื่องเดียว	600฿/เดือน (480฿ รายปี)
VPS-04	5 vCores	10 GB	140 GB	งานปริมาณมาก ต้องการพื้นที่เผื่อเยอะ	1,000฿/เดือน (800฿ รายปี)

💡 ทุกแพ็กเกจมี 1 Public IPv4 ให้ในตัว ซึ่งจำเป็นสำหรับการชี้โดเมนมาที่เครื่องและให้ webhook เรียกเข้ามาได้ · เริ่มที่ VPS-01 (3 GB) แล้วค่อยขยับขึ้นเมื่อเห็นการใช้แรมจริงจะคุ้มกว่าการเดาเผื่อไว้เยอะตั้งแต่แรก

สิ่งที่ต้องเตรียมก่อนติดตั้ง

เตรียมสามอย่างนี้ให้พร้อมก่อนเริ่ม จะทำให้ขั้นตอนติดตั้งลื่นไหลและไม่ต้องย้อนกลับมาแก้ทีหลัง โดยเฉพาะเรื่องโดเมนที่ถ้าไม่ได้เตรียมไว้ตั้งแต่ต้น จะกลายเป็นปัญหา webhook ในภายหลัง

VPS ที่ลง Linux ไว้แล้ว — นิยมใช้ตระกูล Ubuntu หรือ Debian เพราะเอกสารและตัวอย่างมีเยอะที่สุด และคุณต้องเข้าถึงเครื่องผ่าน SSH ด้วยสิทธิ์ระดับผู้ดูแลได้
โดเมนย่อยที่ชี้มาที่ IP ของเครื่องแล้ว — เช่น สร้างเรคคอร์ด A ชื่อ n8n ใต้โดเมนของคุณให้ชี้มาที่ IP ของ VPS แล้วรอให้ DNS กระจายตัวเรียบร้อยก่อนค่อยขอใบรับรอง HTTPS
Docker และส่วนเสริม Docker Compose บนเครื่อง — เป็นตัวที่จะรัน n8n ให้ ควรติดตั้งจากคู่มือทางการของ Docker สำหรับระบบปฏิบัติการที่คุณใช้ แล้วตรวจว่าใช้งานได้ด้วยคำสั่งเช็กเวอร์ชันก่อนไปต่อ

💡 เตรียมโดเมนย่อยไว้ก่อนเสมอ แม้ตอนแรกจะยังไม่ได้เปิดให้ใครใช้ — เพราะการเปลี่ยนที่อยู่ของ n8n ทีหลังหมายถึงต้องไปแก้ URL ที่ตั้งไว้ในระบบภายนอกทุกตัวที่ยิง webhook เข้ามา

ขั้นตอนติดตั้ง n8n ด้วย Docker (ภาพรวม)

ลำดับด้านล่างคือภาพรวมของงานทั้งหมด ไม่ใช่คำสั่งแบบก๊อปวาง เพราะรายละเอียดของแต่ละขั้นเปลี่ยนไปตามเวอร์ชันของ n8n และระบบปฏิบัติการที่คุณใช้ ควรเทียบกับเอกสารทางการฉบับล่าสุดควบคู่ไปด้วยเสมอ

1ติดตั้ง Docker และ Docker Compose บน VPS ตามคู่มือทางการ จากนั้นตรวจสอบว่าเรียกใช้งานได้จริงด้วยคำสั่งเช็กเวอร์ชัน
2เตรียมโฟลเดอร์สำหรับโปรเจกต์และไฟล์ตั้งค่า compose หนึ่งไฟล์ โดยระบุอิมเมจทางการของ n8n กำหนดพอร์ต (ค่าเริ่มต้นคือ 5678) และผูก volume สำหรับเก็บข้อมูลไว้ให้ชัดเจน
3ตั้งค่า environment ที่สำคัญ — โซนเวลาให้ตรงกับที่ใช้จริง, ที่อยู่สาธารณะของ n8n ให้เป็นโดเมนย่อยที่เตรียมไว้, และคีย์เข้ารหัสสำหรับ credential ให้เป็นค่าที่คุณเก็บสำเนาไว้เองอย่างปลอดภัย
4สั่งให้ container ทำงานด้วย docker compose up -d แล้วดู log ของ container ว่าขึ้นมาเรียบร้อยไม่มี error ค้าง
5เปิดหน้าเว็บของ n8n ครั้งแรกเพื่อสร้างบัญชีเจ้าของระบบ (owner) ซึ่งจะเป็นบัญชีผู้ดูแลสูงสุด — ทำขั้นตอนนี้ทันทีหลังเปิดใช้ อย่าปล่อยหน้าจอตั้งค่าแรกทิ้งไว้ให้คนอื่นมากดก่อน
6ครอบ HTTPS ด้วย reverse proxy — ตั้งตัวรับหน้าอย่าง Nginx, Caddy หรือ Traefik ให้รับ 443 แล้วส่งต่อเข้าพอร์ตของ n8n พร้อมออกใบรับรองจาก Let’s Encrypt แล้วปิดไม่ให้เข้าพอร์ตของ n8n ตรง ๆ จากภายนอก
7ตั้งระบบสำรองข้อมูล — สำรอง volume ที่เก็บฐานข้อมูล workflow และ credential เป็นประจำ พร้อมเก็บคีย์เข้ารหัสไว้นอกเครื่อง แล้วทดสอบกู้คืนอย่างน้อยหนึ่งครั้ง

💡 อย่าข้ามข้อสุดท้าย — backup ที่ไม่เคยลองกู้คืน เท่ากับยังไม่มี backup การทดสอบกู้ลงเครื่องเปล่าสักครั้งจะบอกทันทีว่าคุณลืมเก็บอะไรไว้บ้าง

ค่าตั้งค่าที่คนลืมบ่อยที่สุด

สามเรื่องนี้คือสาเหตุของปัญหาส่วนใหญ่ที่คนโพสต์ถามกัน และทั้งสามเรื่องแก้ตอนติดตั้งง่ายกว่าแก้ตอนใช้งานจริงไปแล้วมาก

เรื่องแรกคือโซนเวลา ถ้าไม่ได้ตั้งไว้ container มักยึดเวลามาตรฐาน UTC ซึ่งต่างจากเวลาไทยอยู่เจ็ดชั่วโมง ผลคือ workflow ที่ตั้งให้รันตอนเก้าโมงเช้าจะไปยิงตอนสี่ทุ่มของวันก่อนหน้าแทน และมันจะทำงานอย่างเงียบ ๆ โดยไม่มี error ให้เห็น ทำให้กว่าจะรู้ตัวก็ผ่านไปหลายวัน ควรตั้งทั้งโซนเวลาของระบบและของ n8n ให้ตรงกัน

เรื่องที่สองคือที่อยู่ของ webhook ถ้าไม่ได้บอก n8n ว่าที่อยู่สาธารณะจริงคืออะไร URL ที่มันสร้างให้จะชี้ไปที่ localhost หรือ IP ภายใน ซึ่งระบบภายนอกยิงเข้ามาไม่ได้เลย ต้องตั้งค่าให้เป็นโดเมนย่อยจริงที่ขึ้นต้นด้วย https และตรงกับที่ตั้งไว้ใน reverse proxy

เรื่องที่สามคือการสำรองข้อมูล ข้อมูล workflow และ credential ทั้งหมดอยู่ใน volume ที่ผูกไว้กับ container ถ้าคุณลบ container ทิ้งโดยไม่ได้ผูก volume ไว้ตั้งแต่แรก ข้อมูลจะหายทั้งหมด และต่อให้มีไฟล์ฐานข้อมูล แต่ถ้าไม่มีคีย์เข้ารหัสตัวเดิม credential ที่เก็บไว้ก็จะอ่านไม่ออก ต้องมาผูกบัญชีทุกบริการใหม่หมด

โซนเวลา — ตั้งให้ตรงกับเวลาที่คุณใช้วางแผน schedule จริง แล้วทดสอบด้วย workflow ที่รันทุกนาทีสักรอบเพื่อยืนยันเวลาบนหน้าประวัติ execution
ที่อยู่สาธารณะ — ต้องเป็นโดเมนย่อยจริงที่มี HTTPS ไม่ใช่ localhost และถ้าเปลี่ยนโดเมนทีหลังต้องไปอัปเดตที่ระบบภายนอกทุกตัวด้วย
คีย์เข้ารหัส credential — สร้างเองและเก็บสำเนาไว้นอกเซิร์ฟเวอร์ ถ้าหายแล้วกู้ credential เดิมไม่ได้
volume ที่เก็บข้อมูล — ต้องผูกไว้ตั้งแต่แรก และต้องอยู่ในแผน backup ไม่ใช่แค่ backup ไฟล์ตั้งค่า
การเก็บประวัติ execution — ตั้งให้ลบของเก่าอัตโนมัติตามอายุหรือจำนวนที่เหมาะสม ไม่งั้นฐานข้อมูลจะโตจนกินดิสก์

💡 ชื่อและพฤติกรรมของตัวแปร environment ของ n8n มีการเปลี่ยนแปลงระหว่างเวอร์ชันอยู่เรื่อย ๆ ก่อนตั้งค่าจริงควรเปิดเอกสารทางการของเวอร์ชันที่คุณใช้เทียบเสมอ

ปัญหาที่เจอบ่อยและวิธีแก้

อาการในตารางนี้คือสิ่งที่เจอซ้ำ ๆ กับการติดตั้งแบบ self-host เกือบทุกครั้ง ถ้ารู้ล่วงหน้าว่าอะไรเป็นสาเหตุ จะประหยัดเวลาไล่หาไปได้มาก

อาการ	สาเหตุที่พบบ่อย	วิธีแก้
schedule ยิงผิดเวลา เร็วหรือช้าไปหลายชั่วโมง	ไม่ได้ตั้งโซนเวลา container จึงใช้ UTC	ตั้งโซนเวลาของทั้งระบบและของ n8n ให้ตรงกัน แล้วรีสตาร์ต container ทดสอบใหม่
URL ของ webhook ขึ้นเป็น localhost ใช้จากภายนอกไม่ได้	ไม่ได้บอก n8n ว่าที่อยู่สาธารณะจริงคืออะไร	ตั้งค่าที่อยู่สาธารณะให้เป็นโดเมนย่อยจริงแบบ https แล้วเปิด workflow นั้นใหม่เพื่อให้สร้าง URL ใหม่
เข้าหน้าเว็บได้แต่ล็อกอินไม่ผ่าน หรือขึ้นเตือนเรื่องคุกกี้	เข้าผ่าน http หรือเข้าด้วย IP ตรง ๆ โดยยังไม่มี HTTPS	ตั้ง reverse proxy ให้ครอบ HTTPS บนโดเมนจริงแล้วเข้าผ่านโดเมนนั้นแทน
container รีสตาร์ตเองซ้ำ ๆ หรือทำงานสะดุด	แรมไม่พอกับ workflow ที่รันพร้อมกัน	ดูการใช้แรมจริงบนเครื่อง ลดงานที่รันพร้อมกัน หรืออัปสเปกขึ้นแพ็กเกจถัดไป
reverse proxy ขึ้นหน้า error ว่าเชื่อมต่อปลายทางไม่ได้	ชี้พอร์ตหรือชื่อ service ผิด หรือ container ยังไม่ขึ้น	ตรวจ log ของ container ว่าทำงานอยู่จริง แล้วเทียบพอร์ตปลายทางในไฟล์ตั้งค่า proxy
ขอใบรับรอง HTTPS ไม่สำเร็จ	DNS ยังไม่ชี้มาที่ IP ของเครื่อง หรือพอร์ต 80 ถูกปิด	ตรวจว่าโดเมนย่อยชี้ถูกแล้วจริง รอ DNS กระจายตัว และเปิดพอร์ตที่ระบบออกใบรับรองต้องใช้
อัปเดตเวอร์ชันแล้วข้อมูลหาย	ลบ container โดยไม่ได้ผูก volume ไว้ตั้งแต่ต้น	ผูก volume ให้ถูกตั้งแต่แรก และสำรองข้อมูลก่อนอัปเดตทุกครั้ง
credential อ่านไม่ออกหลังย้ายเครื่อง	คีย์เข้ารหัสไม่ใช่ตัวเดิม	นำคีย์เข้ารหัสเดิมมาใช้กับเครื่องใหม่ ถ้าไม่มีต้องผูกบัญชีทุกบริการใหม่ทั้งหมด

💡 เวลาแก้ปัญหา ให้ดู log ของ container กับหน้าประวัติ execution เป็นสองที่แรกเสมอ ส่วนใหญ่คำตอบอยู่ในนั้นแล้ว ไม่ต้องเดา

ความปลอดภัยที่ต้องทำตั้งแต่วันแรก

สิ่งที่ทำให้ n8n ต่างจากแอปทั่วไปคือมันเก็บ credential ของบริการอื่นไว้ในตัว ถ้าใครเข้าถึงหน้าจอของคุณได้ เขาก็มีสิทธิ์เท่ากับที่ workflow ของคุณมี ซึ่งอาจหมายถึงอีเมล ฐานข้อมูล หรือระบบภายในองค์กร การมองว่ามันเป็นแค่ "เครื่องมือภายใน" จึงอันตรายกว่าที่คิด

อีกเรื่องที่ควรทำเป็นนิสัยคือการอัปเดต n8n และระบบปฏิบัติการอย่างสม่ำเสมอ แต่ควรอ่านบันทึกการเปลี่ยนแปลงของเวอร์ชันก่อน และสำรองข้อมูลไว้ก่อนอัปเดตทุกครั้ง เพราะการข้ามหลายเวอร์ชันรวดเดียวมีโอกาสเจอการเปลี่ยนแปลงที่กระทบ workflow เดิม

อย่าเปิดพอร์ตของ n8n ให้เข้าถึงตรง ๆ จากอินเทอร์เน็ต ให้เข้าผ่าน reverse proxy ที่มี HTTPS เท่านั้น
ตั้งไฟร์วอลล์ให้เปิดเฉพาะพอร์ตที่จำเป็นจริง ๆ และจำกัดการเข้า SSH เท่าที่ทำได้
ใช้กุญแจ SSH แทนรหัสผ่านสำหรับเข้าเครื่อง และตั้งรหัสผ่านบัญชีเจ้าของระบบให้คาดเดายาก
สร้างบัญชีเจ้าของระบบทันทีหลังติดตั้งเสร็จ อย่าปล่อยหน้าตั้งค่าครั้งแรกเปิดค้างไว้
เก็บคีย์เข้ารหัส credential และไฟล์สำรองไว้นอกเซิร์ฟเวอร์ ไม่ใช่ในเครื่องเดียวกับที่รัน n8n
ระวัง workflow ที่รับข้อมูลจาก webhook สาธารณะ ควรตรวจสอบผู้ส่งด้วยกลไกยืนยันตัวตนก่อนนำข้อมูลไปใช้ต่อ
อัปเดตเวอร์ชันอย่างสม่ำเสมอ อ่านบันทึกการเปลี่ยนแปลงก่อน และสำรองข้อมูลก่อนทุกครั้ง

สรุป

การติดตั้ง n8n ด้วย Docker บน VPS ไม่ใช่เรื่องยากในแง่คำสั่ง แต่สิ่งที่ตัดสินว่าระบบจะใช้งานได้จริงหรือไม่คือรายละเอียดรอบ ๆ ตัวมัน — โซนเวลาที่ตั้งถูก ที่อยู่สาธารณะที่ webhook เรียกได้ HTTPS ที่ครอบเรียบร้อย และแผนสำรองข้อมูลที่เคยทดสอบกู้จริงแล้ว

สำหรับสเปก เริ่มที่ VPS-01 (1 vCore / 3 GB RAM / 30 GB SSD) เป็นจุดตั้งต้นที่สมเหตุสมผลสำหรับ n8n ตัวเดียวที่รัน workflow ไม่หนัก แล้วขยับไป VPS-02 (2 vCores / 4 GB) เมื่อ workflow เยอะขึ้นหรือเริ่มใช้ node ที่เกี่ยวกับ AI ซึ่งกินทรัพยากรมากกว่า วิธีที่แม่นที่สุดคือดูการใช้แรมจริงบนเครื่องหลังใช้งานไปสักระยะแล้วค่อยตัดสินใจ

ถ้ายังลังเลว่าจะลงเองหรือใช้บริการคลาวด์ของ n8n ดี ลองชั่งน้ำหนักจาก n8n Cloud vs Self-hosted ก่อนตัดสินใจ หรือย้อนไปทบทวนพื้นฐานที่ n8n คืออะไร และ Docker คืออะไร

💡 ทำทีละขั้นและทดสอบทุกขั้น อย่าลงทุกอย่างรวดเดียวแล้วค่อยมาไล่หาว่าพังตรงไหน — การแก้ทีละจุดตอนที่ยังจำได้ว่าเพิ่งเปลี่ยนอะไรไป เร็วกว่ากันมาก

พร้อมลง n8n บนเซิร์ฟเวอร์ของตัวเองแล้ว?

Cloud VPS ของ Plusweb มี 1 Public IPv4 ทุกแพ็กเกจ — VPS-01 (1 vCore / 3 GB / 30 GB) 250฿/เดือน หรือ 200฿ เมื่อจ่ายรายปี เหมาะกับการเริ่ม self-host n8n

ดูแพ็กเกจ VPS สั่งซื้อทันที

คำถามที่พบบ่อย

ติดตั้ง n8n บน VPS ต้องใช้สเปกเท่าไหร่?

ขึ้นกับปริมาณและความหนักของ workflow สำหรับ n8n ตัวเดียวที่รัน workflow ไม่หนัก แพ็กเกจ VPS-01 (1 vCore / 3 GB RAM / 30 GB SSD) เป็นจุดเริ่มต้นที่สมเหตุสมผล ถ้ามี workflow เยอะหรือใช้ node ที่เกี่ยวกับ AI ควรขยับไป VPS-02 (2 vCores / 4 GB) ทั้งนี้เป็นแนวทางประเมิน ไม่ใช่การรับประกันประสิทธิภาพ ควรดูการใช้แรมจริงประกอบ

จำเป็นต้องใช้ Docker ไหม ลงแบบอื่นได้หรือเปล่า?

ไม่จำเป็น n8n ติดตั้งแบบอื่นได้เช่นกัน แต่วิธีที่ใช้ Docker เป็นที่นิยมที่สุดเพราะไม่ต้องจัดการเวอร์ชัน Node.js เอง แยกสภาพแวดล้อมออกจากระบบหลัก และย้ายเครื่องหรืออัปเดตทีหลังได้ง่ายกว่า เอกสารและตัวอย่างส่วนใหญ่ก็อ้างอิงวิธีนี้

ต้องมีโดเมนไหม ใช้ IP อย่างเดียวได้หรือเปล่า?

ทดลองด้วย IP ได้ แต่ไม่เหมาะกับการใช้งานจริง เพราะการเข้าใช้แบบไม่มี HTTPS มักเจอปัญหาเรื่องคุกกี้ตอนล็อกอิน และ URL ของ webhook ที่เป็น IP เปลี่ยนยากเมื่อย้ายเครื่อง แนะนำให้ตั้งโดเมนย่อยชี้มาที่ IP ของ VPS แล้วครอบ HTTPS ด้วย reverse proxy

ทำไม workflow ที่ตั้งเวลาไว้ถึงยิงผิดเวลา?

สาเหตุที่พบบ่อยที่สุดคือไม่ได้ตั้งโซนเวลา ทำให้ container ใช้เวลามาตรฐาน UTC ซึ่งต่างจากเวลาไทยเจ็ดชั่วโมง แก้โดยตั้งโซนเวลาของทั้งระบบและของ n8n ให้ตรงกัน รีสตาร์ต container แล้วทดสอบด้วย workflow ที่รันถี่ ๆ เพื่อยืนยันเวลาบนหน้าประวัติ execution

อัปเดตเวอร์ชันแล้วข้อมูล workflow จะหายไหม?

ไม่หายถ้าคุณผูก volume สำหรับเก็บข้อมูลไว้ตั้งแต่แรก เพราะข้อมูลจะอยู่นอก container แต่ถ้าไม่ได้ผูกไว้แล้วลบ container ทิ้ง ข้อมูลจะหายทั้งหมด ควรสำรองข้อมูลและอ่านบันทึกการเปลี่ยนแปลงของเวอร์ชันก่อนอัปเดตทุกครั้ง

ต้องสำรองอะไรบ้างถึงจะกู้ระบบกลับมาได้ทั้งหมด?

สำรอง volume ที่เก็บฐานข้อมูลของ n8n ซึ่งมีทั้ง workflow และ credential ควบคู่กับไฟล์ตั้งค่า compose และที่สำคัญที่สุดคือคีย์เข้ารหัส credential เพราะถ้าคีย์ไม่ใช่ตัวเดิม credential ที่กู้กลับมาจะอ่านไม่ออกและต้องผูกบัญชีทุกบริการใหม่ ควรทดสอบกู้คืนลงเครื่องเปล่าอย่างน้อยหนึ่งครั้ง

GUIDES