- Bài viết này là một checklist ghi chép chi tiết từng bước quy trình tự host VPS bằng Hetzner và Coolify
- Hetzner được khuyến nghị nhờ độ trễ thấp tại châu Âu, hiệu năng trên giá thành vượt trội và mô hình giá minh bạch
- Bao gồm các vấn đề thường gặp trong thực tế như thiết lập máy chủ ban đầu, bảo mật SSH, tường lửa, cách cấu hình cập nhật tự động theo hướng bảo mật
- Hướng dẫn chi tiết cách thiết lập môi trường production, giám sát, sao lưu và xử lý sự cố để triển khai ứng dụng Node.js an toàn
- Đây là tài liệu thực tiễn giúp tự xây dựng máy chủ để rèn luyện năng lực DevOps và khả năng quản trị linh hoạt
Checklist chuẩn bị thiết lập VPS
- Ở mục chọn nhà cung cấp dịch vụ VPS, Hetzner được nhắc đến như lựa chọn khuyến nghị về giá/hiệu năng
- Cần chọn cấu hình tối thiểu 1GB RAM, 20GB lưu trữ, đồng thời ghi lại địa chỉ IP và thông tin tài khoản root của máy chủ
- Chuẩn bị SSH client trên máy cục bộ, đồng thời sử dụng trình tạo mật khẩu mạnh
Lý do chọn nhà cung cấp VPS
- Hetzner Cloud rẻ, nhanh và đáng tin cậy tại khu vực châu Âu
- Các lựa chọn thay thế: DigitalOcean (onboarding/tài liệu tốt, nhưng giá tăng), AWS Lightsail (bị ràng buộc vào AWS, khó hơn với người mới), Linode (ổn định nhưng kém cạnh tranh về giá), Render/Fly.io (thuận tiện nhờ là PaaS nhưng chi phí cao và nhiều giới hạn)
- Hetzner rẻ hơn 2~3 lần so với cùng cấu hình, không có phí tính mập mờ, và có lợi thế với trung tâm dữ liệu tại châu Âu
Checklist thiết lập máy chủ ban đầu
Kết nối lần đầu và cập nhật hệ thống
- Cập nhật danh sách gói và nâng cấp hệ thống
- Cung cấp các lệnh kiểm tra thông tin hệ thống (ví dụ: uname -a, cat /etc/os-release)
Cấu hình bảo mật tài khoản root
- Cần đặt mật khẩu phức tạp và lưu trữ an toàn
- Tạo tài khoản người dùng riêng thay vì dùng các tên tài khoản quen thuộc như 'admin', 'user'
- Cấp quyền sudo cho tài khoản mới và kiểm tra xem đã áp dụng đúng chưa
Cấu hình xác thực bằng SSH key
- Trên máy cục bộ, tạo cặp khóa Ed25519 (khuyến nghị) hoặc RSA
- Thêm public key vào
.ssh/authorized_keys trên máy chủ rồi thiết lập quyền phù hợp
- Kiểm tra đăng nhập bằng SSH key hoạt động bình thường (có vào được mà không cần nhập mật khẩu hay không)
- Tắt xác thực bằng mật khẩu, và nếu cần thì kiểm tra thêm file riêng của cloud-init
- Khởi động lại SSH daemon và xác nhận trạng thái hoạt động bình thường
- Xác nhận vô hiệu hóa đăng nhập root để chặn truy cập root từ xa
Checklist cấu hình tường lửa (Firewall)
Thiết lập UFW cơ bản
- Mặc định từ chối toàn bộ kết nối đến, cho phép kết nối đi
- Cho phép các cổng SSH, HTTP(80), HTTPS(443) và kiểm tra UFW đã được áp dụng chưa
- Tùy chọn: giới hạn cổng SSH theo IP cụ thể, đổi số cổng (nhằm tăng cường bảo mật) để thêm một lớp phòng vệ
Checklist cấu hình cập nhật tự động
Cấu hình Unattended Upgrades
- Cài các gói unattended-upgrades, apt-listchanges và chọn đồng ý dùng mặc định
- Có thể bỏ chú thích mục cập nhật bảo mật và cấu hình thông báo qua email, tùy chọn tự khởi động lại
- Kiểm tra thử hoạt động cập nhật tự động và xác minh trạng thái
Checklist triển khai ứng dụng production
Cấu hình môi trường vận hành Node.js
- Cài Node.js LTS và kiểm tra phiên bản
- Tải file ứng dụng lên máy chủ rồi cài dependency để sẵn sàng cho môi trường production
Sử dụng trình quản lý tiến trình (PM2)
- Chạy ứng dụng bằng PM2 ở chế độ production, dùng tùy chọn clustering
- Thiết lập tự khởi động khi boot bằng PM2, đồng thời cung cấp các lệnh khởi động lại/giám sát
Cấu hình Reverse Proxy (Nginx)
- Tạo file cấu hình site cho Nginx và áp dụng proxy pass
- Kích hoạt site và khởi động lại Nginx
Checklist cấu hình chứng chỉ SSL
Let's Encrypt và Certbot
- Sau khi cài certbot, python3-certbot-nginx, tự động cấp chứng chỉ SSL theo domain
- Tùy chọn tự động gia hạn và kiểm tra hiệu lực chứng chỉ
Checklist giám sát và bảo trì
Cách giám sát cơ bản
- Cài các công cụ kiểm tra tài nguyên hệ thống như htop, iotop
- Giám sát log thời gian thực của syslog, auth.log và thiết lập chính sách xoay vòng log (logrotate)
Chiến lược sao lưu
- Viết script sao lưu ứng dụng và cơ sở dữ liệu bằng tar
- Thực hiện sao lưu định kỳ theo lịch (crontab)
Checklist xử lý sự cố
Vấn đề kết nối SSH
- Kiểm tra cấu hình tường lửa, trạng thái dịch vụ SSH, log xác thực và mạng
Lỗi liên quan đến quyền
- Kiểm tra quyền file/thư mục, group và cấu hình sudo
Dịch vụ không khởi chạy
- Dùng systemctl, journalctl để kiểm tra trạng thái và log, đồng thời kiểm tra cú pháp file cấu hình
Sử dụng tài nguyên quá mức
- Phân tích log của tiến trình/đĩa/mạng/ứng dụng
Checklist xác minh cuối cùng
Xác minh bảo mật
- Rà soát xem toàn bộ các mục như xác thực SSH key/đăng nhập bằng mật khẩu/đăng nhập root/tường lửa/cập nhật tự động/chế độ production/SSL/sao lưu... có hoạt động đúng không
Kiểm tra hiệu năng
- Dùng Apache Bench để kiểm thử tải và giám sát tài nguyên, đồng thời kiểm tra lỗi trong log
Danh sách lệnh tham khảo nhanh
Kiểm tra thông tin hệ thống
- htop, df -h, free -h, uname -a
Quản lý tiến trình
- pm2 status, pm2 restart all, pm2 logs, pm2 monit
Liên quan đến bảo mật
- sudo ufw status, sudo fail2ban-client status, sudo lynis audit system
Quản lý dịch vụ
- sudo systemctl status nginx, sudo systemctl restart nginx, sudo journalctl -u nginx
Kết luận
- Checklist này cung cấp quy trình thiết lập và quản lý VPS hoàn chỉnh
- Không chỉ có chi phí thấp mà còn mang lại khả năng tự quản lý, học hỏi và sự tự chủ DevOps
- Self-hosting với Hetzner và Coolify cho phép trải nghiệm độ tin cậy và sự tự do thông qua kinh nghiệm thực chiến
- Đây là nội dung có thể đóng vai trò hướng dẫn thực tiễn cho những ai muốn thử sức với VPS hosting
1 bình luận
Ý kiến trên Hacker News
Tôi nghĩ đây là một bản tóm tắt rất hay cho người mới như tôi, chắc chắn sẽ bookmark lại.
Tuy nhiên điểm đáng tiếc là tiêu đề có nhắc đến Coolify nhưng trong nội dung thì gần như không nói đến.
Một bài hữu ích khác về chủ đề tương tự là 'Setting up a Production-Ready VPS from Scratch', tôi cũng đã bookmark ở link bên dưới.
https://dreamsofcode.io/blog/setting-up-a-production-ready-vps-from-scratch
Khi muốn hiểu sâu hơn về những chủ đề kiểu này, tôi thường đưa link bài viết vào LLM rồi
"Đây là một bài viết về 'chủ đề/tiêu đề': https://article.link. Hãy nắm thật rõ và phân tích nó, sau đó mở rộng từng phần bằng kiến thức của bạn, đồng thời thêm cả các phần liên quan khác"
rồi dùng prompt như vậy để học.
https://www.youtube.com/watch?v=taJlPG82Ucw
Tôi đã vận hành với cấu hình này khoảng 1 năm, và đây là lần đầu tiên tôi cảm thấy tự tin về self-hosting.
OVH cũng đáng tin cậy như Hetzner, mà hiện giờ còn có các gói rẻ hơn khá nhiều.
https://us.ovhcloud.com/vps/configurator/?planCode=vps-2025-model3&brick=VPS%2BModel%2B3&pricing=upfront12&processor=%20&vcore=8__vCore&storage=200__SSD__NVMe
Nếu dùng Coolify thì tôi đang phân vân nên chọn distro nào.
Tôi đang cân nhắc giữa Ubuntu 24.04 và Debian 13, không biết cái nào là lựa chọn tốt hơn.
OVH VPS - 24 vCPU (hoặc thread), 96GB RAM có giá $53.4/tháng.
Hetzner VPS (theo tùy chọn AMD) là 16vCPU, 32GB, $54.9/tháng.
DO Droplet là 16vCPU, 64GB RAM với giá $504/tháng.
Linode và Upcloud cũng ở mức 24~20vCPU, 96GB RAM nhưng giá $576/tháng, đắt hơn OVH rất nhiều.
Tôi không biết OVH dùng CPU gì, nhưng xét chênh lệch giá thì ngay cả nếu đó là CPU Intel E-Core cũng vẫn là một mức khá ổn.
Tham khảo thêm thì Hetzner cũng có tùy chọn Intel vCPU rẻ hơn, nhưng là phần cứng cũ và chỉ mở slot khi khách khác hủy.
Vì vậy tôi chỉ đem tùy chọn AMD mới nhất ra so sánh.
Vấn đề duy nhất của OVH là để thuê VPS (khoảng $30/tháng), tôi buộc phải gửi bản sao giấy tờ tùy thân.
Tôi không muốn phát tán dữ liệu cá nhân của mình theo cách đó, nên cuối cùng đã chọn chỗ đắt hơn.
Theo trải nghiệm của tôi (dù không quá dài), cloud server của Hetzner cho hiệu năng tốt hơn hẳn so với OVH VPS.
Tôi vẫn hài lòng khi dùng cả hai.
Tôi thắc mắc vì sao OVH và Hetzner lại rẻ hơn các nhà cung cấp khác nhiều đến vậy.
Với VPS thì còn có thể hiểu phần nào vì tài nguyên được chia sẻ nhiều hơn nơi khác, nhưng hai bên này cả dedicated server cũng rất rẻ.
Tôi còn tự hỏi liệu có phải kiểu honeypot nào không, hoặc giá OVH gần đây mới thay đổi.
Tôi nhớ là vài năm trước nó còn đắt hơn Hetzner.
Tất cả các CPU được nhắc đến ở đây thực chất rất có thể đều là tài nguyên dùng chung.
Và họ cũng không công khai mức độ chia sẻ thực tế.
Hetzner có những server cùng số core nhưng giá chỉ bằng một nửa.
Bề ngoài không thể hiện ra, nhưng nếu tự benchmark thì thấy server rẻ hơn thực tế chỉ cho khoảng một nửa hiệu năng.
Trong phần cấu hình CSS, chỉ cần tắt hai dòng dưới đây là UI/UX của blog cải thiện rất nhiều.
pre {
margin: 2rem 0 !important;
padding: 1rem !important;
}
Padding và margin của code block quá lớn nên trên màn hình chỉ thấy được 3 dòng.
Ngoài ra, nếu cài Webmin/Virtualmin thì những việc như thêm subdomain mới hoặc thêm user sẽ tiện hơn nhiều.
Tôi bấm vào vì tò mò về Coolify, nhưng thực tế nó chỉ được nhắc ở tag, phần mở đầu và kết bài, còn thân bài thì không có gì.
Tôi thấy việc đưa Coolify vào đây là không phù hợp.
Thực chất bài này là về cách chuẩn bị VPS để triển khai Coolify.
Nó không hề nói về việc cài đặt Coolify.
Từ trước đến nay tôi quản lý mọi service bằng Docker Compose trên VM, nên đã bấm vào vì muốn biết liệu Coolify có phải là giải pháp thay thế tốt hơn đáng kể không.
Nhưng rốt cuộc chẳng có nội dung thực tế nào về Coolify, và các bước thủ công để chuẩn bị cho Coolify lại còn trông phức tạp hơn.
Cách của tôi, kiểu “dùng base image Docker Compose rồi chỉnh vài thứ”, có vẻ đơn giản hơn nhiều,
nên tôi thấy phương pháp mình đang dùng vẫn hoàn toàn ổn.
Điểm hay là khi chuyển giữa các host, chỉ cần copy file Docker Compose YAML là giải quyết được 99%.
Tôi đã thử Coolify vài tháng trước, và gặp đủ loại vấn đề khi nhiều container được nối với nhau bằng Compose.
Ví dụ có lúc tôi quên rằng một container đã chạy rồi nên lại khởi chạy trùng, hoặc cả hai cùng chạy nhưng Coolify chỉ nhận ra một cái.
Nếu đăng ký từng service riêng lẻ vào Coolify thì còn tạm ổn.
Cuối cùng tôi cũng quay lại với cấu hình standalone dựa trên Docker Compose, và hóa ra còn dễ vận hành hơn nhiều.
Tôi nghĩ những nỗ lực như Coolify thực sự rất cần thiết, nhưng hiện tại vẫn chưa đủ chín để dùng cho production nghiêm túc.
Nếu Coolify hay các dự án tương tự không hỗ trợ backup DB và streaming replication, thì chúng sẽ chỉ dừng ở mức hobby thôi.
Tôi đang vận hành 2 VM bằng Docker Compose và bash script, chỉ cần thiết lập backup hàng giờ lên S3, wal streaming, streaming replication cho PG và Redis là đã đáp ứng được mức tối thiểu cho production thực tế theo tôi nghĩ.
Tùy mục đích sử dụng, nhưng tôi đã dùng cả Coolify lẫn CapRover.
Cuối cùng tôi chọn CapRover vì với Git Hook, app NodeJS có thể được tự động build mỗi khi commit nên lên nhanh hơn.
Cả hai đều hỗ trợ tính năng này, nhưng CapRover ít ma sát hơn.
Coolify thì nhiều tính năng hơn.
Coolify chạy trên Traefik và Docker, thực chất là một lớp UI phủ lên trên.
Nó thiếu khá nhiều tính năng thiết yếu liên quan đến backup (dù có thể xử lý bằng restic chẳng hạn), và UX cũng chỉ ở mức dùng được.
Coolify hiện vẫn cần quyền root khi cài đặt.
Tôi nghe nói họ đang phát triển một nhánh cho phép cài không cần quyền root.
Bạn có thể SSH vào server để cài Coolify rồi sau đó tắt đăng nhập root đi.
Nếu chấp nhận khả năng làm hỏng server và phải setup lại từ đầu thì có thể làm như vậy.
Gần đây tôi cũng thử triển khai Coolify hoàn toàn từ đầu, nhưng liên tục lỗi ở SSH key.
Tôi đang triển khai tốt nhiều project trên các server khác, nhưng cách tiếp cận kiểu “chỉ cần đưa file docker compose” thì trên thực tế chưa lần nào chạy ngon với tôi.
Gần đây tôi đã chuyển một server FreeBSD sang Hetzner, và việc đó rất dễ.
Biến số duy nhất là các port dành cho mail server bị chặn cho tới khi chu kỳ thanh toán kết thúc hoàn toàn.
Tôi hiểu chính sách này, nhưng lúc bắt đầu lại không được thông báo rõ ràng nên khá bối rối.
Nhân tiện, nếu thẻ tín dụng hết hạn thì Hetzner có thể cắt hẳn network ngay lập tức.
Không có cảnh báo trước, và tôi chỉ biết khi có người dùng thực hoặc nhân viên liên hệ.
Tôi đã thực sự gặp chuyện này.
Nếu bạn liên hệ đội Hetzner và giải thích loại traffic của mình, họ đôi khi sẽ mở port trước.
Tôi đã cho họ xem bằng chứng về project sắp migrate và họ mở ngay.
Các công cụ như Coolify (hay Dokploy) cũng trông khá ổn, nhưng tôi luôn thấy tiếc vì trạng thái server không được lưu dưới dạng code.
Vì thế tôi thích NixOS hoặc Ansible hơn, nhưng để dựng production thực tế thì lại cần quá nhiều boilerplate và tùy biến.
Tôi đang tự hỏi có ai biết framework infrastructure-as-code nào không phải Kubernetes mà vẫn mang tính khai báo hơn và giúp quản lý server production dễ dàng không.
Gần như không có gì phải backup ngoài cấu hình Coolify, và cấu hình ứng dụng đều nằm trong /data/coolify.
Tôi backup toàn bộ volume bằng kopia.
Đây không phải cách đẹp đẽ gì, hơi kiểu workaround, nhưng vẫn là phương án dùng được cho disaster recovery.
Đây là một hướng dẫn hay.
Nhưng tôi không đồng ý với cách cấu hình firewall, nhất là khi dùng Hetzner.
Nếu chỉ cần thiết lập đơn giản thì firewall do Hetzner cung cấp là quá đủ, mà còn có hiệu ứng “outsourcing” nữa.
Nếu muốn tùy biến hơn thì cũng có thể cấu hình qua API.
https://docs.hetzner.cloud/reference/cloud#firewalls
Tôi muốn biết liệu firewall của Hetzner có nhược điểm nghiêm trọng nào không.
Tôi thấy lời khuyên "chỉ cho phép SSH từ IP của bạn (tùy chọn nhưng được khuyến nghị)" là khá nguy hiểm.
Nếu IP thay đổi thì bạn có thể tự khóa quyền truy cập của chính mình.
Có thể reset qua dashboard của Hetzner, nhưng thay vì buộc vào IP mạng nhà cứ thay đổi liên tục, dùng Tailscale hoặc
một IP VPN bên ngoài cố định sẽ tốt hơn.
Chỉ cần dùng xác thực bằng SSH key cũng đã ngăn được gần như hầu hết vấn đề bảo mật rồi.
Có thể thêm một lớp để giảm log noise nữa, và nếu có service nào ngoài SSH không cần public ra ngoài
thì tôi nghĩ nên chặn lại bằng VPN hoặc cách tương tự.
Thực ra trên server, đa số service còn dễ tổn thương hơn SSH.
Đúng là khá nguy hiểm.
Nhiều người ở nhà dùng IP động.
Chỉ cần cấu hình SSH key và chặn đăng nhập root là tôi thấy đã đủ an toàn rồi.
Tôi nghĩ phần thiết lập app production nên được thay bằng Docker.
Giờ Docker lặp lại được hơn nhiều và cấu hình cũng dễ hơn.