n8n 3.0 vào beta: tự host chuyển sang Docker, cần thử trước khi nâng

Đây là bản beta có thay đổi vận hành, không phải lệnh nâng ngay

n8n công bố bản 3.0 beta ngày 27/10/2026, cho phép tổ chức chủ động thử trước một đợt thay đổi lớn về triển khai và mặc định workflow. Nhà cung cấp dự kiến bản stable vào đầu tháng 12; đây là kế hoạch, không phải một ngày phát hành đã chắc chắn. Bản tin ngày 28/10 phân biệt rõ thử beta với nâng hệ thống đang phục vụ khách hàng.

Nhóm tự host bằng npm hoặc npx, xử lý tệp lớn, chạy Code lâu hoặc dùng community package cần rà trước. n8n 3.0 chỉ hỗ trợ cách tự host bằng Docker; triển khai Kubernetes với Helm vẫn theo luồng phù hợp của nó. Không nên chờ workflow lỗi sau nâng rồi mới xác định ứng dụng hiện tại đang được cài bằng phương thức nào.

Ảnh là bản 3.0.0 thật, báo cáo trống không chứng minh tương thích

Friday Works đã chạy container n8n 3.0.0 trong môi trường thử riêng ngày 28/10 và mở Migration report → Instance issues. Ảnh giữ nhãn Version 3.0.0, cho thấy bốn cảnh báo về mặc định của instance. Môi trường này không có workflow khách hàng; dòng 0 of 0 compatible không phải kết quả xác nhận quy trình thực tế của bất kỳ doanh nghiệp nào.

Migration Report đã có từ nhánh 2.39 để chuẩn bị nâng cấp. Bài này không dùng ảnh 2.39 thay bản mới hoặc gọi báo cáo là một tính năng lần đầu xuất hiện ở 3.0. Việc kiểm tra giao diện và phiên bản cũng chưa tương đương hoàn tất thử chuyển cơ sở dữ liệu, khôi phục hay chạy các workflow có credential thật.

Các mặc định mới có thể làm tác vụ đang chạy phải dừng

Báo cáo trong bản 3.0.0 nêu thời gian mặc định của task runner giảm từ 300 xuống 60 giây. Tác vụ Code cần lâu hơn có thể không còn hoàn thành với mặc định mới; biến N8N_RUNNERS_TASK_TIMEOUT cho phép cấu hình phù hợp. Không tăng thời gian vô hạn như một cách xử lý chung: cần biết mã đang làm gì và vì sao cần thời gian đó.

Với node giải nén, giới hạn kích thước giải nén mặc định giảm từ 2 GiB xuống 256 MiB, số mục ZIP tối đa từ 5.000 xuống 1.000. Đây là thay đổi mặc định, không phải mọi tệp cũ đều chắc chắn lỗi. Đội vận hành nên dùng các tệp mẫu sát nghiệp vụ và ghi kích thước sau giải nén, thay vì chỉ nhìn dung lượng tệp ZIP đầu vào.

Community package chưa được n8n xác minh mặc định không được nạp nếu N8N_UNVERIFIED_PACKAGES_ENABLED không được đặt phù hợp. Trước khi giữ lại lựa chọn cho phép, kiểm kê package, tác giả, phiên bản và nhu cầu thật. Việc nhà cung cấp gọi package là verified không đồng nghĩa doanh nghiệp được bỏ kiểm tra quyền và dữ liệu mà node truy cập.

Bản mới cũng bỏ Import from URL trong editor. Những tài liệu hướng dẫn nội bộ dùng đường này cần cập nhật, thay vì bảo người dùng tiếp tục tìm một nút không còn tồn tại.

Bảo mật và hàng đợi cần được rà theo điều kiện triển khai

Thông báo 3.0 nêu thay đổi về xoay khóa mã hóa, signing secret cho Slack và mặc định liên quan SSRF. SSRF là rủi ro dịch vụ bị dẫn đi gửi yêu cầu tới địa chỉ ngoài phạm vi mong muốn; blocklist mở rộng chỉ có tác dụng trong điều kiện cơ chế bảo vệ tương ứng được bật. Không suy rằng tất cả hệ thống đã tự chặn mọi truy cập mạng nguy hiểm.

Môi trường queue cần rà nơi thực thi thủ công và dữ liệu nhị phân. Bộ nhớ không còn là lựa chọn lưu binary theo cách cũ; cần phương án filesystem hoặc nơi lưu ngoài được hỗ trợ và phù hợp kiến trúc. Kiểm tra cả main, worker, khóa mã hóa và cách các tiến trình đọc cùng dữ liệu. Một lần mở editor thành công không kiểm chứng được những đường chạy đó.

Bản sao lưu chỉ có giá trị khi đã thử khôi phục

n8n cảnh báo không có đường quay lui đơn giản sau nâng 3.0; muốn trở lại phải phục hồi bản sao lưu phù hợp. Friday Works khuyến nghị thử ở môi trường tách riêng, lưu cơ sở dữ liệu, cấu hình, khóa mã hóa và dữ liệu tệp cần thiết, rồi thực sự kiểm tra lần phục hồi trước khi hẹn lịch sản xuất.

Nhánh 2.x tiếp tục nhận bản sửa bảo mật và lỗi nghiêm trọng trong 12 tháng sau khi 3.0 stable ra mắt; không tính mốc đó từ ngày beta. Với hệ thống còn 1.x, nhà cung cấp nêu kết thúc hỗ trợ ngày 31/12 và cần đi qua 2.x trước. Đối chiếu lịch chính thức khi lập kế hoạch, không coi beta là lý do bỏ qua một bước nâng nhánh.

Nhóm thử nên có webhook, tệp lớn, Code, Slack và workflow dùng node cộng đồng đại diện, với đầu ra mong đợi và người duyệt rõ ràng. Chỉ xem nâng cấp đạt khi kết quả nghiệp vụ đúng, worker và lịch chạy ổn, credential còn dùng được và phương án phục hồi đã được chứng minh. Chưa có các bằng chứng đó thì giữ thử nghiệm ở phạm vi nhỏ.