Cài Cloudron trên VPS Ubuntu: DNS và yêu cầu

Cài Cloudron trên VPS: bản tóm tắt

Để cài Cloudron trên VPS, bạn cần một máy chủ Ubuntu mới, ít nhất 2 GB RAM và một domain có thể chỉnh sửa bản ghi DNS. Quá trình cài đặt chỉ gồm 3 lệnh và 1 lần reboot. Hầu hết lỗi xảy ra trước bước này (chọn sai base image, sai loại virtualization) hoặc sau đó (DNS, mail, backup).

wget https://cloudron.io/cloudron-setup
chmod +x cloudron-setup
sudo ./cloudron-setup

Cloudron cài đặt, cập nhật, backup và cấp chứng chỉ TLS (transport layer security) cho các app tự host. Mỗi app chạy trong Docker, nginx đứng trước toàn bộ các app và mỗi app có một subdomain riêng trong domain của bạn. Vì vậy, việc cấu hình DNS phải được thực hiện trước.

Vì sao Cloudron yêu cầu khắt khe về hệ điều hành nền

Script cài đặt kiểm tra server trước khi cài bất kỳ thứ gì. Nếu một kiểm tra thất bại, bạn phải đặt một server mới. Hãy đọc các yêu cầu này trước khi chọn image.

• Chỉ hỗ trợ Ubuntu và chỉ 3 bản phát hành. Các hệ điều hành khác sẽ thoát với Cloudron requires Ubuntu 20.04, 22.04, 24.04. Debian, Rocky và Alpine không được hỗ trợ. Ubuntu 24.04 cần Cloudron 8 hoặc mới hơn; script sẽ tự kiểm tra điều này.
• Chỉ hỗ trợ Intel hoặc AMD 64-bit: Error: Cloudron only supports amd64/x86_64. VPS ARM không chạy được.
• Chỉ hỗ trợ ảo hóa phần cứng đầy đủ. Trên VPS dựa trên container, script dừng với Error: Cloudron does not support lxc, only runs on bare metal or with full hardware virtualization vì phát hiện container bằng systemd-detect-virt --container. KVM được hỗ trợ. OpenVZ và LXC không được hỗ trợ.
• Filesystem root phải là ext4 hoặc xfs. Với các loại khác, bạn sẽ nhận Error: Cloudron requires '/' to be ext4 or xfs. Đây là nguyên nhân image btrfs và zfs không cài được.
• Cần ít nhất 941 MB RAM và 20 GB trên /. Các giá trị này được đo bằng free -m và kích thước của filesystem root.
• Server phải thực sự mới. Nếu nginx, docker hoặc node đã được cài đặt, script sẽ từ chối với Error: Some packages like nginx/docker/nodejs are already installed.

Đây là kiểm tra thường gây tranh luận, nên dưới đây là lý do. Cloudron cài các phiên bản cố định của Docker, nginx, Node.js và MySQL, ghi cấu hình nginx cho mọi app được host trên máy, đồng thời tự quản lý các rule firewall iptables. Docker bạn cài hôm qua có thể không đúng phiên bản, còn các file site hiện có của nginx sẽ bị thay thế. Cloudron quản lý toàn bộ máy, vì vậy hãy cấp cho nó một VPS riêng.

Có một kiểm tra khác rất dễ bỏ sót. Trên CPU cũ không có AVX (advanced vector extensions), script in ra CPU has no AVX support. MongoDB will be disabled và mọi app cần MongoDB sẽ không thể cài đặt. Trước khi triển khai, hãy kiểm tra CPU bằng grep -m1 -o avx /proc/cpuinfo. Lệnh này in avx trên host có hỗ trợ và không in gì trên máy cũ.

Cloudron cần bao nhiêu RAM?

