Đến nội dung chính
Phạm Nam

Tìm kiếm

Nhập từ khoá để tìm trong các bài viết.

Quay lại

Tự host Coolify: PaaS mã nguồn mở trên VPS riêng

Hướng dẫn tự host Coolify trên VPS: cài đặt, deploy app đầu tiên bằng git push, HTTPS tự động, backup, rollback và các giới hạn cần biết trước khi dùng.

10 phút đọc—

Một app web nhỏ, nhìn từ ngoài vào, chỉ là vài trang và một database. Nhưng để nó chạy ổn định, bạn phải lo domain, HTTPS, reverse proxy, build code, biến môi trường, database, log và backup. Với một app, Docker Compose xử lý tốt. Với ba đến năm dịch vụ, cách làm rời rạc đó bắt đầu rối: mỗi app một cách cấu hình, một cách deploy, một chỗ xem log.

Vercel, Heroku hay Netlify giải quyết điểm đau này: đẩy code lên Git là có deploy mới, domain, HTTPS và preview cho pull request. Đổi lại là chi phí theo mức sử dụng và dữ liệu nằm ngoài server của mình. Coolify là cách giữ trải nghiệm “git push là deploy” mà vẫn chạy trên VPS riêng.

Lưu ý thẳng thắn: bài này đối chiếu lệnh và tính năng với tài liệu chính thức tại ngày 27/10/2026. Phần cài đặt dưới đây mình chưa chạy thử trên VPS thật, nên bạn cần đối chiếu lại tài liệu mới nhất trước khi chạy lệnh.

Coolify là gì?

Coolify là nền tảng PaaS mã nguồn mở, tự host được, dùng để triển khai ứng dụng, database và dịch vụ lên server của chính người dùng. Nó thay thế Heroku, Netlify và Vercel ở một điểm cốt lõi: thay vì thuê hạ tầng của nhà cung cấp PaaS, bạn chạy Coolify trên VPS của mình và nó quản lý server, ứng dụng, database qua kết nối SSH.

Dự án dùng giấy phép Apache-2.0. Tại ngày 27/10/2026, kho GitHub có khoảng 64.987 star, 5.833 fork, bản mới nhất v4.5.0 ra ngày 23/10/2026, lần đẩy code gần nhất ngày 26/10/2026. Con số này chỉ cho thấy dự án đang được duy trì tích cực, không phải bằng chứng về chất lượng tuyệt đối. Hãy kiểm tra lại release mới nhất trước khi cài.

Coolify nhận code từ GitHub, GitLab, Bitbucket và Gitea, build bằng Nixpacks, Railpack, Dockerfile, Docker Compose hoặc image có sẵn. Mỗi lần push có thể tự động deploy, pull request có preview riêng, deploy lỗi rollback được về image đã giữ lại. Ngoài ra còn có hơn 360 dịch vụ dựng sẵn bằng vài cú nhấp chuột, kèm lưu trữ bền vững và thông tin đăng nhập tự sinh.

Ai nên dùng, ai chưa cần

Theo mình, Coolify hợp nhất với đội nhỏ, freelancer, homelab và doanh nghiệp muốn chủ quyền dữ liệu với chi phí VPS cố định. Khi bạn quản lý vài website, công cụ nội bộ, staging và production tách biệt, một dashboard để deploy, xem log và đặt lịch backup tiết kiệm rất nhiều thao tác SSH rời rạc.

Ba trường hợp chưa cần Coolify: hệ thống cần autoscaling đa vùng và failover tự động kiểu Kubernetes; bạn chỉ chạy đúng một app đơn lẻ, lúc đó Docker Compose trực tiếp nhẹ hơn; và bạn không muốn chịu trách nhiệm cập nhật, backup, giám sát server — khi đó nền tảng quản lý sẵn vẫn hợp lý hơn.

Kiến trúc và cơ chế deploy

Điểm quan trọng nhất: Coolify không phải runtime mới. Nó là control plane biến SSH và Docker thành trải nghiệm PaaS. Hiểu đúng điểm này giúp bạn đánh giá đúng cả lợi ích lẫn rủi ro.

