Tự host OneCLI: mỗi người một agent riêng

Điều bạn nhận được khi tự host OneCLI

Khi tự host OneCLI, mỗi người trong team sẽ có một agent riêng. Mỗi agent chạy trong sandbox riêng, còn API key được lưu trong một gateway mà agent không bao giờ đọc được. Bộ cài là một Docker Compose stack có PostgreSQL phía sau, có thể truy cập tại http://localhost:10254. Hãy chuẩn bị một máy chủ thực sự. Cấu hình mặc định được tài liệu ghi rõ là 2 GiB memory cho mỗi agent sandbox. Vì vậy, đây không phải workload phù hợp với VPS 1 GB.

Stack này có bảy thành phần. Biết chức năng của từng thành phần sẽ giúp bạn đọc các phần còn lại của guide dễ hơn.

• Web dashboard (Next.js), cổng 10254. Tạo agent, chat, chỉnh sửa memory và skill, quản lý connection và secret.
• API server, cổng 10256. Control plane: database, xử lý hội thoại và work queue.
• Rust gateway, cổng 10255. Intercept request outbound từ agent và chèn credential.
• Runner. README mô tả đây là component “khởi động, tạm dừng và thu hồi agent sandbox. Chỉ outbound, không bao giờ truy cập database.”
• Sandbox Supervisor. README mô tả component này chạy “bên trong từng sandbox, giao tiếp qua harness interface không phụ thuộc vendor để có thể thay thế agent runtime.”
• Channel adapter. Một daemon kết nối với Slack app để agent trả lời trong channel và DM bằng tên riêng của agent.
• PostgreSQL. File compose đi kèm chạy postgres:18-alpine với volume pgdata.

Tên gọi là CLI, nhưng sản phẩm là một server

OneCLI là một nền tảng server. Tên gọi khiến bạn nghĩ đây là một command line tool cài trên laptop, nhưng đó không phải là sản phẩm được mô tả trong hướng dẫn này. Có một command line client riêng trong repository onecli/onecli-cli. Client này định tuyến traffic của một coding agent cục bộ qua một gateway. Thứ bạn triển khai ở đây là một web application dành cho nhiều người dùng: hệ thống account trong đó account đầu tiên sở hữu instance, database lưu các cuộc trò chuyện và secret, cùng một runner để khởi chạy các container.

Mô hình mỗi người một agent là nền tảng của toàn bộ thiết kế. README viết: "Bạn tạo một agent cho mỗi người, cấp cho từng agent quyền truy cập cần thiết, rồi agent chạy trong một sandbox và được định tuyến qua gateway để gateway chèn credential và thực thi policy của bạn." Mỗi agent có filesystem và shell riêng, trang hội thoại riêng, memory do platform lưu giữ và các skill bạn chỉ cần viết một lần. Cách quản lý credential cũng ngược với mô hình thông thường. Thay vì sao chép API key vào environment của từng người, bạn lưu key một lần rồi cấp quyền sử dụng key đó cho các agent được phép.

Những gì máy chủ cần có trước khi bắt đầu

• Docker, với Compose plugin phiên bản 2.19 trở lên. File Compose sử dụng một service migration chạy một lần mà API phải chờ, và dạng dependency này cần phiên bản 2.19.
• Bộ nhớ, đây mới là giới hạn thực tế. Đọc phần sizing bên dưới trước khi chọn plan.
• Các port loopback 10254, 10255, 10256 và 5432 chưa được sử dụng.

Bạn không cần tự cài PostgreSQL: file Compose chạy PostgreSQL dưới dạng một service. Bạn cũng không cần Node.js hoặc Rust. Các thành phần này chỉ cần cho quy trình build-from-source, trong đó mise cố định toolchain.

Có thể chạy bao nhiêu agent sandbox trên VPS?