Script từ chối chạy khi RAM dưới 941 MB, với Error: Cloudron requires atleast 1GB physical memory, và tài liệu yêu cầu 2 GB RAM cùng 20 GB disk. Cả hai con số này là mức tối thiểu cho platform, không phải cho platform cộng với các app của bạn. Trước khi bạn cài một app, Cloudron đã chạy Docker, nginx, service box riêng, các database container mà nó cung cấp cho app (MySQL, PostgreSQL, MongoDB), Redis và mail stack. Chạy docker ps trên một bản cài mới rồi đếm các container đó.

Giới hạn bộ nhớ của app được tính thêm trên nền tảng cơ sở này. Mỗi app package có một giới hạn mặc định thấp. Bạn tăng giới hạn này bằng slider trong mục Resources của app. Khi app vượt quá giới hạn, app sẽ restart và gửi thông báo OOM (out of memory). Vì vậy, một máy chủ liên tục restart một app thường gặp vấn đề về giới hạn hơn là bug.

Đây là cấu hình tôi sẽ đặt mua. Các mức này dành cho một server mà bạn không phải rebuild vào tháng sau. Đây không phải kết quả benchmark được đo thực tế.

[
  {
    "label": "2 apps (free tier)",
    "vcpu": 2,
    "ram_gb": 4,
    "disk_gb": 60
  },
  {
    "label": "5 apps",
    "vcpu": 4,
    "ram_gb": 8,
    "disk_gb": 120
  },
  {
    "label": "10 apps",
    "vcpu": 6,
    "ram_gb": 16,
    "disk_gb": 240
  }
]

Hai app chạy ổn với 4 GB RAM và 60 GB disk. Khoảng 10 app cần 16 GB RAM và 240 GB disk, vì phần nền của platform không bao giờ giảm, còn mỗi app thêm một Docker image, một database và dữ liệu riêng. Disk đầy nhanh hơn nhiều người nghĩ: image, dữ liệu app và backup local dùng chung một volume cho đến khi bạn chuyển backup ra khỏi máy.

Cloudron cấp swap không giới hạn cho mọi app, vì vậy giới hạn bộ nhớ bạn đặt chỉ áp dụng cho RAM. Trên một VPS image không có file swap, swapon --show hoàn toàn không in ra gì, và áp lực bộ nhớ chuyển thẳng thành các lần restart do OOM thay vì khiến app chạy chậm. Thêm 2 GB swap là một biện pháp dự phòng rẻ, nhưng không thể thay thế RAM thực. Chênh lệch giữa các gói VPS nhỏ hơn nhiều so với số giờ bạn sẽ mất để tinh chỉnh giới hạn, vì vậy hãy xem chi phí thực tế của VPS và chọn gói lớn hơn kế tiếp.

DNS: bản ghi wildcard giúp các subdomain của app hoạt động

Cloudron đặt dashboard tại my.example.com và mỗi app trên một subdomain riêng, vì vậy DNS là điều kiện tiên quyết chứ không phải bước làm sau. Trỏ các bản ghi sau đến địa chỉ IP public của server trước khi mở dashboard lần đầu:

• my.example.com dưới dạng bản ghi A. Đây là dashboard.
• *.example.com dưới dạng bản ghi A. Bản ghi này giúp các subdomain của app hoạt động, nên wiki.example.com và git.example.com sẽ phân giải ngay khi bạn cài các app đó.
• example.com dưới dạng bản ghi A, chỉ khi bạn muốn chạy một app trên domain gốc.

Bản ghi wildcard có độ ưu tiên thấp hơn bản ghi tường minh, nên bản ghi www.example.com hiện có và đang trỏ đến nơi khác vẫn tiếp tục hoạt động.

Trong quá trình thiết lập, bạn chọn cách Cloudron xử lý DNS từ thời điểm đó:

