Hướng dẫn tự host Rakazo AI bot trên VPS Linux

Rakazo tự host thực sự chạy những gì

Tự host Rakazo nghĩa là chạy năm thành phần trên một máy chủ Linux: PostgreSQL, một tiến trình Graphile Worker, API, ứng dụng web và một container sandbox cho mỗi bot đang hoạt động. Rakazo là giải pháp thay thế mã nguồn mở cho Grok Bot, được elie222 phát hành theo giấy phép Apache 2.0. Mỗi bot có thread riêng, tài nguyên tính toán riêng, bộ nhớ riêng và lịch sử riêng, đồng thời có thể tạo ra các peer hoặc các subagent tồn tại trong thời gian ngắn. Nếu các thuật ngữ như bộ nhớ (memory), subagent và gọi công cụ (tool call) trong câu trên còn xa lạ, một lộ trình từng bước về cách các agent thực sự hoạt động sẽ rất đáng để bạn dành một buổi chiều tìm hiểu, vì hầu hết các thiết lập bên dưới chỉ có ý nghĩa khi bạn hình dung được bot đang làm gì lúc nó thức dậy.

Đó là lý do tại sao phần này cần chạy trên một VPS (virtual private server) chứ không phải trên máy tính cá nhân. Một bot cần duy trì bộ nhớ và chạy các tác vụ theo lịch trình phải luôn sẵn sàng ngay cả khi bạn đang ngủ. Một chiếc laptop chuyển sang chế độ ngủ (suspend) sẽ làm mất hàng đợi (queue).

Rakazo đang ở giai đoạn beta sớm tính đến tháng 8 năm 2026, vì vậy hãy coi đây là một thiết lập đang hoàn thiện thay vì một sản phẩm đóng gói sẵn. Toàn bộ stack đều sử dụng TypeScript: React 19 và Vite cho ứng dụng web, Hono cho API, Postgres với Prisma, Better Auth để quản lý tài khoản và Graphile Worker cho các tác vụ chạy ngầm. Graphile Worker lưu trữ hàng đợi bên trong Postgres, vì vậy không cần Redis hay bất kỳ kho dữ liệu thứ hai nào khác. .env.example thiết lập WAKEUP_DRIVER=graphile, nghĩa là việc một bot thức dậy chính là một job được hỗ trợ bởi Postgres. Dừng Postgres đồng nghĩa với việc mọi tác vụ bot theo lịch trình cũng dừng theo. Nếu bạn muốn tự lắp ráp một agent từ các thành phần thay vì chạy sản phẩm của người khác, tự xây dựng agent từ các thành phần là hướng đi còn lại.

Tại sao gói 1 GB không đủ đáp ứng

Hãy đếm số tiến trình. Postgres là một. API là một tiến trình Node. Worker là tiến trình thứ hai. Web app là tiến trình thứ ba. Sandbox supervisor là tiến trình thứ tư. Sau đó, mỗi bot đang chạy sẽ chiếm một container chứa môi trường desktop Linux đồ họa và trình duyệt.

Tài liệu tự host của dự án đưa ra một con số thực tế: máy chủ 2 vCPU và 4 GB RAM là đủ cho API, worker và Postgres khi E2B quản lý các desktop của bot. Đó là con số chỉ dành cho control plane, với phần nặng nhất được host ở nơi khác. Nếu bạn thiết lập SANDBOX_PROVIDER=docker, các desktop đó sẽ chuyển về VPS của bạn, vì vậy 4 GB trở thành mức tối thiểu thay vì mức mục tiêu. Hãy bắt đầu với 8 GB nếu bạn dự định giữ nhiều hơn một bot hoạt động, và đo lường con số thực tế bằng docker stats trong khi bot đang làm việc. Trình duyệt bên trong sandbox là thứ làm tiêu tốn RAM, nên bảng thông số kỹ thuật sẽ không cho bạn biết chính xác. Để biết phương pháp chung về việc chọn cấu hình máy chủ cho tác vụ agent, RAM và CPU thực tế cần cho một VPS agent sẽ hướng dẫn chi tiết cách đo lường.