Tài liệu của runner đưa ra các con số cụ thể. Mỗi sandbox được cấp 2048 MB memory (RUNNER_SANDBOX_MEMORY_MB), một CPU (RUNNER_SANDBOX_CPUS) và 512 process (RUNNER_SANDBOX_PIDS). Giới hạn concurrency là 4 (RUNNER_MAX_SANDBOXES). Tài liệu khuyến nghị có khoảng 10 GiB memory trống ngoài base stack để đáp ứng giới hạn này.

[
  {
    "plan": "2 GB box",
    "ram_gb": 2,
    "sandbox_slots": 0
  },
  {
    "plan": "4 GB box",
    "ram_gb": 4,
    "sandbox_slots": 1
  },
  {
    "plan": "8 GB box",
    "ram_gb": 8,
    "sandbox_slots": 3
  },
  {
    "plan": "16 GB box",
    "ram_gb": 16,
    "sandbox_slots": 7
  },
  {
    "plan": "32 GB box",
    "ram_gb": 32,
    "sandbox_slots": 15
  }
]

Các con số slot này chỉ là phép tính, không phải benchmark: lấy tổng memory trừ khoảng 2 GB cho PostgreSQL và 4 service chạy dài hạn, rồi chia cho giới hạn 2 GiB của mỗi sandbox. Theo cơ sở đó, 2 GB box chạy được 0 sandbox, nên plan rẻ nhất hoàn toàn không chạy được hosted agent. 16 GB box còn đủ chỗ cho 7, cao hơn đáng kể giới hạn mặc định là 4 và cao hơn khoảng 10 GiB memory trống mà tài liệu của runner yêu cầu. 32 GB box tăng con số này lên 15.

Có 2 yếu tố làm thay đổi phép tính trên. Sandbox có background process đang chạy sẽ không chuyển sang trạng thái chờ, nên giữ slot vĩnh viễn. Vì vậy, hãy tính RUNNER_MAX_SANDBOXES theo tải duy trì, không phải theo phút bận nhất. Ngoài ra, memory sẽ cạn trước CPU. Mỗi sandbox bị giới hạn ở một CPU, nên 4 agent bận cần 4 core; nhưng 4 agent không hoạt động mà vẫn thức vẫn giữ 8 GiB.

Cài đặt OneCLI bằng Docker Compose

Tài liệu self-hosting của upstream đưa ra đúng chuỗi lệnh này. Chuỗi lệnh ghi 3 secret vào docker/.env bên cạnh file compose, rồi khởi động stack.

git clone https://github.com/onecli/onecli.git && cd onecli/docker
cat > .env <<EOF
SECRET_ENCRYPTION_KEY=$(head -c 32 /dev/urandom | base64)
GATEWAY_INTERNAL_SECRET=$(head -c 32 /dev/urandom | base64)
BETTER_AUTH_SECRET=$(head -c 32 /dev/urandom | base64)
COMPOSE_PROFILES=runner
EOF
chmod 600 .env
docker compose up -d --wait

Đọc block đó trước khi chạy. Heredoc marker không được đặt trong dấu nháy, nên shell sẽ chạy từng head -c 32 /dev/urandom | base64 và ghi kết quả thay vì ghi nguyên văn nội dung. SECRET_ENCRYPTION_KEY là khóa AES-256-GCM dùng cho mọi secret trong database. GATEWAY_INTERNAL_SECRET xác thực gateway với API. BETTER_AUTH_SECRET ký session cookie. COMPOSE_PROFILES=runner là dòng quan trọng nhất, vì service runner nằm sau một Compose profile: bỏ dòng này thì stack vẫn khởi động và báo healthy, nhưng không có agent sandbox nào được chạy.

--wait giữ shell chờ cho đến khi mọi service báo healthy, nên exit code khác 0 là tín hiệu đầu tiên cho biết có vấn đề. Sau đó kiểm tra thực tế những gì đã được khởi động.

docker compose ps
docker compose logs migrations