• Nhà cung cấp API. Cloudron lưu token cho Cloudflare, DigitalOcean, Route53, Hetzner, Porkbun, Linode, deSEC, Gandi, Namecheap và khoảng hai mươi nhà cung cấp khác, rồi tự ghi mọi bản ghi, bao gồm cả bản ghi mail.
• Wildcard. Bạn tự thêm bản ghi * và Cloudron không ghi bản ghi nào.
• Thủ công. Cloudron hiển thị từng bản ghi và chờ bạn thêm bản ghi đó trước mỗi lần cài app.

Bản ghi DNS wildcard không phải là certificate wildcard. Nhà cung cấp certificate mặc định là Let's Encrypt Prod - Wildcard. Certificate này xác minh quyền sở hữu qua DNS, nên chỉ hoạt động với nhà cung cấp API. Với backend Wildcard hoặc Manual, hệ thống chuyển sang cấp một certificate cho mỗi app và xác thực qua HTTP. Vì vậy, cổng inbound 80 phải luôn được mở. Nếu registrar hoặc DNS host của bạn có trong danh sách API, hãy dùng nhà cung cấp đó: cả bản ghi mail và certificate đều không còn là việc bạn phải tự quản lý.

Hãy xác minh trước khi tiếp tục. dig +short my.example.com và dig +short anything.example.com đều phải in ra địa chỉ IP của server. Nếu truy vấn wildcard không trả về gì, các app sẽ lỗi về sau trong khi dashboard vẫn hoạt động bình thường.

Nếu domain nằm sau Cloudflare, hãy đặt các bản ghi ở chế độ DNS only. Proxy chỉ chuyển tiếp HTTP và HTTPS, nên các cổng mail sẽ bị lỗi và mọi app sẽ thấy địa chỉ Cloudflare thay vì địa chỉ của visitor.

Chạy script thiết lập

wget https://cloudron.io/cloudron-setup
chmod +x cloudron-setup
sudo ./cloudron-setup

Chạy script với quyền root hoặc thông qua sudo, vì nếu không, dòng đầu tiên nó in ra sẽ là This script should be run as root.. Quá trình cài đặt mất vài phút và không hiển thị nhiều thông tin trong lúc chạy, vì output của apt và các lần pull Docker được ghi vào một file log. Theo dõi log từ một phiên SSH thứ hai:

tail -f /var/log/cloudron-setup.log

Cuối cùng, script in After reboot, visit one of the following URLs and accept the self-signed certificate to finish setup. kèm theo địa chỉ của server, rồi hỏi The server has to be rebooted to apply all the settings. Reboot now ? [Y/n]. Trả lời yes. Có thể dùng flag --skip-reboot nếu cần lên lịch reboot, nhưng không thể sử dụng Cloudron cho đến khi máy khởi động lại xong.

Khởi động lần đầu: domain, DNS backend và tài khoản admin

Mở https://<server-ip> và chấp nhận cảnh báo của trình duyệt. Chứng chỉ là self-signed vì Cloudron chưa biết domain của bạn, nên chưa có thông tin để yêu cầu certificate authority cấp chứng chỉ. Trong Chrome, nhấp vào Advanced, sau đó nhấp Proceed to <ip> (unsafe). Trong Firefox, nhấp vào Advanced, sau đó nhấp Accept the Risk and Continue.

Màn hình đầu tiên yêu cầu domain của bạn. Nhập example.com và dashboard sẽ hoạt động tại my.example.com. Bạn cũng có thể dùng subdomain như cloudron.example.com, khi đó dashboard sẽ ở my.cloudron.example.com. Chọn DNS backend, dán API token nếu có, rồi tạo tài khoản admin bằng một địa chỉ email bạn thực sự đọc: Let's Encrypt registration và mọi cảnh báo của platform đều sử dụng địa chỉ này.

Sau khi lưu, Cloudron sẽ yêu cầu cấp chứng chỉ và chuyển dashboard sang https://my.example.com. URL dùng địa chỉ IP sẽ ngừng hoạt động tại thời điểm đó, vì vậy hãy bookmark URL mới.

Chứng chỉ: cơ chế gia hạn và thời điểm dừng