Một thiết lập giúp tình trạng này không trở nên tồi tệ hơn. .env.example đi kèm với SANDBOX_IDLE_MS=600000 cùng chú thích rằng nó sẽ tạm dừng các máy tính E2B, hoặc dừng các máy Docker, sau khoảng thời gian mili giây nhàn rỗi đó. Sau mười phút không hoạt động, máy tính sẽ bị xóa. Giá trị tối thiểu được chấp nhận là 30000. Nếu không có thiết lập này, mọi bot bạn từng mở sẽ chiếm dụng RAM mãi mãi.

Dung lượng đĩa cũng quan trọng. Image của sandbox, các Node module và volume của Postgres dùng chung một ổ đĩa, vì vậy 40 GB là mức khởi điểm hợp lý.

Ghim phiên bản trước khi clone

Rakazo phát triển rất nhanh và main không phải là một bản release chính thức. Tính đến ngày 16 tháng 8 năm 2026, repository này chỉ có duy nhất một tag là v0.1.0-beta, được công bố vào ngày 13 tháng 8 năm 2026 và được đánh dấu là bản prerelease.

git clone https://github.com/elie222/rakazo.git
cd rakazo
git checkout 53b119a68d9ef843d23aa3b7e3719b6be7b51fdb
git log -1 --format='%H %ci'

Commit đó là commit mà v0.1.0-beta trỏ tới. Hãy pin commit thay vì branch hoặc tag. Branch có thể thay đổi sau lần git pull tiếp theo. Tag là một nhãn có thể di chuyển mà maintainer có thể trỏ sang commit khác. Vì vậy, cả hai đều không xác định một tree mà bạn có thể quay lại. Identifier của commit không thể thay đổi. Hãy ghi lại identifier này cùng với các thông tin khác về server. Khi một lần upgrade làm hỏng hệ thống, cách sửa rẻ nhất là git checkout <old commit> và rebuild. Cách này chỉ hiệu quả nếu bạn biết commit nào đang hoạt động. Việc pin chính xác như vậy là chi phí khi dùng beta, không phải quy tắc áp dụng cho mọi dự án. Với dự án có các bản release được phát hành có chủ đích, bạn có thể giữ ở một tag đã publish. Một stack self-host nhỏ hơn như openGym áp dụng cách này.

Yêu cầu: Node 22, pnpm 9 và Docker

node -v
pnpm -v
docker --version

package.json khai báo "engines": { "node": ">=22" } và "packageManager": "pnpm@9.15.0", vì vậy node -v phải in ra v22 hoặc cao hơn. Gói Node trong kho lưu trữ của Ubuntu thường cũ hơn mức đó, nên hãy cài đặt từ NodeSource hoặc nvm. pnpm đi kèm với Node thông qua corepack:

corepack enable
corepack prepare pnpm@9.15.0 --activate

Docker Engine cùng với plugin compose sẽ xử lý các phần còn lại, và user của bạn phải có quyền truy cập vào daemon. Nếu docker ps trả về permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock, hãy thêm user của bạn vào nhóm docker và mở một login shell mới. Hãy hiểu rõ quyền hạn này trước: thành viên trong nhóm docker tương đương với quyền root trên máy chủ, vì bất kỳ ai trong nhóm đó đều có thể khởi chạy container và mount filesystem của host.

Cấu hình .env, sau đó khởi động Postgres

cp .env.example .env
chmod 600 .env

Hai giá trị cần thay đổi trước khi đưa bất kỳ thứ gì ra mạng. .env.example phát hành BETTER_AUTH_SECRET=replace-with-32-plus-character-secret và ENCRYPTION_KEY=replace-with-64-char-hex-or-passphrase. Rakazo từ chối các giá trị giữ chỗ đó bên ngoài môi trường phát triển, vì vậy một bản deploy cấu hình dở dang sẽ báo lỗi thay vì chạy với một secret đã bị công khai trong repository.

openssl rand -base64 48
openssl rand -hex 32

Sau đó, khởi chạy database riêng biệt và thực hiện các migration.

docker compose --env-file .env -f infra/compose/docker-compose.yml up postgres -d
pnpm install
pnpm db:generate
pnpm db:migrate
pnpm sandbox:build

pnpm sandbox:build xây dựng image máy tính cho bot, được định nghĩa trong package.json là docker build -t rakazo/computer:local infra/sandboxes/computer. Đây là một image đồ họa, nên lần build đầu tiên sẽ tải về nhiều dữ liệu và mất thời gian. Xác nhận image đã có bằng docker image ls rakazo/computer, lệnh này sẽ in ra một dòng kết quả.