Cố định version. ONECLI_VERSION đặt tag cho tất cả service cùng lúc, và image của agent sandbox cũng dùng version đó, trừ khi RUNNER_AGENT_IMAGE trỏ sang nơi khác. Tính đến ngày 19 tháng 8 năm 2026, release hiện tại là v2.0.1, được phát hành ngày 18 tháng 8 năm 2026. Thêm version này vào cùng file rồi khởi động lại stack.

echo 'ONECLI_VERSION=v2.0.1' >> .env
docker compose up -d --wait

Cũng có installer là curl -fsSL https://onecli.sh/install | sh. Installer ghi cấu hình vào ~/.onecli/.env và thực hiện cùng công việc. Cách dùng Compose cho phép bạn đọc từng file trước khi bất cứ thứ gì chạy, và phù hợp khi máy đã chạy các Compose stack khác. Build từ source là cách thứ ba, được mô tả lần lượt bằng pnpm install rồi pnpm run setup trong repository đã clone. Cách này vẫn cần mise, Rust cho gateway và Docker, đồng thời dành cho những người muốn thay đổi code.

Truy cập dashboard từ laptop

Mọi port được publish trong file compose đi kèm đều bind vào ${ONECLI_BIND_HOST:-127.0.0.1}. Trên VPS, điều đó có nghĩa là dashboard đang chạy nhưng không có gì bên ngoài máy chủ truy cập được. Đây là thiết lập mặc định đúng. Hãy giữ nguyên và tạo tunnel:

ssh -N -L 10254:127.0.0.1:10254 you@your-server

Bây giờ mở http://localhost:10254 trên laptop. Traffic đi qua kết nối SSH, nên không có dashboard HTTP không mã hóa nào trên Internet công cộng và cũng không cần mở thêm port trên firewall.

Thiết lập ONECLI_BIND_HOST=0.0.0.0 sẽ publish dashboard qua HTTP thuần và đồng thời publish PostgreSQL. Nếu có nhiều người cần dashboard, hãy đặt một reverse proxy có TLS (transport layer security) phía trước port 10254 và giữ nguyên bind host. Hãy làm việc đó trước khi instance có owner. Tài liệu upstream giải thích rất rõ lý do: "Nếu chưa làm vậy, instance chưa có owner; trên một host có thể truy cập, người nào đến trước sẽ trở thành owner." Nếu reverse proxy đó đã đứng trước các ứng dụng self-hosted khác, việc chuyển tiếp xác thực qua một lớp single sign-on tự host sẽ đặt dashboard phía sau login mà team của bạn đang dùng. Khi xóa một người dùng ở một nơi, quyền truy cập qua cửa này cũng bị đóng.

Tạo account đầu tiên, sau đó cấp model key

Mở dashboard và tạo account ngay lập tức. Account đó sở hữu instance. Khi account đã tồn tại, người khác phải tham gia bằng invitation.

Sau đó lưu model key trước khi tạo agent. Hosted agent cần một model key đã được cấp quyền, và thứ tự thực hiện rất quan trọng: lưu key trong dashboard, cấp key cho agent, rồi mới bắt đầu conversation. Nếu bỏ qua bước cấp quyền, sandbox sẽ không khởi chạy. Kết quả là agent không làm gì cả.

Chỉ cấp quyền ở phạm vi cần thiết. Mỗi agent chỉ nhận đúng những quyền bạn đã cấp, và gateway kiểm tra quyền đó trong mọi request. Vì vậy, agent chỉ đọc một repository sẽ không có đường truy cập đến key của payment provider. Danh sách quyền được cấp cũng là công cụ để kiểm soát chi phí. Agent của từng người có thể gọi mọi model bạn sở hữu sẽ tạo ra hóa đơn tương ứng cho từng người. Vì vậy, hãy đọc cách giới hạn số tiền agent có thể chi cho các lần gọi model trước khi cấp quyền cho mười agent.

Cách gateway giữ key ngoài các agent

