Tự động hoá quy trình với n8n

n8n chạy theo từng tài khoản hosting, trên một tên miền của chính tài khoản đó. Đây là một ứng dụng thông thường của tài khoản chứ không phải dịch vụ dùng chung: một unit systemd chạy dưới người dùng của tài khoản bên trong user-<uid>.slice, nên giới hạn CPU, bộ nhớ và tiến trình của gói đã áp dụng cho nó, và front-end phục vụ nó trên cổng 443 bằng chứng chỉ mà tên miền đã có.

Cài đặt từ panel (Trình cài đặt tự động → n8n, hoặc /n8n), hoặc từ shell:

hitechcloudcli n8n install --account oneil --domain flow.example.com

--path /flows phục vụ ứng dụng dưới một tiền tố thay vì chiếm toàn bộ hostname. --database sqlite|postgres ghi đè lựa chọn được mô tả bên dưới.

Quá trình cài đặt làm gì​

• Cài gói npm n8n vào ~/.n8n-app, dùng runtime Node.js mà tài khoản đã chọn nếu có, nếu không thì dùng của máy chủ. Tối thiểu là Node 20; phiên bản cũ hơn bị từ chối thay vì để lỗi ở lần khởi động đầu tiên.
• Ghi ~/.n8n-app/n8n.env (chế độ 0600, thuộc sở hữu của tài khoản) với host, cổng, các URL công khai và thiết lập cơ sở dữ liệu.
• Ghi /etc/systemd/system/hitechcloud-n8n@<account>.service, bật và khởi động nó.
• Thêm một mục front-end cho tên miền, để ứng dụng được truy cập qua HTTPS trên các cổng web thông thường. Không có gì mới lắng nghe công khai: bản thân n8n chỉ bind 127.0.0.1 trên một cổng từ 5678 đến 5778.

Vị trí lưu trữ​

Khoá mã hoá​

n8n mã hoá các thông tin xác thực bạn lưu trong nó — khoá API, mật khẩu cơ sở dữ liệu, token OAuth — bằng khoá trong encryption.key. Khoá được tạo một lần khi cài đặt và không bao giờ bị ghi lại sau đó, kể cả bởi upgrade.

Hãy đưa ~/.n8n-app vào bản sao lưu. Khôi phục thư mục dữ liệu mà không có khoá đó sẽ khiến mọi thông tin xác thực đã lưu không đọc được, và n8n không báo đây là lỗi: nó vẫn khởi động, các workflow vẫn còn, và từng workflow thất bại khi cố xác thực. Cũng vì lý do này, một lần cài đặt tìm thấy thư mục dữ liệu có sẵn nhưng không có khoá sẽ bị từ chối thay vì được cấp khoá mới.

Cơ sở dữ liệu​

Mặc định, quá trình cài đặt chọn cho tài khoản:

• PostgreSQL khi tài khoản đã có role trên máy chủ này (một cơ sở dữ liệu tên <account>_n8n được tạo bên trong), vì đó là lựa chọn đứng vững khi nhiều workflow chạy cùng lúc.
• SQLite trong các trường hợp còn lại — một tệp trong thư mục dữ liệu, không cần thiết lập gì, và đủ cho hầu hết tài khoản.

Lựa chọn được in ra ở cuối quá trình cài đặt và hiển thị trên trang panel.

Webhook và URL công khai​

N8N_WEBHOOK_URL và N8N_EDITOR_BASE_URL được gắn cố định với tên miền đã chọn khi cài đặt. Webhook đăng ký với nhà cung cấp bên ngoài mang theo URL đầy đủ đó, nên chuyển n8n sang tên miền khác nghĩa là chạy lại cài đặt với tên miền mới và đăng ký lại các webhook bị ảnh hưởng — chỉ đổi DNS sẽ khiến nhà cung cấp vẫn gọi tên cũ.

Nâng cấp​

hitechcloudcli n8n upgrade <account>

Dịch vụ được dừng trước, với thời gian chờ dừng 60 giây, để lần thực thi đang chạy hoàn tất hoặc bị ngắt gọn gàng trước khi npm thay thế các tệp; sau đó dịch vụ được khởi động lại. Khoá mã hoá không bị động tới. Nếu npm thất bại, phiên bản trước vẫn được giữ và dịch vụ được khởi động lại.

Gỡ bỏ​

hitechcloudcli n8n uninstall <account>                 # stop and unregister
hitechcloudcli n8n uninstall <account> --delete-data   # and delete everything

Nếu không có --delete-data, các workflow, thông tin xác thực và khoá mã hoá được giữ nguyên, nên có thể cài lại tài khoản trên cùng dữ liệu đó.

Các giới hạn áp dụng​

Dịch vụ chạy trong slice của tài khoản, nên TasksMax, MemoryMax và CPUQuota của gói áp dụng cho n8n cùng với các worker PHP và shell của tài khoản. Workflow fork nhiều tiến trình bị giới hạn bởi cùng mức trần PID như mọi thứ khác mà tài khoản chạy — nên biết điều này trước khi đổ lỗi cho n8n về lỗi "cannot fork".