File compose xuất bản Postgres dưới dạng 127.0.0.1:5433:5432, chỉ giới hạn ở loopback. Hãy giữ nguyên như vậy. Các thông tin xác thực cho môi trường phát triển là rakazo:rakazo, chúng nằm trong repository, và một cổng Postgres có thể truy cập từ Internet với mật khẩu công khai sẽ bị các trình quét tìm thấy trong vòng vài giờ. File compose cho môi trường production đọc POSTGRES_PASSWORD thay vào đó, vì vậy hãy đặt giá trị đó thành một chuỗi ngẫu nhiên khi bạn thực hiện bước đó.

Lần chạy đầu tiên

pnpm dev

Lệnh này khởi chạy bốn thành phần: API trên cổng 3100, Graphile Worker, ứng dụng web Vite trên cổng 5173 và sandbox supervisor trên cổng 7091. Ứng dụng nằm tại http://127.0.0.1:5173, và bạn sẽ thấy trang đăng nhập.

Trên một VPS, bạn không ngồi trực tiếp tại máy đó, và bạn không nên mở cổng 5173 ra ngoài để truy cập. Thay vào đó, hãy forward các cổng qua SSH (secure shell) từ máy của bạn.

ssh -L 5173:127.0.0.1:5173 -L 3100:127.0.0.1:3100 you@your-server

Hãy cẩn thận với sự khác biệt giữa hai cách chạy này. pnpm dev chạy Vite trên host, bind cục bộ. Service web trong file compose publish cổng 5173:5173 trên mọi interface. Nếu bạn chạy toàn bộ stack development compose trên một VPS công cộng, ứng dụng sẽ bị lộ ra ngoài. Vì vậy, hãy sử dụng file production và reverse proxy của nó cho bất kỳ dịch vụ nào bạn để chạy lâu dài.

Nhà cung cấp sandbox nào an toàn trên máy chủ?

Đây là thiết lập quan trọng nhất cần thực hiện đúng. SANDBOX_PROVIDER trong .env nhận bốn giá trị.

• docker là mặc định. Mỗi bot nhận một container riêng trên máy của bạn, được build từ image mà pnpm sandbox:build tạo ra. Đây là thiết lập self-hosted nhanh nhất.
• e2b chạy các máy tính bot trên E2B và cần E2B_API_KEY. Dự án khuyến nghị dùng cách này cho các triển khai công cộng hoặc đa người dùng, vì nó tách biệt máy tính bot khỏi host đang chạy API và database của bạn.
• desktop chạy các lệnh của bot trực tiếp trên host API và worker. Hướng dẫn của repository đã nói rõ: không sử dụng nó trên máy chủ công cộng hoặc máy chủ dùng chung.
• fake là trình giả lập in-process dành cho kiểm thử. Nó không phải là môi trường runtime.

Hãy coi cảnh báo về desktop mode là nghiêm túc. Ở chế độ desktop, hoàn toàn không có ranh giới cô lập nào, vì vậy bot chạy các lệnh shell với tư cách người dùng đang chạy tiến trình API, cùng với thư mục home, SSH keys, thông tin xác thực cloud và .env của người dùng đó. Văn bản trên một trang web mà bot đọc được sẽ trở thành một lệnh trên máy chủ của bạn. Chế độ desktop trên máy chủ là cách khiến bot chiếm đoạt thông tin xác thực của bạn. Chỉ dùng nó trên máy tính cá nhân, hoặc tốt nhất là không dùng. Việc chuyển đổi nhà cung cấp sẽ đặt một container xung quanh đường dẫn trang web đó thay vì đóng nó lại, và cung cấp cho bot một backend tìm kiếm SearXNG riêng sẽ giải quyết cùng một bề mặt tấn công từ phía tìm kiếm.

