So sánh 5 lựa chọn tự host thay n8n trên VPS
So sánh Activepieces, Windmill, Node-RED, Automatisch và Huginn với n8n về license, RAM, database, AI steps và lỗi backup khiến restore thất bại.
Dùng gì thay cho n8n
Các lựa chọn tự host thay cho n8n đáng dùng trên VPS (virtual private server) gồm Activepieces, Windmill, Node-RED, Automatisch và Huginn. Activepieces là lựa chọn thay thế gần nhất với cách đa số người dùng n8n, và phần lõi của nó được cấp phép MIT. Windmill phù hợp với các team muốn viết Python hoặc TypeScript thay vì kéo thả các khối trên canvas. Node-RED là lựa chọn gọn nhẹ và hoàn toàn không cần database.
Nhiều người dùng nên tiếp tục dùng n8n. Giấy phép n8n cho phép sử dụng nội bộ trong doanh nghiệp, nên nếu bạn chạy flow cho công ty của mình thì giấy phép không phải vấn đề. Việc migration cũng không miễn phí. Không công cụ nào trong danh sách này đọc được file export của n8n, nên bạn phải tạo lại từng flow thủ công và nhập lại mọi credential. Cài đặt n8n là một công việc riêng, được hướng dẫn trong hướng dẫn cài n8n trên VPS bằng Docker và HTTPS, còn n8n so với Zapier và Make giải thích cách so sánh toàn bộ nhóm công cụ này với các dịch vụ hosted.
Vì sao nhiều người tìm giải pháp thay thế n8n tự host
Có 2 lý do thường xuyên được nhắc đến.
Lý do đầu tiên là giấy phép. n8n được phát hành theo Sustainable Use License v1.0. Dự án gọi đây là fair-code thay vì open source. Giấy phép cho phép “chỉ sử dụng hoặc sửa đổi phần mềm cho mục đích kinh doanh nội bộ của bạn, hoặc cho mục đích phi thương mại hay cá nhân”. Giấy phép cũng cấm cung cấp phần mềm đó cho người khác vì mục đích thương mại. Các file và thư mục có .ee trong tên thuộc một n8n Enterprise License riêng. Nếu bạn muốn chạy automation thay cho khách hàng trả phí, đây là giới hạn không thể vượt qua. Nếu bạn là đội vận hành nội bộ, điều này không làm thay đổi công việc hằng ngày.
Lý do thứ hai là bộ nhớ. n8n là một tiến trình Node.js, còn dữ liệu workflow nằm trong bộ nhớ trong lúc workflow chạy. Tài liệu n8n nêu rõ các nguyên nhân: lượng dữ liệu JSON, kích thước dữ liệu binary, số node trong workflow, Code node, các lần thực thi thủ công (khi đó dữ liệu được copy thêm một lần cho editor) và các workflow khác đang chạy đồng thời. Cách khắc phục được tài liệu đề xuất không phải là dùng sản phẩm khác. Đó là dùng queue mode với các worker process riêng, đồng thời dùng Postgres thay cho file SQLite mặc định tại ~/.n8n/database.sqlite. Các job lớn cũng nên chia batch, vì một Loop Over Items node đưa dữ liệu vào sub-workflow chỉ giữ một phần dữ liệu trong bộ nhớ tại mỗi thời điểm. Hãy thử cách này trước khi xây dựng lại 60 flow ở một nơi khác.
Những lựa chọn thay thế n8n tự host nào vẫn còn được duy trì
Thông tin giấy phép dễ đọc, nên mọi người đều so sánh giấy phép. Tình trạng phát triển của dự án thì dễ bị bỏ qua. Đây là 6 dự án trong phần so sánh này, cùng bản release được gắn tag mới nhất của từng dự án tính đến ngày 4 August 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
}
]Hai dòng làm thay đổi danh sách rút gọn. Automatisch gắn tag release gần nhất vào v0.15.0, cách đây 361 ngày, và default branch của dự án không có commit nào kể từ ngày 15 January 2026. Huginn gắn tag một release cách đây 1447 ngày, nhưng commit log của dự án vẫn hoạt động trong tháng này. Đây là mô hình ngược lại: code vẫn được cập nhật nhưng release thì không, nên khi chạy dự án, bạn sẽ phải chạy một image chưa được gắn tag.
Hãy tự kiểm tra việc này trước khi tin vào bất kỳ phần so sánh nào, kể cả phần này. Mở trang releases của dự án trên GitHub, sau đó mở danh sách commit của default branch. Một dự án có release mới nhưng commit log im ắng chỉ đang duy trì quán tính. Một dự án có commit mới nhưng nhiều năm không có release đang buộc bạn chạy code mà chưa ai đóng gói thành một version.
Activepieces: lựa chọn tương đồng nhất, với phần lõi dùng giấy phép MIT
Activepieces là lựa chọn tương đương trực tiếp. Đây là một trình dựng trực quan gồm các trigger và step, được gọi là piece, và README cho biết có hơn 280 piece. Mỗi piece cũng được cung cấp dưới dạng server MCP (model context protocol), nên client LLM (large language model) có thể gọi các connector tương tự dưới dạng tool. Phần lõi dùng giấy phép MIT. Hai thư mục, packages/ee/ và packages/server/api/src/app/ee, dùng giấy phép thương mại. Muốn sử dụng nội dung trong các thư mục này trên server của bạn, bạn cần thỏa thuận trả phí.
Hãy đọc kỹ phần phân tách giấy phép này trước khi migrate, vì phạm vi của nó rộng hơn hầu hết dự án MIT. Trang giá của Activepieces mô tả Community Edition là "open source, free forever, with no cap on runs, users, or flows", đồng thời xếp Agents và Chat, Projects, quyền truy cập API và toàn bộ lớp quản trị (single sign-on, vai trò người dùng, audit log, secret manager, branding, Git sync) ra ngoài phiên bản này. Vì vậy, Community Edition là một automation engine hoàn chỉnh với số flow và user không giới hạn, nhưng không phải là platform có thể điều khiển từ API. Nếu kế hoạch của bạn là tạo flow bằng code, kế hoạch đó cần có giấy phép.
Mô hình runtime gồm một app container, một hoặc nhiều worker container, Postgres và Redis. AP_DB_TYPE=POSTGRES và AP_REDIS_TYPE=STANDALONE là các thiết lập mặc định. Có chế độ một container với database nhúng và queue chạy trong process (AP_DB_TYPE=PGLITE với AP_REDIS_TYPE=MEMORY), và tài liệu ghi rõ chế độ này "is only meant for personal use or testing". Hãy hiểu đúng theo nghĩa đó. Các chế độ này không thể chạy nhiều hơn một instance. Khi cần mở rộng vượt qua giới hạn này, bạn phải migrate chứ không chỉ đổi một flag.
Windmill: ưu tiên code, nhưng nặng hơn vẻ ngoài
Windmill chạy script bằng Python, TypeScript, Go, Bash và SQL, sau đó ghép chúng thành flow. Nếu automation của bạn chủ yếu là code và chỉ cần một ít glue code, Windmill phù hợp hơn mọi giao diện node canvas.
Bạn cần chú ý đến giấy phép. Source code dùng AGPLv3 khi được compile mà không bật enterprise feature flag. Các image được publish tại ghcr.io/windmill-labs/windmill là Community Edition. Chúng bao gồm code không phải open source và được phép sử dụng miễn phí trong giới hạn quota. Trang pricing của Windmill đặt các quota đó ở mức 50 user, 3 workspace và 10 GiB workspace object storage, với số lần execution không giới hạn. Với một người hoặc một team nhỏ, các giới hạn này còn rất xa. Vì vậy, vấn đề thực tế không phải là quota. Vấn đề là binary bạn chạy không phải bản build AGPL.
Dung lượng là yếu tố cần cân nhắc khác. docker-compose.yml của Windmill đi kèm database Postgres 16, một server, 3 worker mặc định với giới hạn bộ nhớ 2048M cho mỗi worker, một native worker và proxy Caddy. Quy tắc ước tính được tài liệu hóa là "1 worker cho mỗi 1vCPU và 1-2 GB RAM". Bạn có thể giảm số replica trên máy có cấu hình nhỏ. Nhưng cần hiểu rằng bạn đang giảm số replica, vì worker là thành phần thực sự chạy job của bạn.
Các tính năng AI của Windmill được tài liệu hóa dưới dạng hỗ trợ trong lúc build: tạo code, xây dựng flow, chat và điền form. Trước tiên, bạn phải thêm resource của model provider trong workspace settings. Nếu bạn cần một agent step chạy theo lịch và gọi tool, node AI Agent của n8n vẫn là lựa chọn trực tiếp hơn. Xây dựng AI agent trong n8n mô tả đúng kiểu triển khai đó.
Node-RED: bản nhỏ gọn, hoàn toàn không có database
Node-RED sử dụng giấy phép Apache 2.0, là giấy phép cởi mở nhất trong phần so sánh này. Đây là một tiến trình Node.js duy nhất với volume /data. Không có Postgres. Không có Redis. Ghim phiên bản này bằng nodered/node-red:5.0.4; đây là bản phát hành hiện tại.
Node-RED phát triển từ việc kết nối các thành phần trong IoT (internet of things), nên được thiết kế theo event thay vì theo connector. Các node cho dịch vụ bên thứ ba đến từ thư viện cộng đồng và chất lượng không đồng đều. Đây là sự đánh đổi để có footprint nhỏ. Node-RED không có bước AI agent tích hợp sẵn. Với một VPS nhỏ xử lý webhook và traffic từ message queue, đây là lựa chọn nhẹ nhất trong danh sách này mà vẫn đáp ứng yêu cầu. Nó khởi động trong vài giây.
Huginn và Automatisch: kiểm tra commit log trước
Huginn dùng giấy phép MIT, được viết bằng Ruby on Rails và cần MySQL hoặc PostgreSQL. Huginn hoạt động theo mô hình agent theo dõi một nguồn rồi phát ra event. Đây là mô hình khác với flow canvas và Huginn không có hướng tích hợp LLM. Mã nguồn vẫn có commit mới, nhưng bản release được gắn tag gần nhất từ tháng 08 năm 2022. Vì vậy, khi chạy Huginn, bạn sẽ dùng image ghcr.io/huginn/huginn được build từ default branch. Hãy chọn Huginn khi mô hình agent phù hợp với bài toán của bạn, không nên xem đây là sản phẩm thay thế n8n nói chung.
Automatisch dùng giấy phép AGPL-3.0, ngoại trừ các file .ee. Nó có vẻ giống một phiên bản n8n đơn giản hơn: Postgres, Redis và một catalogue nhỏ các app. Đây là công cụ thường được các tutorial triển khai đơn lẻ khuyến nghị. Lịch sử release cho thấy bạn nên chờ thêm. Một năm không có release và nửa năm không có commit không phải là lý do để lo lắng nếu bạn đã chạy công cụ này, nhưng đó là lý do để không bắt đầu một deployment production mới với nó.
Activepieces thực sự cần bao nhiêu RAM
Không ai có thể công bố chính xác RAM mà Activepieces dùng khi idle và khi chạy, vì mức dùng này phụ thuộc vào flow của bạn và lượng dữ liệu mà chúng xử lý. Bạn có thể xem mức tài nguyên mà từng vendor yêu cầu dự trù. Activepieces mô tả như dưới đây. Câu đi kèm quan trọng hơn các con số: "Worker với concurrency-1 sẽ bận trong toàn bộ thời gian chạy của một flow (tối đa 10 min), vì vậy hãy sizing theo số flow chạy đồng thời, không theo tần suất 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
}
]Một worker dùng 0.5 vCPU và 1 GB RAM, đồng thời chỉ chạy đúng một flow tại một thời điểm. Postgres được sizing ở mức 4 GB. File compose của project có sẵn 5 worker replica, nên theo mức sizing đó, stack trong repository cần khoảng 11 GB trước khi flow của bạn thực hiện tác vụ đáng kể nào. Các tutorial chỉ dùng một tool thường copy file này rồi gọi đó là một deployment nhỏ.
Trên VPS 4 GB, hãy chạy 2 worker, để Postgres trong cùng compose project và đo thực tế. docker stats --no-stream in một dòng cho mỗi container, hiển thị resident memory thực tế. Con số này đáng tin cậy hơn mọi mức tài nguyên do vendor hoặc blog công bố. Nếu một container tăng memory không giới hạn, hãy đặt giới hạn cho nó. phần giới hạn memory trong Docker Compose trình bày cú pháp.
File compose cho Activepieces trên một VPS
Ghim tag. latest có nghĩa là docker compose pull tiếp theo có thể tự ý cập nhật database schema mà không cảnh báo. Version 0.86.3 là version mà project ghim trong file compose của chính project tính đến ngày 4 August 2026.
Trước tiên, hãy tạo 2 secret theo đúng độ dài được tài liệu quy định.
openssl rand -hex 16 # AP_ENCRYPTION_KEY, encrypts stored connections
openssl rand -hex 32 # AP_JWT_SECRET, signs session tokensGhi .env cạnh file 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 phải là địa chỉ HTTPS public, vì nếu không Activepieces sẽ cố dùng public IP của bạn khi tạo webhook URL. Mọi webhook bạn cung cấp cho bên thứ ba đều được tạo từ giá trị đó. Nếu giá trị vẫn trỏ đến localhost, URL bạn dán vào service khác sẽ không thể đến server.
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:File đó là compose file của chính project, với 4 thay đổi: số worker giảm từ 5 xuống 2, port được publish chỉ bind vào 127.0.0.1 thay vì mọi interface, các container name cố định bị xóa vì service có replicas không thể dùng chúng, và phần network tường minh bị bỏ vì compose tự tạo network.
docker compose up -d
docker compose psMỗi service phải hiển thị Up, bao gồm 2 container worker. Container restart liên tục sẽ ghi lý do trong docker compose logs worker, vì vậy hãy đọc phần đó trước khi thay đổi bất kỳ thứ gì. Port binding này có nghĩa là từ bên ngoài chưa thể truy cập app cho đến khi bạn đặt reverse proxy có TLS (transport layer security) phía trước. Nội dung chạy Traefik phía trước nhiều app compose trình bày cách thực hiện. Giữ .env ở mode 600 và không đưa file này vào git, như hướng dẫn trong quản lý secret trong file env của compose.
Bản backup mà mọi hướng dẫn đều bỏ qua
Tất cả các công cụ này đều mã hóa thông tin xác thực đã lưu, nên chỉ dump database thì chưa phải là backup. Bạn cần cả dump và key dùng để giải mã nó. Vấn đề là hầu hết các công cụ này tự tạo key cho bạn một cách âm thầm rồi lưu ở nơi bạn không backup.
n8n là trường hợp rõ nhất. Nếu bạn chưa từng đặt N8N_ENCRYPTION_KEY, n8n sẽ “tự động tạo một encryption key ngẫu nhiên trong lần khởi chạy đầu tiên và lưu key đó trong thư mục ~/.n8n”, rồi dùng key này để mã hóa thông tin xác thực trước khi ghi vào database. Bạn dump Postgres, restore vào một container mới với volume mới, các workflow sẽ quay lại nhưng mọi thông tin xác thực đều trở thành ciphertext không thể đọc được. Hãy đặt biến này một cách tường minh và dùng cùng một giá trị trên mọi worker khi chạy queue mode.
Node-RED cũng có cơ chế tương tự. Thông tin xác thực nằm trong một file được mã hóa riêng, còn key là credentialSecret trong settings.js. Khi bạn không đặt key, runtime sẽ tạo một key ngẫu nhiên và lưu key đó tại _credentialSecret trong settings store riêng của nó bên trong /data. File settings mặc định nêu rõ hậu quả: “sau khi đặt thuộc tính này, không được thay đổi nó - nếu làm vậy, node-red sẽ không thể giải mã thông tin xác thực hiện có và chúng sẽ bị mất.” Hãy backup toàn bộ volume /data, không chỉ file flows.
Activepieces lưu AP_ENCRYPTION_KEY trong .env của bạn. Tài liệu mô tả đây là “key dạng hexadecimal gồm 32 ký tự (16 byte), dùng để mã hóa các connection”. Huginn lưu APP_SECRET_TOKEN trong environment của nó. Automatisch có 3 key: ENCRYPTION_KEY, WEBHOOK_SECRET_KEY và APP_SECRET_KEY. Trong mỗi trường hợp, secret nằm trong một environment file, nên environment file cũng là một phần của backup.
Windmill là ngoại lệ đáng lưu ý. Các variable và secret của nó được mã hóa bằng symmetric key riêng cho từng workspace. Windmill lưu key này trong database riêng, nên một Postgres dump duy nhất chứa cả hai phần. Điều này thuận tiện khi restore, nhưng cũng có nghĩa là chỉ cần dump là đã đủ để đọc mọi secret. Vì vậy, hãy bảo vệ file này như chính các secret.
Với stack Activepieces ở trên, backup gồm 2 file:
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-*.bakTiếp theo, hãy kiểm tra backup bằng cách restore, vì backup chưa được kiểm thử chỉ là phỏng đoán. Restore dump vào một compose project tạm thời sử dụng AP_ENCRYPTION_KEY cố ý khác, rồi chạy một flow dùng connection đã lưu. Flow sẽ fail vì ciphertext trong database được tạo bằng key khác. Lặp lại thao tác restore với key thật từ .env, flow tương tự sẽ chạy được. Hai lần chạy này là bằng chứng duy nhất cho thấy backup của bạn thực sự dùng được. Hãy định kỳ chuyển cả 2 file ra khỏi server bằng restic backup từ một VPS, vì backup nằm trên cùng disk sẽ mất cùng disk.
Khi nên tiếp tục dùng n8n
Hãy tiếp tục dùng nếu công việc chỉ phục vụ nội bộ công ty bạn, vì đó chính xác là phạm vi mà Sustainable Use License cho phép. Hãy tiếp tục dùng nếu bạn cần phạm vi tích hợp rộng, vì n8n có hơn 1500 integration, hoặc cần node AI Agent được xây dựng trên LangChain. Không công cụ nào khác trong danh sách này có sẵn nhiều bước cho agent tương đương. Điều khiển workflow n8n bằng Claude cho thấy cách này hoạt động trong thực tế.
Chuyển sang Activepieces nếu bạn muốn một license cho phép sử dụng rộng rãi đối với automation core và một stack có thể đọc xuyên suốt từ đầu đến cuối. Chuyển sang Windmill nếu các flow của bạn thực chất là code được bọc trong giao diện người dùng. Chuyển sang Node-RED nếu máy chủ có cấu hình nhỏ và công việc của bạn chủ yếu dựa trên event. Đừng chuyển chỉ vì một benchmark cho rằng n8n nặng. Hãy đo instance của chính bạn trước, sau đó đọc những gì đáng tự host trong 2026 và chọn một lần, vì lần migration thứ hai tốn chi phí tương đương lần đầu.
FAQ
Alternative tự host nào của n8n gần với n8n nhất?
Activepieces. Ý tưởng của nó tương tự: một trình dựng trực quan, trong đó trigger khởi động flow và mỗi bước gọi một service, với danh mục connector lớn. Phần core dùng giấy phép MIT, chạy trên Postgres và Redis trong Docker, đồng thời các piece có thể hoạt động như MCP server cho LLM client. Điểm cần lưu ý là quyền truy cập API và các tính năng agent nằm trong các thư mục enterprise thương mại. Vì vậy, instance Community Edition được điều khiển qua web interface thay vì qua lập trình.
Activepieces có thực sự là open source không?
Phần core là open source theo giấy phép MIT. Hai thư mục packages/ee/ và packages/server/api/src/app/ee dùng giấy phép thương mại. Muốn sử dụng các tính năng đó trên server của bạn, bạn cần giấy phép trả phí. Trang pricing của nhà cung cấp liệt kê Agents và Chat, Projects, quyền truy cập API, single sign-on, vai trò người dùng, audit log, secret manager, branding và Git sync là các tính năng nằm ngoài Community Edition. Số lượng run, user và flow không bị giới hạn. Vì vậy, Activepieces thực sự là open source cho việc xây dựng và chạy automation, nhưng không phải open source cho lớp quản trị và làm việc nhóm.
Activepieces cần bao nhiêu RAM trên VPS?
Tài liệu Activepieces nêu mức 0.5 vCPU và 1 GB cho mỗi worker, 1 vCPU và 1 GB cho app container, 4 GB cho Postgres và 1 GB cho Redis. Một worker xử lý mỗi lần một flow trong toàn bộ thời gian chạy flow đó. Vì vậy, bạn phải tính theo số flow chạy đồng thời cực đại, không phải theo tần suất trigger chạy. File compose trong repository có sẵn 5 worker, tương đương khoảng 11 GB theo mức sizing được công bố. Chạy 2 worker trên VPS 4 GB là điểm bắt đầu hợp lý. docker stats --no-stream sẽ xác nhận con số thực tế cho các flow của bạn trong khi chúng chạy.
Tôi cần backup những gì để restore thực sự hoạt động?
Bạn phải backup cả database dump và encryption key. Với Activepieces, đó là một pg_dump của database activepieces cùng với file .env chứa AP_ENCRYPTION_KEY. Với n8n, đó là database cùng với N8N_ENCRYPTION_KEY. n8n tự tạo file này trong thư mục ~/.n8n nếu bạn chưa thiết lập nó. Với Node-RED, hãy backup toàn bộ volume /data, vì credentials file và key dùng để giải mã file đó đều nằm trong volume này. Windmill là trường hợp ngoại lệ: workspace key nằm trong chính database Postgres của nó. Vì vậy, dump chứa toàn bộ dữ liệu và phải được bảo vệ như chính các secret.
Tôi có thể import workflow n8n vào công cụ khác không?
Không. Các project này import và export format flow riêng, không phải format của n8n. Migration có nghĩa là dựng lại từng flow trong builder mới và tạo lại từng credential từ service gốc. Đây mới là chi phí thực sự khi chuyển đổi, vì vậy hãy đếm số flow trước khi quyết định. 12 flow có thể mất một buổi chiều. 200 flow là một project. Thông thường, chuyển n8n sang dùng queue mode và Postgres để giảm mức sử dụng memory sẽ rẻ hơn việc dựng lại toàn bộ flow.