Việc gia hạn chứng chỉ là tự động và tuân theo ACME Renewal Information (ARI), tức lịch do tổ chức cấp chứng chỉ công bố. Trên thực tế, chứng chỉ thường được gia hạn khoảng một tháng trước khi hết hạn. Nếu gia hạn thất bại, hệ thống sẽ gửi email đến tài khoản quản trị. Khi chứng chỉ hết hạn, hệ thống sẽ chuyển về chứng chỉ tự ký tích hợp sẵn. Đây là nguyên nhân của cảnh báo trình duyệt trên một site vẫn hoạt động bình thường vào ngày hôm trước.

Hai nguyên nhân chiếm phần lớn các trường hợp. Xác thực HTTP cần port 80 nhận kết nối từ bên ngoài. Vì vậy, đóng port 80 với lý do “mọi thứ đều dùng HTTPS rồi” sẽ làm hỏng việc gia hạn cho mọi app dùng backend Wildcard hoặc Manual DNS. Xác thực DNS cần một API token vẫn có quyền ghi. Vì vậy, việc xoay vòng hoặc thu hẹp quyền của token này sẽ âm thầm làm hỏng quá trình gia hạn cho đến khi email cảnh báo được gửi.

Giao diện Domains có nút Renew All để buộc thử gia hạn ngay lập tức và có provider Let's Encrypt Staging để kiểm thử. Chứng chỉ Staging cố ý không được trình duyệt tin cậy. Đây chính là mục đích của chúng: bạn có thể thử lại bao nhiêu lần tùy ý mà không tiêu tốn rate limit của môi trường production.

Bạn có nên dùng mail server tích hợp sẵn không?

Cloudron cung cấp một mail stack hoàn chỉnh với mailbox IMAP, submission, bộ lọc sieve và ký DKIM (domainkeys identified mail). Bạn bật tính năng này cho từng domain trong mục Email của dashboard. Đưa mail đến mailbox đích mới là phần khó, và những khó khăn đó không nằm ở Cloudron.

• Hầu hết nhà cung cấp VPS chặn outbound port 25 để chống spam. Một số nhà cung cấp sẽ mở port này sau khi bạn gửi support ticket. Kiểm tra từ server bằng nc -zv aspmx.l.google.com 25 (cài netcat-openbsd nếu chưa có command này). Báo cáo port đang mở là succeeded. Port bị chặn sẽ treo cho đến khi timeout.
• PTR record (reverse DNS) do nhà cung cấp VPS thiết lập, không phải DNS host. PTR phải khớp với mail hostname. Mail gửi từ địa chỉ có PTR chung chung thường bị đưa vào spam folder.
• Bạn khai báo các record SPF, DKIM và DMARC trên API DNS backend. Với Wildcard hoặc Manual backend, bạn phải tự thêm các record này. Thiếu DKIM record nghĩa là mọi message bạn ký đều không thể được xác minh.

Cấu hình phù hợp với hầu hết người dùng là nhận mail trên Cloudron và gửi mail qua relay như SendGrid, Postmark, Mailgun hoặc Amazon SES. Bạn cấu hình relay trong chế độ xem Email. Relay phải cho phép gửi bằng mọi địa chỉ thuộc domain của bạn. Nếu không, notification từ các app dùng sender khác nhau sẽ bị từ chối. Nếu mail là lý do chính khiến bạn mua server, hãy chạy mail server riêng như Mailcow trên một máy riêng với IP reputation riêng.

Nếu không dùng Cloudron Email, hãy block các port 25, 465, 587, 993 và 4190 trong firewall của nhà cung cấp. Hãy block tại đó, không phải trên server, vì Cloudron tự ghi các rule iptables và yêu cầu được quản lý các rule này. Điều này ngược với một VPS thông thường, nơi bạn tự quản lý các rule ufw.

Cấu hình đích backup trước khi cần dùng