Gateway là một HTTPS proxy viết bằng Rust, lắng nghe trên port 10255. HTTP client của agent được trỏ đến gateway, còn agent chỉ giữ một credential tạm thời thay vì credential thật. Gateway đối chiếu request gửi đi với các quyền được cấp cho agent đó, giải mã secret thật, thay secret vào request rồi chuyển tiếp request. Các secret được lưu trong PostgreSQL dưới dạng mã hóa bằng AES-256-GCM (advanced encryption standard, 256-bit, Galois/counter mode) và chỉ được giải mã tại thời điểm xử lý request. Mỗi lần gọi đều được ghi log cùng với danh tính agent và đích đến. Đây là audit trail mà bạn không thể có khi key nằm trong shell profile của mười người.

Có 2 cơ chế quyết định cách bạn triển khai gateway.

• HTTPS interception là một cuộc tấn công man-in-the-middle. Gateway tạo một certificate authority cục bộ, agent trust certificate authority đó, sau đó gateway terminate kết nối TLS từ agent và mở một kết nối mới đến upstream service. Vì vậy, agent có HTTP client không trust certificate authority của gateway sẽ fail với lỗi certificate verification thay vì lỗi authentication.
• Agent tự nhận diện bằng header Proxy-Authorization. Trên một máy duy nhất, khi agent và gateway dùng chung một Docker network nội bộ, header đó không đi qua network mà bạn không kiểm soát. Nếu trỏ agent ở máy khác đến gateway, proxy port cần có TLS riêng vì header đó là bearer token.

Đánh đổi cần chấp nhận: gateway đọc mọi request mà agent gửi, ở dạng plaintext, theo đúng thiết kế. Đây là process nhạy cảm nhất trên máy. Hãy bảo vệ host tương ứng và hạn chế số người có thể đăng nhập bằng cách dùng Linux user theo nguyên tắc đặc quyền tối thiểu.

Vì sao runner không cần cổng inbound

Runner chỉ tạo kết nối outbound. Theo tài liệu của nó: “runner không mở cổng nào để bên ngoài có thể truy cập, vì vậy laptop, homelab hoặc VPC nằm sau NAT đều hoạt động mà không cần ingress, tunnel hay cấu hình TLS termination.” NAT là network address translation, tức cơ chế router gia đình sử dụng. Runner kết nối đến control plane và pull công việc từ đó, nên không có gì để forward và cũng không cần mở cổng nào.

Thiết kế này phát huy tác dụng trong sandbox network. File compose định nghĩa một network thứ hai được đánh dấu internal: true. Trong Docker, điều này có nghĩa là network đó hoàn toàn không có route ra ngoài host. Các sandbox kết nối vào network này. Gateway có kết nối vào cả hai network, nên là lối duy nhất để đi ra ngoài. Tài liệu của runner nêu rõ điểm này: “một network internal với gateway có kết nối vào cả hai network là yếu tố biến egress chỉ qua gateway thành một ranh giới thực sự, thay vì chỉ là khuyến nghị.” Nếu agent tự quyết định gửi source code của bạn đến một địa chỉ bất kỳ, nó không có route để thực hiện việc đó.

Hãy tự xác nhận trên máy của bạn thay vì chỉ tin đoạn giải thích trên.

docker network ls
docker network inspect onecli-sandboxes | grep -i internal

Bạn sẽ thấy "Internal": true. Nếu kết quả là false, cơ chế kiểm soát egress đang tắt và gateway lại chỉ còn là khuyến nghị. Hãy dùng đúng tên sandbox network mà docker network ls in ra, vì onecli-sandboxes chỉ là giá trị mặc định.

Mức độ mạnh của sandbox OneCLI đến đâu?

Hãy đọc chậm phần này, vì mô tả riêng của dự án nhấn mạnh rất nhiều vào từ “sandbox”, trong khi cơ chế này chỉ được tài liệu hóa ở đúng một nơi.