docker là một ranh giới thực sự nhưng chưa hoàn hảo. Một bot không thể đọc file của bot khác vì mỗi bot có container riêng. Tuy nhiên, supervisor tạo ra các container đó lại mount /var/run/docker.sock, và quyền kiểm soát Docker socket của host đồng nghĩa với quyền kiểm soát toàn bộ host. Vì vậy, hãy giữ supervisor ở chế độ riêng tư. .env.example ghi nhận SANDBOX_SUPERVISOR_TOKEN là một thông tin xác thực dịch vụ riêng biệt tùy chọn, mặc định là BETTER_AUTH_SECRET khi để trống, nghĩa là nếu để secret đó ở giá trị mặc định thì dịch vụ tạo container sẽ được bảo vệ bằng một chuỗi ký tự mà bất kỳ ai trên GitHub cũng có thể đọc được. Hãy thiết lập cả hai giá trị này. Để có sự tách biệt mạnh mẽ nhất hiện có, hãy sử dụng e2b, hoặc cấp cho Rakazo một máy riêng không chứa dữ liệu gì khác. Đó cũng là lý do đằng sau việc chạy các coding agent trong một VM dùng một lần: cách rẻ nhất để sống sót khi một agent thực hiện sai lệnh là đảm bảo máy của nó không chứa bất kỳ giá trị nào.

API key của model được đặt ở đâu?

Rakazo không quản lý việc thanh toán cho model. Bạn phải tự cung cấp key. .env.example thiết lập PI_DEFAULT_PROVIDER=openrouter, vì vậy OPENROUTER_API_KEY là nơi thông thường để đặt, và key của nhà cung cấp cũng hoạt động thông qua thiết lập tương tự.

Hãy giữ key trong .env và không đưa vào bất kỳ file nào bạn commit. Cả hai lệnh compose trong repository đều truyền --env-file .env, vì vậy các giá trị sẽ đến được container mà không bao giờ bị ghi vào file YAML mà git theo dõi. Bạn cũng có thể để trống OPENROUTER_API_KEY và dán key vào ứng dụng trong quá trình onboarding, đây là một lý do nữa khiến ENCRYPTION_KEY cần một giá trị ngẫu nhiên thực sự thay vì giá trị mặc định được cung cấp sẵn.

Hãy thiết lập hạn mức chi tiêu cho key tại nhà cung cấp trước khi bot bắt đầu sử dụng nó. Một bot bị lặp vô tận là một bot tiêu tốn tiền, và hạn mức theo từng key là chốt chặn duy nhất không phụ thuộc vào việc bạn có đang theo dõi hay không. Hãy đặt tên riêng cho key này để bạn có thể thu hồi nó một cách độc lập. Nếu bạn đang thiết lập hệ thống này cho một nhóm thay vì cho cá nhân, Cổng gateway OneCLI duy nhất cho agent của mọi người là một giải pháp khác cho cùng một vấn đề, vì nó giữ các key của nhà cung cấp tại một nơi thay vì mỗi người một key.

Chuyển từ chế độ dev sang môi trường production

Repository cung cấp một file compose cho production, chạy Postgres, API, worker, web app và Caddy để tự động lấy chứng chỉ TLS (transport layer security). Nó yêu cầu E2B cho các máy tính bot.

sudo DEPLOY_USER=deploy bash infra/compose/harden-host.sh
docker compose --env-file .env -f infra/compose/docker-compose.prod.yml up -d --build

harden-host.sh vô hiệu hóa đăng nhập bằng mật khẩu SSH, thiết lập các quy tắc UFW (uncomplicated firewall) cho SSH, HTTP và HTTPS, bật fail2ban và áp dụng các profile AppArmor. Hãy đọc kỹ trước khi chạy vì nó thay đổi cách bạn đăng nhập. Hãy giữ một phiên SSH thứ hai luôn mở trong khi script chạy.

.env cho production cần nhiều tài nguyên hơn bản development. Tài liệu self-host liệt kê các yêu cầu tối thiểu này.

NODE_ENV=production
RAKAZO_HOST=app.example.com
BETTER_AUTH_URL=https://app.example.com
WEB_ORIGIN=https://app.example.com
API_URL=https://app.example.com
POSTGRES_PASSWORD=<random>
BETTER_AUTH_SECRET=<random>
ENCRYPTION_KEY=<random>
E2B_API_KEY=<your key>
OPENROUTER_API_KEY=<your key>
SANDBOX_PROVIDER=e2b
AGENT_RUNTIME=pi
DATA_DIR=/data

Trỏ một bản ghi A về máy chủ trước khi chạy up lần đầu. Caddy sẽ yêu cầu chứng chỉ cho tên miền trong RAKAZO_HOST, và yêu cầu này sẽ thất bại nếu tên miền không phân giải về máy chủ này hoặc nếu cổng 80 bị chặn từ bên ngoài.