Control plane là dashboard, API, CLI và MCP — nơi khai báo server, ứng dụng, database, domain, biến môi trường, lịch backup và quyền theo team. Destination server là máy đích nhận deploy qua SSH và chạy workload bằng Docker. Hai tầng này có thể nằm chung một máy, nhưng với hệ thống quan trọng thì không nên, lý do sẽ nói ở phần cài đặt.

Luồng deploy điển hình: push code, mở pull request hoặc gọi webhook, Coolify nhận sự kiện và build image trên server đích theo builder đã chọn. Sau đó nó cấp domain, cấu hình reverse proxy, cấp HTTPS tự động và chạy health check. Container chạy trong mạng riêng, log build và runtime xem được từ dashboard, kèm terminal container và theo dõi tài nguyên.

Với pull request, Coolify tạo preview để xem trước thay đổi. Khi deploy mới lỗi, bạn rollback về image đã giữ lại. Lưu ý: rollback khôi phục ứng dụng, không tự khôi phục dữ liệu database đã bị ghi đè nếu không có backup riêng.

Coolify chạy trên Linux, phụ thuộc Docker trên server đích, SSH ổn định, domain đã trỏ về server và cổng 80/443 mở để cấp HTTPS. Nó không phải trình điều phối đa node như Kubernetes, không hứa hẹn autoscaling hay failover tự động. Nói cách khác, Coolify quản lý “nhiều server” chứ không biến chúng thành cụm tự cân bằng tải. Bạn cộng thêm server đích khi cần thêm chỗ chạy, nhưng phân tải và chuyển đổi dự phòng vẫn phải thiết kế riêng.

Cài đặt Coolify trên VPS

Điều kiện tiên quyết

Tài liệu chính thức yêu cầu tối thiểu 2 CPU, 2 GB RAM, 10 GB đĩa trống, amd64 hoặc arm64. Máy nhỏ hơn, ví dụ 1 CPU và 512 MB RAM, vẫn có thể chạy nhưng không được khuyến nghị. Theo mình, đừng tiết kiệm ở mức này nếu bạn build code trên cùng server, vì build rất dễ thiếu RAM.

Hệ điều hành được liệt kê gồm Debian/Ubuntu, họ RHEL (CentOS, Fedora, RHEL, AlmaLinux, Rocky), SUSE, Arch, Alpine và Raspberry Pi OS 64-bit. Quan trọng hơn cấu hình là dùng server mới, chưa chạy dịch vụ khác. Cài lên server đã có dịch vụ chiếm cổng 80/443 hoặc Docker cấu hình sẵn là nguyên nhân xung đột thường gặp nhất. Trước khi cài, hãy chụp snapshot VPS, chuẩn bị domain đã trỏ về IP VPS và quyền root hoặc sudo.

Cài đặt bằng lệnh chính thức

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

Trước khi pipe script từ internet sang bash, hãy tải script về và đọc qua. Script cài đặt có quyền thay đổi hệ thống, bạn nên biết nó sẽ làm gì. Chỉ chạy trên server mới, và ghi lại output cuối của trình cài đặt, vì nó in ra bước tiếp theo.

Kiểm tra và đăng nhập lần đầu

docker ps

Kết quả mong đợi: các container liên quan tới Coolify xuất hiện trong danh sách, ở trạng thái đang chạy. Sau đó mở dashboard bằng địa chỉ trình cài đặt đã công bố — thường là domain bạn đã trỏ về VPS, hoặc IP kèm cổng do installer in ra. Lần đầu truy cập, bạn tạo tài khoản quản trị đầu tiên.

Nếu không vào được dashboard, kiểm tra theo thứ tự: firewall và cổng đã mở chưa, Docker có đang chạy không, rồi đọc lại log trình cài đặt. Phần lớn trường hợp kẹt ở một trong ba bước này, không phải do Coolify hỏng.

Deploy ứng dụng đầu tiên

Bốn bước: thêm server đích; kết nối kho Git và chọn builder (Nixpacks/Railpack cho app thông thường, Dockerfile/Docker Compose nếu dự án đã có sẵn, prebuilt image nếu chỉ chạy image đã build); khai báo domain, bật HTTPS tự động, nhập biến môi trường và secret; bấm deploy rồi theo dõi log build, log runtime và health check.