README nói mỗi agent có “sandbox biệt lập riêng, với filesystem và shell riêng”, đồng thời xác định Sandbox Supervisor là thành phần “chạy bên trong từng sandbox và giao tiếp qua harness interface không phụ thuộc vendor, để có thể thay thế agent runtime”. Không câu nào trong hai câu này nói rõ isolation được tạo bằng gì. Tài liệu của runner có nói: backend mặc định là Docker (RUNNER_BACKEND=docker), và sandbox là một Docker container có memory cap, CPU cap và process cap, được nối vào internal network. Code có sẵn một điểm mở cho các backend khác, còn tài liệu nêu Kubernetes và microVM là những module mà người khác phải tự viết. Hiện tại, trên máy của bạn, sandbox là một container.

Những điều tài liệu không nói cũng quan trọng không kém. Không có threat model. Không có tuyên bố rằng Docker daemon chạy rootless, rằng user namespace remapping được bật, hoặc rằng có seccomp hay AppArmor profile nào ngoài các mặc định của Docker. Cũng không có cam kết về kernel boundary như gVisor hoặc microVM. Vì vậy, hãy hiểu theo phạm vi hẹp. Các cap chỉ giới hạn tài nguyên. Internal network thực sự là một cơ chế kiểm soát egress. Mức isolation giữa agent và host của bạn chỉ tương đương những gì một Docker container mặc định cung cấp, và container dùng chung kernel với host.

Có một sự thật thứ hai cần cân nhắc. Runner service mount /var/run/docker.sock vì đó là cách nó tạo sandbox. Quyền truy cập Docker socket tương đương quyền root trên host, vì bất kỳ ai có thể gọi API đó đều có thể khởi động một container và mount filesystem của host vào trong container. Mọi runner dùng Docker backend đều hoạt động theo cách này. Hệ quả là runner process nhạy cảm không kém gateway.

Hãy xem boundary này là chưa được chứng minh cho đến khi upstream ghi rõ trong tài liệu. Trên thực tế, điều đó có nghĩa là bạn nên duy trì 3 thói quen.

1. Chạy OneCLI trên một máy không làm việc gì khác. Không chạy service production không liên quan, không dùng chung database và không lưu dữ liệu của team khác.
2. Giả định rằng agent có arbitrary code execution bên trong sandbox có thể tiếp cận host, rồi chuẩn bị để tình huống đó vẫn có thể khắc phục bằng backup được lưu ngoài máy.
3. Đọc apps/runner/src hoặc hỏi upstream trước khi nói với đồng nghiệp rằng agent đã được containment.

Để xem một boundary được tài liệu hóa đầy đủ thường được mô tả thế nào và nên hỏi upstream những gì, hãy đối chiếu phần này với mô tả boundary của một agent sandbox thực sự. Điểm khác biệt nằm ở việc cơ chế đã được ghi rõ hay chưa, và cơ chế đó không ngăn được những gì.

Phân tách giấy phép và lý do cần kiểm tra trước khi triển khai

Phần core của OneCLI dùng Apache-2.0 và được phép self-host trong môi trường production. Các thư mục có tên ee/ thuộc OneCLI Enterprise License riêng: miễn phí cho development, testing và evaluation, nhưng cần subscription để sử dụng trong production. Release notes của v2.0.1 ngày 18 August 2026 đề cập việc khôi phục file licence Apache-2.0 để GitHub có thể phát hiện, nên badge trên trang repository gần đây đã thay đổi. Hãy kiểm tra tag mà bạn thực sự triển khai, thay vì dựa vào một bản tóm tắt được viết vào thời điểm khác.

cd onecli && find . -type d -name ee -not -path '*/node_modules/*'

Mọi thứ nằm trong các path đó đều thuộc phần thương mại. Nếu feature mà bạn dự định phụ thuộc vào nằm ở đó, hãy kiểm tra chi phí trước khi xây dựng quy trình dựa trên feature đó.

Nâng cấp, migration và một file không được để mất