Đồng thời thiết lập SIGNUP_ALLOWLIST=you@example.com. SIGNUPS_ENABLED=true là giá trị mặc định, vì vậy một instance trên tên miền công khai sẽ chấp nhận đăng ký từ bất kỳ ai tìm thấy nó, và mỗi tài khoản mới sẽ được cấp một máy tính. Hãy sử dụng allowlist trước. Bạn có thể nới lỏng sau nếu muốn. Nếu bạn đã chạy nhiều dịch vụ trên cùng một máy chủ và muốn quản lý một danh sách người dùng thay vì mỗi app một allowlist, việc đặt một instance Authentik phía trước sẽ chuyển quyết định đó về phía proxy, mặc dù nó nằm trước các tài khoản Better Auth của Rakazo chứ không thay thế chúng.

Hãy coi docs/self-host.md trong repository là nguồn thông tin chính xác cho các thiết lập production, vì nó thay đổi theo code còn hướng dẫn này thì không. Vì Compose đảm nhận việc vận hành, các quy tắc thông thường vẫn áp dụng, và các kiến thức cơ bản về Docker Compose cho VPS giải thích lý do tại sao --env-file và named volumes lại quan trọng hơn khi một stack được vận hành liên tục trong nhiều tháng.

Sao lưu

Postgres và thư mục data/ là toàn bộ instance của bạn.

./scripts/backup.sh
./scripts/restore.sh backups/BACKUP_TIMESTAMP

backup.sh thực hiện dump Postgres và lưu trữ data/. Đối với máy chủ quan trọng, hãy cài đặt infra/compose/backup-prod.sh dưới dạng /usr/local/sbin/rakazo-backup cùng với timer đi kèm trong repository để quá trình xoay vòng diễn ra tự động. Bản sao lưu nằm trên cùng ổ đĩa với cơ sở dữ liệu không được coi là bản sao lưu, vì vậy hãy copy nó ra khỏi máy chủ. Sau đó, hãy thực hiện khôi phục thử một lần trên một máy chủ dự phòng trước khi bạn thực sự cần đến nó.

Tại sao nó thất bại và bạn sẽ thấy gì

pnpm db:migrate không thể kết nối tới database. Quá trình migration báo lỗi không thể kết nối tới database server tại 127.0.0.1:5433. Hoặc là container Postgres chưa chạy, hoặc nó đã chạy nhưng chưa sẵn sàng. Hãy chạy docker compose --env-file .env -f infra/compose/docker-compose.yml ps và kiểm tra xem service postgres có báo trạng thái healthy hay không, vì file compose đã thiết lập health check chạy mỗi ba giây. Một container khởi động lại liên tục thường có nghĩa là volume pgdata đã được tạo với thông tin xác thực khác. docker compose ... down -v sẽ xóa sạch nó, đồng thời xóa luôn cả dữ liệu bên trong.

Cổng đã bị chiếm. Việc khởi động Postgres thất bại với bind: address already in use khi có thứ gì đó đang giữ cổng 5433, thường là một stack Rakazo cũ mà bạn quên chưa dừng. sudo ss -lntp | grep 5433 sẽ cho biết tên của tiến trình đó.

Bot không nhận được máy tính. Với SANDBOX_PROVIDER=docker mà không có image rakazo/computer:local, sẽ không có gì để khởi động cả. docker image ls rakazo/computer trả lời vấn đề đó trong một dòng, và pnpm sandbox:build sẽ khắc phục nó. Nếu supervisor không thể kết nối tới Docker socket, nó cũng không thể tạo container, và thông báo lỗi sẽ chỉ ra đường dẫn: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock.

Một lệnh dài bị ngắt giữa chừng. .env.example thiết lập SANDBOX_COMMAND_TIMEOUT_MS=300000, nên một lệnh đơn lẻ bên trong máy tính của bot sẽ bị ngắt sau năm phút. Hãy tăng giá trị này cho các bản build chậm thay vì cho rằng sandbox đã bị crash.

pnpm install bị lỗi theo những cách khó hiểu. Hãy kiểm tra node -v trước bất cứ thứ gì khác. Workspace khai báo >=22, và một phiên bản Node cũ sẽ gây lỗi trong code dependency thay vì báo lỗi về phiên bản.

Đăng nhập hoạt động ở local nhưng không qua domain. BETTER_AUTH_URL, WEB_ORIGIN và API_URL đều phải chứa cùng một public origin như trên thanh địa chỉ, bao gồm cả scheme. Một giá trị http://127.0.0.1:5173 cũ còn sót lại trong một trong các cấu hình này thường là nguyên nhân khiến session không bao giờ duy trì được.