Nếu có điều kiện, hãy tách server chạy Coolify khỏi server chạy workload ngay từ đầu. Nếu gộp cả hai lên cùng một VPS, một sự cố ở máy đó đồng thời làm mất cả dashboard quản trị lẫn ứng dụng đang chạy, và nút rollback trên dashboard cũng không cứu được khi host đã sập. Vì vậy, coi Docker host — chứ không phải dashboard — là tầng cần giám sát, backup và khôi phục đầu tiên.

Lỗi thường gặp

Server không trắng gây xung đột cổng 80/443 hoặc Docker sẵn có: dùng server mới hoặc dọn cổng trước khi cài. Domain chưa trỏ đúng IP khiến HTTPS không cấp được: kiểm tra DNS trước khi kết luận Coolify lỗi. Server quá yếu khiến build chậm hoặc thiếu RAM: nâng lên mức tối thiểu khuyến nghị. Build fail do thiếu biến môi trường hoặc Dockerfile chưa phù hợp: đọc log build trong dashboard thay vì deploy lại mù.

Đánh giá: ưu điểm, nhược điểm và bảo mật

Ưu điểm rõ nhất là trải nghiệm PaaS trên hạ tầng riêng: git-push deploy, preview cho pull request, rollback, backup, tác vụ theo lịch, thông báo, API, CLI và MCP. Chi phí dễ dự đoán theo VPS thay vì theo mức sử dụng, dữ liệu và cấu hình nằm trong hạ tầng bạn kiểm soát. Hơn 360 dịch vụ một chạm giúp dựng nhanh database, hàng đợi hay công cụ nội bộ mà không viết lại Compose từ đầu.

Đánh đổi lớn nhất là bạn tự gánh vận hành: cập nhật Coolify, Docker, hệ điều hành, chứng chỉ, backup và giám sát đều thuộc về người vận hành. Coolify không thay thế Kubernetes cho bài toán đa cụm, autoscaling hay failover phức tạp. Khi lỗi sâu ở tầng Docker hay mạng, bạn vẫn cần kỹ năng debug Docker, không thể chỉ bấm dashboard mà xong.

Về hiệu năng và chi phí, bài này không đưa con số so sánh với Vercel hay Heroku, vì tài liệu đã kiểm tra không công bố benchmark như vậy và mình cũng chưa đo đạc. Căn cứ duy nhất để lập kế hoạch là mức tối thiểu 2 CPU, 2 GB RAM, 10 GB đĩa và khuyến nghị tách server Coolify khỏi server workload.

Về bảo mật, bảo vệ dashboard trước tiên: tài khoản quản trị mạnh, bật xác thực đa yếu tố nếu phiên bản bạn cài hỗ trợ, giới hạn IP truy cập quản trị khi được, phân quyền theo team thay vì dùng chung tài khoản root. Secret quản lý qua biến môi trường của Coolify, không commit secret vào repo. Khóa SSH cho server đích phải kiểm soát chặt và thu hồi khi nhân sự rời đội.

Cập nhật cũng là một phần của bảo mật: cập nhật Coolify, Docker và hệ điều hành theo lịch, luôn backup cấu hình Coolify cùng dữ liệu workload trước mỗi lần nâng cấp lớn. Quan trọng hơn, hãy thử khôi phục từ backup trước khi sự cố thật xảy ra — một bản backup chưa từng thử khôi phục thì chưa thể gọi là backup.

So sánh với các giải pháp cùng phạm vi

Bảng dưới đây so sánh những giải pháp cùng giải quyết bài toán deploy ứng dụng, theo tiêu chí người vận hành thực sự phải chọn.