Mặc định, backup được lưu trên filesystem cục bộ tại /var/backups, cùng ổ đĩa với mọi thành phần khác. Tài liệu nêu rất rõ: "Lưu backup trên cùng ổ đĩa vật lý với server platform là nguy hiểm." Một ổ đĩa hỏng sẽ làm mất cả ứng dụng lẫn backup.

Mở Backups, sau đó chọn Backup Sites, rồi cấu hình đích lưu trữ khác ngay từ ngày đầu tiên. Object storage tương thích với S3 là lựa chọn phổ biến (Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces hoặc một bucket MinIO trên server thứ hai). Ngoài ra, hệ thống cũng hỗ trợ các đích SSHFS, NFS, CIFS và filesystem thông thường.

Ba thiết lập quyết định backup đó có thực sự hữu ích hay không:

• Định dạng. tgz tạo một compressed archive cho mỗi app và upload lại toàn bộ archive ở mỗi lần chạy. rsync chỉ upload các file đã thay đổi, giúp giảm chi phí đáng kể với một instance Nextcloud lớn, nhưng tạo ra nhiều request hơn đến storage API.
• Mã hóa. Tùy chọn này dùng AES-256 để mã hóa cả nội dung file và filename. Cloudron không lưu bản sao password, vì vậy nếu mất password thì không ai có thể giải mã backup, kể cả bạn. Hãy lưu password trong password manager tự host trước khi bấm save.
• Chính sách lưu giữ. Giá trị được nhập dưới dạng số lượng, chẳng hạn 7 bản daily và 4 bản weekly. Thời gian lưu giữ dài trên object storage sẽ phát sinh phí hàng tháng, nên hãy chọn số lượng mà bạn sẵn sàng tiếp tục trả phí.

Sau đó, hãy kiểm tra việc restore. Cài một app nhỏ, restore app đó từ dashboard và theo dõi quá trình khôi phục cùng dữ liệu của app. Một bản backup chưa từng được restore chỉ là một giả định.

Giới hạn của gói miễn phí

Tính đến tháng 8 năm 2026, gói miễn phí giới hạn ở 2 ứng dụng được cài đặt. Gói này vẫn bao gồm mọi tính năng khác: cập nhật ứng dụng, backup riêng cho từng ứng dụng, firewall, mail server và single sign-on. Ứng dụng thứ 3 là lúc bạn cần licence. Các gói trả phí bỏ giới hạn số ứng dụng. Gói cao hơn còn thêm user group và role, directory server, cùng nhiều site backup. Giá có thể thay đổi, vì vậy hãy xem trang giá Cloudron thay vì dùng một con số trong tutorial.

Một licence chỉ áp dụng cho 1 Cloudron install. Vì vậy, 2 server nhỏ có giá gấp đôi 1 server lớn. Cách tính giá này khiến đa số người dùng chọn 1 VPS lớn hơn, trái với khuyến nghị thông thường là phân tách các service trên nhiều máy. Hãy tính dung lượng server dựa trên điều đó, vì tách các service về sau sẽ khiến bạn phải trả phí 2 lần.

Khi có sự cố

Bắt đầu bằng công cụ kiểm tra tích hợp sẵn. Công cụ này lần lượt kiểm tra DNS, chứng chỉ, disk, memory và từng service, rồi cho biết bài kiểm tra nào thất bại:

sudo cloudron-support --troubleshoot

Sau đó, dùng các công cụ systemd (system và service manager) thông thường. systemctl status box hiển thị trạng thái của chính Cloudron service, journalctl -u box -n 100 hiển thị log gần đây của service này, còn journalctl -u docker kiểm tra container runtime bên dưới. Mọi lỗi xảy ra trong quá trình cài đặt được ghi trong /var/log/cloudron-setup.log.