Cập nhật bản checkout đã ghim

Quy trình nâng cấp trong tài liệu self-host rất ngắn gọn: kéo source code mới về, chạy migration database, sau đó khởi động lại API và worker.

./scripts/backup.sh
git fetch --all
git checkout NEW_COMMIT_SHA
pnpm install
pnpm --filter @rakazo/db migrate
docker compose --env-file .env -f infra/compose/docker-compose.prod.yml up -d --build

Hãy backup trước. Các migration chỉ tiến về phía trước, và phiên bản beta không cung cấp lộ trình quay lại an toàn. Hãy đọc các commit giữa SHA hiện tại và SHA mới trước khi thực hiện, vì một dự án còn non trẻ như thế này thường đổi tên các biến môi trường mà không thông báo trước. Một biến môi trường bị thiếu sẽ khiến service khởi động rồi thoát ngay lập tức. Nếu bạn vẫn đang cân nhắc liệu Rakazo có phù hợp để chạy hay không, bài tổng hợp các AI agent self-hosted sẽ bao gồm các lựa chọn khác trong cùng phân khúc và chi phí duy trì của từng loại.

FAQ

Tôi có thể chạy Rakazo trên VPS 1 GB không?

Không. Postgres, API, worker, sandbox supervisor và web app đều chạy cùng lúc, và với SANDBOX_PROVIDER=docker, mỗi bot đang hoạt động sẽ thêm một container chứa desktop đồ họa và trình duyệt. Tài liệu của dự án nêu rõ 2 vCPU và 4 GB RAM chỉ đủ cho API, worker và Postgres khi E2B host các desktop của bot. Hãy coi 4 GB là mức tối thiểu cho control plane, và cần cấu hình cao hơn nếu bạn chạy desktop trên máy chủ của mình.

Provider sandbox desktop có an toàn trên server không?

Không. desktop chạy các lệnh của bot trực tiếp trên host của API và worker, dưới quyền của user đang chạy tiến trình đó, khiến các file và credential của user đó bị lộ. Repository khuyến cáo không sử dụng nó trên server công cộng hoặc server dùng chung. Hãy sử dụng docker để tạo mỗi container cho một bot, hoặc e2b khi có nhiều người cùng đăng nhập.

Tôi nên cài đặt phiên bản Rakazo nào?

Tính đến ngày 16 tháng 8 năm 2026, chỉ có một tag là v0.1.0-beta, được phát hành ngày 13 tháng 8 năm 2026 và được đánh dấu là bản prerelease. Hãy checkout commit mà nó trỏ tới, 53b119a68d9ef843d23aa3b7e3719b6be7b51fdb, thay vì theo dõi main. Một branch có thể thay đổi và một tag có thể bị trỏ lại, nên cả hai đều không định danh chính xác một tree mà bạn có thể quay lại. Hãy ghi lại mã commit, vì việc rollback chỉ khả thi khi bạn biết chính xác phiên bản nào đã hoạt động ổn định.

Tôi đặt OpenRouter API key ở đâu?

Trong .env dưới dạng OPENROUTER_API_KEY, và tuyệt đối không đưa vào file compose mà bạn commit. Cả hai lệnh compose trong repository đều truyền --env-file .env, nên giá trị này sẽ đến được các container mà không cần ghi vào file YAML được track. Bạn cũng có thể để trống và dán key vào ứng dụng trong quá trình onboarding. Hãy thiết lập hạn mức chi tiêu cho key tại nhà cung cấp, vì một bot bị kẹt trong vòng lặp sẽ liên tục gọi model cho đến khi có thứ gì đó ngăn nó lại.

Tôi có cần tên miền và TLS không?

Đối với bất kỳ mục đích nào ngoài việc thử nghiệm lần đầu, câu trả lời là có. File compose cho môi trường production chạy Caddy và tự động lấy chứng chỉ, đồng thời RAKAZO_HOST, BETTER_AUTH_URL, WEB_ORIGIN và API_URL đều phải sử dụng chung một origin HTTPS công khai. Để xem qua lần đầu, bạn có thể bỏ qua tên miền: chạy pnpm dev và forward cổng 5173 qua SSH thay vì publish nó ra ngoài.