Nâng cấp n8n lên bản mới mà không làm vỡ workflow cũ

n8n ra bản mới gần như mỗi tuần. Bấm nâng cấp mà không đọc gì trước là cách nhanh nhất khiến một workflow đang chạy tốt đứng im. Người phát hiện ra thường là khách hàng, không phải đội kỹ thuật. Nâng cấp n8n an toàn không khó. Chỉ cần đúng thứ tự: đọc trước, sao lưu trước, đổi từng bước nhỏ.

Vì sao nâng cấp hay làm vỡ workflow

Workflow vỡ sau khi nâng cấp vì node đổi tham số mặc định. Hoặc một phiên bản node cũ bị gỡ khỏi bản mới, trong khi workflow vẫn đang tham chiếu đúng phiên bản đó. n8n theo dõi version riêng cho từng node. Hai workflow dùng cùng loại node vẫn có thể phản ứng khác nhau với cùng một lần cập nhật n8n.

Theo tài liệu n8n, các bản có thay đổi phá vỡ tương thích được gọi riêng là breaking change, liệt kê trong release notes của từng phiên bản, tách biệt với mục sửa lỗi thông thường. Bỏ qua mục này là bỏ qua đúng phần cảnh báo dành cho người sắp nâng cấp.

n8n 3.0 đổi gì và ai bị ảnh hưởng

n8n 3.0 dự kiến phát hành khoảng tháng 10 năm 2026. Mốc đáng chú ý nhất: bỏ hỗ trợ cài đặt qua npm. Đội vận hành đang tự cài n8n bằng lệnh npm trực tiếp trên hệ điều hành phải chuyển sang chạy bằng Docker trước khi mốc đó tới. Không thể đợi bản 3.0 phát hành rồi mới xử lý.

Ảnh hưởng rõ nhất rơi vào các máy chủ tự dựng từ đầu, cài n8n như một gói Node.js rồi quản lý bằng PM2 hoặc systemd. Máy đã chạy sẵn bằng Docker image chính thức không bị đổi cách vận hành. Chỉ cần theo đúng quy trình pin phiên bản ở phần dưới. Máy chưa có ai theo dõi lịch phát hành thì nên gộp việc này vào gói quản trị máy chủ theo tháng thay vì tự nhớ từng mốc.

Pin phiên bản Docker thay vì dùng tag latest

Tag latest kéo image mới nhất mỗi lần container khởi động lại. Máy chủ có thể tự nâng cấp n8n mà không ai bấm nút nào. Đổi sang tag ghi rõ số phiên bản, ví dụ n8nio/n8n:1.68.0 thay vì n8nio/n8n:latest. Version chỉ đổi khi có người chủ động sửa file cấu hình.

Cách làm trên VPS chạy Docker: mở file docker-compose.yml, sửa dòng image từ tag latest sang tag số phiên bản đang chạy ổn định, khởi động lại container một lần để xác nhận không có gì đổi. Từ đó mỗi lần nâng cấp là một dòng sửa có chủ đích, không phải một lần khởi động lại ngẫu nhiên.

Đọc release notes trước khi đổi phiên bản

Ba mục cần đọc trong release notes: breaking changes, node bị deprecated, và thay đổi ở biến môi trường. Bỏ qua một trong ba mục này thường khiến workflow chạy sai ngay sau khi nâng cấp mà không có log lỗi rõ ràng.

Node bị đánh dấu deprecated vẫn chạy được một thời gian trước khi gỡ hẳn. n8n thường nêu rõ phiên bản dự kiến gỡ trong ghi chú. Workflow nào đang dùng node đó nên lên lịch thay thế trước mốc đó, không đợi tới lúc nâng cấp xong mới phát hiện workflow không chạy được.

Sao lưu trước nâng cấp gồm những gì

Cần đủ hai phần: file export toàn bộ workflow dạng JSON, và bản sao database PostgreSQL đang lưu lịch sử execution cùng credential đã mã hoá. Thiếu một trong hai, lúc cần khôi phục workflow có thể trở lại nhưng lịch sử chạy và vài kết nối phải cấu hình lại từ đầu.

Trình tự làm: dừng ghi dữ liệu mới vào n8n trong vài phút, export workflow, sao lưu volume database, rồi mới đổi tag Docker sang phiên bản mới. Quy trình này mất khoảng 10 đến 15 phút cho một máy chủ cỡ vừa. Ngắn hơn nhiều so với thời gian dò lại workflow nếu nâng cấp lỗi mà không có gì để phục hồi.

Rollback khi có sự cố và cách nâng từng bước nhỏ

Rollback là đổi ngược tag Docker về số phiên bản đang pin trước đó rồi khởi động lại container, sau đó khôi phục database từ bản sao lưu nếu cấu trúc dữ liệu đã bị bản mới ghi đè. Đã pin phiên bản theo số cụ thể ở bước trên thì rollback chỉ là sửa lại đúng dòng đó. Không phải dò xem bản cũ là bản nào.

Rollback chỉ an toàn tuyệt đối khi chưa chạy workflow nào trên bản mới. Đã có execution mới ghi vào database theo cấu trúc bản mới, rollback database có thể làm mất đúng những lần chạy đó. Bước dừng ghi dữ liệu ở phần sao lưu không phải bước thừa.

Cách né tình huống này ngay từ đầu: nâng theo từng bản minor liền kề thay vì nhảy thẳng từ bản cũ vài tháng lên bản mới nhất. Nhảy nhiều bản một lúc gộp luôn rủi ro của nhiều lần breaking change, khó dò lỗi phát sinh từ thay đổi nào. Máy chủ đang chạy nhiều workflow production nên tách một khung giờ ít traffic để thử, ví dụ sáng sớm hoặc cuối tuần, xếp việc này vào lịch bảo trì định kỳ thay vì làm ngay khi thấy bản mới.

Đội đang dựng workflow lần đầu và chưa muốn lo phần phiên bản có thể xem dịch vụ AI Workflow n8n, phần hạ tầng và bản cài do BizMaC giữ.

Câu hỏi thường gặp về nâng cấp n8n

Điều cần nhớ

• Pin tag Docker theo số phiên bản cụ thể, bỏ tag latest để tránh tự nâng cấp ngoài ý muốn.
• Đọc breaking changes, node deprecated và biến môi trường trong release notes trước mỗi lần đổi tag.
• Sao lưu workflow JSON và database PostgreSQL trước khi nâng cấp, mất khoảng 10 đến 15 phút.
• Nâng từng bản minor liền kề thay vì nhảy nhiều bản một lúc.
• Máy cài qua npm cần chuyển sang Docker trước khi n8n 3.0 phát hành khoảng tháng 10 năm 2026.