Dashboard không tải được thường là do DNS hoặc firewall của nhà cung cấp, không phải do Cloudron. Chạy dig +short my.example.com từ laptop của bạn và xác nhận cổng 80 và 443 đã được mở trong network firewall của nhà cung cấp. Đây là một cơ chế kiểm soát riêng với các rule của chính server. Nếu bạn bắt đầu lại, script sẽ từ chối lần chạy thứ hai bằng Error: Cloudron is already installed. To reinstall, start afresh. Khi đó, cách xử lý đúng là rebuild server.

Khi Cloudron không phù hợp

Cloudron phù hợp khi bạn muốn chạy các ứng dụng thay vì tự quản lý hạ tầng. Cloudron không phù hợp khi bạn muốn tự quản lý các container theo cách của mình, vì nó quản lý nginx, Docker và firewall, đồng thời sẽ ghi đè các cấu hình bạn đặt tại đó. Nếu kế hoạch của bạn là quản lý một thư mục chứa các file compose, Traefik đứng trước các stack Docker Compose của bạn sẽ cung cấp TLS tự động và định tuyến subdomain tương tự mà không thêm một platform bên trên. Nếu bạn chưa chọn giải pháp, so sánh Cloudron, CasaOS và Coolify sẽ đặt chúng cạnh nhau, còn danh sách đầy đủ hơn về những gì có thể tự host là điểm bắt đầu phù hợp hơn so với một hướng dẫn cài đặt.

FAQ

Cloudron cần bao nhiêu RAM trên VPS?

Script cài đặt từ chối chạy khi RAM dưới 941 MB và tài liệu yêu cầu 2 GB, nhưng đó là mức tối thiểu cho platform khi chưa chạy app nào. Cloudron chạy Docker, nginx, service box riêng, các database container và mail stack ngay từ lần boot đầu tiên. Dành 4 GB cho hai app và 16 GB cho khoảng mười app, đồng thời thêm swap file, vì Cloudron cho app dùng swap không giới hạn và máy không có swap sẽ biến áp lực bộ nhớ thành các lần restart.

Tôi có thể cài Cloudron trên Debian hoặc trên server đã chạy Docker không?

Cả hai trường hợp đều không được. Script kiểm tra bản phát hành rồi dừng với Cloudron requires Ubuntu 20.04, 22.04, 24.04, vì vậy Debian, Rocky và Alpine không được hỗ trợ. Script cũng dừng khi nginx, docker hoặc node đã tồn tại, vì Cloudron cài các phiên bản cố định của tất cả thành phần này và tự ghi cấu hình nginx cùng các rule iptables. Hãy bắt đầu từ một Ubuntu image mới trên KVM VPS.

Vì sao các app subdomain của tôi không hoạt động trong khi dashboard vẫn hoạt động?

Wildcard DNS record bị thiếu. Setup tạo hoặc yêu cầu một A record cho my.example.com, nên dashboard phân giải được, trong khi wiki.example.com trả về NXDOMAIN và browser báo không tìm thấy site. Thêm A record cho *.example.com trỏ đến IP của server, rồi xác nhận bằng dig +short wiki.example.com trước khi cài app.

Tôi có phải dùng mail server của Cloudron không?

Không. Bạn có thể tắt email gửi đến và gửi qua một external relay như Postmark, Mailgun hoặc Amazon SES. Đây là lựa chọn an toàn hơn khi provider chặn outbound port 25 hoặc IP address chưa có uy tín gửi mail. Nếu bỏ qua hoàn toàn Cloudron Email, hãy đóng các port 25, 465, 587, 993 và 4190 trong firewall của provider thay vì trên server.

Điều gì xảy ra khi tôi đạt giới hạn hai app của gói miễn phí?

Dashboard chặn lần cài thứ ba và yêu cầu licence key. Các app đang chạy không bị ảnh hưởng: chúng vẫn được update, vẫn được backup và vẫn giữ certificate. Thêm licence sẽ gỡ giới hạn mà không cần cài lại, vì vậy gói miễn phí là cách hợp lý để thử platform trước trên một domain thật.