Giải phápMô hìnhDeployHTTPSRollback/backupĐa serverPhù hợp với
CoolifySelf-hosted PaaS trên Docker qua SSHGit push, preview PRTự độngVề image đã giữThêm server đíchĐội nhỏ, homelab, doanh nghiệp cần PaaS trên VPS riêng
Dokploy, CapRoverCùng họ self-hosted PaaSTương tự, đối chiếu tại thời điểm đọcTự độngTùy công cụTùy công cụNgười muốn so sánh thêm lựa chọn cùng họ
Docker Compose thuầnKhông có dashboard PaaSThủ công qua SSHTự cấu hìnhTự lo bằng script, snapshotKhôngChỉ 1–2 app, muốn nhẹ nhất
Vercel, Heroku, NetlifyManaged PaaSGit push, preview PRTự độngTheo nền tảngDo nền tảng loKhông muốn vận hành server
KubernetesĐiều phối cụm containerGitOps, manifest, HelmTự cấu hìnhCó, nhưng phức tạpCụm đa node thật sựCụm lớn, cần autoscaling và failover

Kết luận thẳng: chọn Coolify khi cần trải nghiệm PaaS mà vẫn giữ server riêng. Chọn Compose khi chỉ có 1–2 app. Chọn managed PaaS khi không muốn vận hành. Chọn Kubernetes khi bài toán thực sự là cụm đa node.

Coolify dùng trong thực tế cho những kịch bản nào?

Với doanh nghiệp nhỏ và đội IT nội bộ, Coolify gom website, CRM nội bộ, công cụ vận hành, staging và production tách biệt về một dashboard, dữ liệu ở trong hạ tầng do doanh nghiệp kiểm soát. Tách môi trường bằng server đích khác nhau cũng tránh lỗi deploy nhầm bản thử nghiệm lên production.

Với homelab, một dashboard cho blog, media server, database và công cụ tự host giúp thử nghiệm nhanh: preview của pull request và dịch vụ một chạm cho phép dựng thử mà không làm bẩn server chính, xóa đi cũng gọn hơn dọn container thủ công.

Với DevOps cho đội nhỏ, Coolify chuẩn hóa luồng git-push deploy, preview cho pull request, rollback nhanh, log tập trung và tách staging với production. Đây là mức chuẩn hóa vừa đủ, không cần dựng cả pipeline GitOps phức tạp.

Với prototype AI và ứng dụng full-stack, Coolify deploy nhanh từ repo Git, gắn database và dịch vụ một chạm để demo. Lưu ý riêng: workload AI nặng GPU không thuộc phạm vi VPS Coolify thông thường, cần đánh giá riêng về phần cứng và driver.

Với quản trị hệ thống, Coolify giúp quản lý nhiều server từ một dashboard, theo dõi tài nguyên, đặt lịch backup và tác vụ định kỳ, thay vì SSH từng máy để chạy lệnh rời rạc. Giá trị nằm ở việc gom thao tác lặp lại về một chỗ có log và lịch rõ ràng.

Kết luận

Nên tự host Coolify nếu bạn là đội nhỏ, freelancer, homelab hoặc doanh nghiệp cần PaaS trên VPS riêng, đã quen Docker và chấp nhận tự vận hành: cập nhật, backup, giám sát và bảo mật SSH đều thuộc về bạn. Không nên dùng nếu bạn chỉ chạy một app tĩnh đơn giản, cần autoscaling và failover đa vùng, hoặc không muốn chịu trách nhiệm về server.

Bước tiếp theo: chụp snapshot VPS, cài trên server trắng theo tài liệu mới nhất, deploy một app thử nghiệm và một dịch vụ một chạm, rồi kiểm tra HTTPS, log, backup và rollback trước khi đưa production thật lên. Đừng đưa production lên trước khi bạn đã thử khôi phục từ backup ít nhất một lần. Để đối chiếu hai phía còn lại, xem triển khai Astro lên Cloudflare Pages cho phía managed và tự host Stoat bằng Docker Compose cho phía Compose thuần — Coolify là lựa chọn ở giữa, chỉ nên chọn khi bạn hiểu rõ mình đang đổi cái gì lấy cái gì.

Tham khảo


Bài viết liên quan

  • 10 phút đọc—

    AiSOC tự host: SOC AI mã nguồn mở cho blue team

    Hướng dẫn tự host AiSOC bằng Docker: gom cảnh báo từ EDR, cloud và identity về hàng đợi incident, triage bằng AI và chỉ hành động sau khi con người phê duyệt.

Bình luận

Bình luận được duyệt trước khi hiển thị.

Đang tải bình luận…

Để lại bình luận