Nâng cấp gồm tăng version và restart. Một service migration chạy một lần sẽ chạy trước API trong mỗi up, và nếu migration thất bại, stack sẽ không khởi động thay vì phục vụ với schema mới một nửa. Đây là hành vi cần có, vì khi nâng cấp thất bại, lỗi sẽ biểu hiện như một outage thay vì âm thầm làm hỏng dữ liệu, và docker compose logs migrations giải thích lý do.

cd onecli/docker
docker compose pull
docker compose up -d --wait
docker compose logs migrations

Nếu bạn cài bằng install script, hãy chạy lại script đó thay vì tự pull thủ công, để file compose luôn đồng bộ với các image mà nó tham chiếu.

Hãy backup 2 thứ. PostgreSQL lưu agent, conversation, memory và các secret đã mã hóa. File docker/.env lưu SECRET_ENCRYPTION_KEY, và nếu không có key này thì không thể đọc các secret đã mã hóa. Vì vậy, chỉ có database dump thì không khôi phục được hệ thống ở trạng thái sử dụng được.

cd onecli/docker
docker compose exec -T postgres pg_dump -U onecli onecli | gzip > ~/onecli-db.sql.gz
install -m 600 .env ~/onecli-env.backup

Lưu cả 2 bản sao bên ngoài máy chủ. Quy trình này giống quy trình cần có cho mọi stateful Compose stack. Nếu bạn đã backup và nâng cấp một Docker Compose stack theo lịch, hãy thêm 2 path này vào quy trình đó rồi không cần bận tâm thêm.

Khi hệ thống không hoạt động

• Stack không bao giờ chuyển sang trạng thái healthy và docker compose up -d --wait thoát với mã khác 0. Trước tiên hãy đọc docker compose logs migrations, vì API cố ý chờ service đó.
• Agent ở trạng thái nhàn rỗi và không xuất hiện sandbox. Kiểm tra COMPOSE_PROFILES=runner có nằm trong docker/.env không, đồng thời kiểm tra docker compose ps có liệt kê runner không. Sau đó kiểm tra agent đã được cấp model key chưa, vì sandbox không khởi chạy nếu thiếu key này.
• Không còn slot. RUNNER_MAX_SANDBOXES mặc định là 4, và sandbox có background process đang chạy sẽ giữ slot vĩnh viễn. docker ps hiển thị những gì thực sự đang chạy.
• Container biến mất hoặc host chạy ì ạch. Máy đã hết memory. dmesg -T | grep -i oom ghi lại các lần kernel kill process do thiếu memory, và một sandbox có thể tự chiếm 2048 MB.
• Các request HTTPS của agent thất bại với lỗi xác minh certificate thay vì lỗi authentication. HTTP client của agent không trust certificate authority của gateway.
• Container hoặc volume cũ vẫn còn sau khi bạn xóa agent. Runner reconcile mỗi 60 giây và xóa orphan cũ hơn RUNNER_ORPHAN_GRACE_SECONDS, mặc định là 3600, vì vậy hãy chờ một giờ trước khi kết luận đây là memory leak.

Đây có phải là lựa chọn phù hợp với bạn không?

Bài kiểm tra mức độ phù hợp khá ngắn. OneCLI phù hợp khi nhiều người đều cần một agent và bạn muốn quản lý credentials ở một nơi: một store để xoay vòng, một audit log để đọc, một dashboard để khi thu hồi quyền truy cập của một người thì quyền đó thực sự bị thu hồi. Đây là một vấn đề vận hành thực tế, và việc sao chép một API key vào 6 laptop là cách xử lý tệ hơn.

Với một người, đây là quá nhiều thành phần mà không mang lại lợi ích. Bạn sẽ phải chạy PostgreSQL, một control plane, một gateway và một runner chỉ để cung cấp một agent cho chính mình. Trong trường hợp chỉ bạn giữ key, vấn đề credentials mà gateway giải quyết gần như không tồn tại. Thay vào đó, hãy chạy một harness duy nhất trên một máy nhỏ hơn: một agent harness duy nhất trên VPS có thể đảm nhiệm việc đó với chỉ một phần nhỏ lượng memory. Nếu bạn vẫn chưa chọn hướng nào, khảo sát so sánh các self-hosted AI agent là bước đầu tiên ít tốn kém hơn.

FAQ

Yêu cầu máy chủ tối thiểu để self-host OneCLI là gì?

Cần Docker có Compose plugin phiên bản 2.19 trở lên và đủ memory. PostgreSQL đã có trong compose file, nên không cần cài riêng. Memory quyết định quy mô triển khai: runner mặc định cấp 2048 MB cho mỗi agent sandbox, tài liệu yêu cầu khoảng 10 GiB trống ngoài base stack để phục vụ giới hạn mặc định là 4 sandbox, và khoảng 2 GB dành cho PostgreSQL cùng 4 service chạy lâu dài. Máy 4 GB chạy được mỗi lần 1 agent. Máy 16 GB đáp ứng thoải mái giới hạn mặc định. VPS 1 GB hoặc 2 GB không thể khởi động hosted agent.

OneCLI có cần PostgreSQL không, hay có thể dùng SQLite?

OneCLI cần PostgreSQL. DATABASE_URL được mô tả là PostgreSQL connection string, compose file đi kèm chạy postgres:18-alpine với volume pgdata, và một migrations service sẽ áp dụng schema trước khi API khởi động. Không có tài liệu nào về tùy chọn SQLite. Nếu bạn đã chạy PostgreSQL ở nơi khác, hãy trỏ DATABASE_URL đến instance đó và giữ migrations service, vì migration lỗi sẽ dừng stack thay vì để stack phục vụ với schema mới áp dụng dở dang.

Agent sandbox của OneCLI có phải là một ranh giới bảo mật thực sự không?

Cơ chế được tài liệu hóa là một Docker container có giới hạn memory, CPU và số process, được gắn vào network đánh dấu internal: true nên không có route ra ngoài, ngoại trừ qua gateway. Egress control này là có thật và bạn có thể xác minh bằng docker network inspect. Mức cô lập với host tương đương container, nhưng upstream không công bố threat model, không đưa ra cam kết về rootless hoặc user namespace, và cũng không có kernel boundary như gVisor hay microVM. Runner còn mount /var/run/docker.sock, tương đương quyền root trên host. Hãy coi ranh giới giữa agent và host là chưa được chứng minh cho đến khi upstream nêu rõ, chạy OneCLI trên một máy riêng và lưu backup ngoài máy đó.

Tôi có cần mở cổng inbound nào cho OneCLI không?

Không. Runner chỉ tạo kết nối outbound và không giữ cổng nào mà thế giới bên ngoài có thể truy cập, nên có thể hoạt động phía sau NAT mà không cần tunnel. Compose file mặc định bind dashboard, gateway, API và PostgreSQL vào 127.0.0.1. Truy cập dashboard qua SSH tunnel, hoặc đặt reverse proxy có TLS phía trước cổng 10254 nếu có nhiều người cần truy cập. Gateway tại cổng 10255 dành cho agent; trên một máy duy nhất, các agent này truy cập gateway qua Docker network nội bộ.

OneCLI có được sử dụng miễn phí trong công ty không?

Core dùng Apache-2.0 và được phép sử dụng trong môi trường production self-hosted mà không cần commercial licence. Các directory có tên ee/ thuộc OneCLI Enterprise License. Licence này miễn phí cho development, testing và evaluation, nhưng cần subscription trong production. Phạm vi phân chia thay đổi giữa các release. Ghi chú của v2.0.1 ngày 18 August 2026 đề cập việc khôi phục licence file Apache-2.0 có thể được GitHub nhận diện. Vì vậy, hãy kiểm tra LICENSE và các directory ee/ trong đúng tag bạn triển khai trước khi xây dựng workflow phụ thuộc vào bất kỳ feature riêng lẻ nào.