Tự host không khó, khó là chọn đúng ngay từ đầu
Rất nhiều người bắt đầu self-hosted app với tâm thế “cứ dựng lên đã”, rồi sau vài tuần mới phát hiện: VPS thiếu RAM, domain đặt tên rối, reverse proxy cấu hình chắp vá, SSL lỗi lúc được lúc không. Kết quả là hệ thống vẫn chạy, nhưng khó mở rộng, khó bảo trì, và dễ phát sinh downtime đúng lúc cần dùng nhất.
Nếu bạn đang muốn triển khai các ứng dụng self-hosted như Nextcloud, n8n, Vaultwarden, Gitea, Ghost, Uptime Kuma hay các dashboard nội bộ, thì ba quyết định quan trọng nhất ngay từ đầu là: chọn VPS, chọn domain, và chọn reverse proxy. Đây là “xương sống” của toàn bộ hệ thống. Chọn đúng, bạn tiết kiệm rất nhiều thời gian về sau. Chọn sai, bạn sẽ phải migrate, đổi cấu hình, thậm chí dựng lại từ đầu.
Bài viết này sẽ đi thẳng vào cách ra quyết định thực tế, phù hợp cho cả người mới bắt đầu lẫn người đã có vài dịch vụ đang chạy.
Vì sao 3 lựa chọn này quan trọng hơn bạn nghĩ?
Nhiều người tập trung vào app trước, nhưng app chỉ là phần nổi. Phần hạ tầng bên dưới mới quyết định trải nghiệm vận hành lâu dài:
– VPS quyết định hiệu năng, độ ổn định, chi phí và khả năng mở rộng.
– Domain quyết định cách bạn tổ chức dịch vụ, SSL, email, DNS và tính chuyên nghiệp.
– Reverse proxy là cổng vào chung: xử lý HTTPS, định tuyến subdomain, bảo mật cơ bản và che giấu kiến trúc phía sau.
Nếu coi self-hosting là xây nhà, thì VPS là nền móng, domain là địa chỉ, còn reverse proxy là cửa chính có khóa.
Cách chọn VPS: đừng mua theo cảm tính
Chọn theo loại ứng dụng, không chỉ theo giá
Không phải self-hosted app nào cũng cần cấu hình giống nhau. Một số ứng dụng nhẹ, chỉ vài trăm MB RAM. Một số khác ngốn tài nguyên vì có database, indexing, xử lý file, hoặc background jobs.
Bạn có thể chia nhu cầu thành 3 nhóm:
– Nhóm nhẹ: Uptime Kuma, Vaultwarden, Tiny Tiny RSS, homepage dashboard, các API nội bộ nhỏ.
– Nhóm trung bình: Gitea, Ghost, Umami, Plausible, n8n, app có PostgreSQL/MySQL riêng.
– Nhóm nặng: Nextcloud, Mastodon, GitLab, app có search engine, object storage, xử lý media.
Với người mới, một mốc tham khảo khá an toàn là:
– 1 vCPU / 1 GB RAM: chỉ phù hợp thử nghiệm hoặc dịch vụ rất nhẹ.
– 2 vCPU / 2-4 GB RAM: mức khởi đầu tốt cho nhiều app self-hosted phổ biến.
– 4 vCPU / 8 GB RAM trở lên: khi chạy nhiều container, database nặng, hoặc có người dùng thật.
Ưu tiên RAM trước CPU trong nhiều tình huống
Đa số self-hosted app nhỏ không “ăn” CPU liên tục, nhưng lại dễ gặp vấn đề khi thiếu RAM: swap nhiều, database chậm, container restart thất thường. Vì vậy, nếu phải chọn giữa thêm 1 vCPU và thêm RAM, thì với nhiều workload phổ biến, thêm RAM thường đáng giá hơn.
SSD, băng thông và I/O quan trọng hơn bạn tưởng
Đừng chỉ nhìn mỗi vCPU/RAM. Hãy kiểm tra:
– Loại ổ đĩa: ưu tiên SSD hoặc NVMe.
– Dung lượng thực tế: đủ cho app, database, logs, backup tạm.
– Hiệu năng I/O: rất quan trọng với database và ứng dụng lưu nhiều file.
– Băng thông/throttling: nếu có upload file, media, hoặc nhiều request, giới hạn băng thông sẽ lộ rất nhanh.
Ví dụ, Nextcloud chạy được trên VPS không quá mạnh, nhưng nếu ổ đĩa chậm thì trải nghiệm đồng bộ file sẽ rất tệ.
Chọn nhà cung cấp: ổn định và minh bạch quan trọng hơn “rẻ nhất”
Khi đánh giá nhà cung cấp VPS, hãy để ý:
– Uptime và độ ổn định mạng.
– Chính sách backup/snapshot.
– Datacenter gần người dùng chính.
– Hỗ trợ IPv4, IPv6.
– Giao diện quản trị có dễ reboot, rescue, snapshot không.
– Chi phí tăng thêm cho backup, IP, traffic.
Một VPS rẻ nhưng mạng chập chờn hoặc I/O yếu thường khiến bạn trả giá bằng thời gian xử lý sự cố.
Đừng gom mọi thứ vào một VPS quá sớm
Khi mới bắt đầu, chạy nhiều app trên một VPS là hợp lý để tiết kiệm. Nhưng nếu một dịch vụ quan trọng hơn phần còn lại, hãy cân nhắc tách dần:
– App public và app nội bộ không nhất thiết nằm chung.
– Database quan trọng có thể cần môi trường riêng.
– Các app thử nghiệm không nên làm ảnh hưởng dịch vụ production.
Nguyên tắc thực tế: bắt đầu gọn, nhưng giữ đường nâng cấp rõ ràng.
Cách chọn domain: đặt tên thông minh để đỡ đau đầu về sau
Mua domain dễ nhớ, dễ gõ, dễ mở rộng
Một domain tốt cho self-hosting không cần quá “đẹp”, nhưng nên:
– Ngắn, dễ nhập, ít nhầm lẫn.
– Tránh dấu gạch ngang nếu không cần.
– Tránh tên quá dài hoặc quá giống thương hiệu khác.
– Dễ mở rộng thành nhiều subdomain.
Ví dụ, nếu bạn có domain example.com, bạn có thể tổ chức:
– cloud.example.com cho Nextcloud
– git.example.com cho Gitea
– status.example.com cho Uptime Kuma
– auth.example.com cho hệ thống xác thực
Cách này rõ ràng hơn nhiều so với nhồi tất cả vào path kiểu example.com/nextcloud, example.com/git.
Ưu tiên subdomain hơn subpath
Về mặt kỹ thuật, nhiều app hoạt động tốt hơn khi chạy trên subdomain riêng thay vì subpath. Lý do:
– Dễ cấu hình reverse proxy.
– Ít xung đột route, cookie, redirect.
– SSL và bảo mật tách biệt rõ hơn.
– Dễ di chuyển app sang server khác sau này.
Subpath chỉ nên dùng khi bạn hiểu rõ app đó hỗ trợ tốt và bạn thực sự cần gom chung một domain gốc.
Chọn nhà đăng ký domain có quản lý DNS tốt
Domain không chỉ là tên miền; phần quan trọng là DNS management. Hãy ưu tiên nhà đăng ký hoặc nhà cung cấp DNS có:
– Giao diện DNS rõ ràng.
– Hỗ trợ record đầy đủ: A, AAAA, CNAME, TXT, MX.
– TTL linh hoạt.
– DNSSEC nếu cần.
– API quản lý DNS nếu bạn muốn tự động hóa.
Nếu sau này bạn dùng wildcard certificate, dynamic DNS, hoặc tự động cập nhật IP, API DNS sẽ rất hữu ích.
Tách domain public và domain nội bộ nếu cần
Nếu bạn vừa có dịch vụ public, vừa có dịch vụ chỉ dùng trong mạng riêng, bạn có thể cân nhắc:
– Một domain chính cho public app.
– Một subdomain hoặc domain phụ cho nội bộ/VPN-only.
– Thậm chí dùng local DNS riêng cho dịch vụ chỉ truy cập trong LAN hoặc Tailscale/ZeroTier.
Điều này giúp tránh vô tình expose dịch vụ nội bộ ra Internet.
Cách chọn reverse proxy: lớp điều phối không thể làm qua loa
Reverse proxy là gì, và vì sao gần như luôn cần?
Reverse proxy đứng trước các ứng dụng backend. Nó nhận request từ người dùng, xử lý HTTPS, rồi chuyển tiếp đến container hoặc service nội bộ. Nhờ đó bạn có thể:
– Dùng một IP cho nhiều ứng dụng.
– Tự động cấp SSL/TLS.
– Ẩn port nội bộ.
– Áp chính sách bảo mật chung.
– Log và kiểm soát traffic tập trung.
Nếu bạn self-host từ 2 app trở lên, gần như chắc chắn bạn nên dùng reverse proxy.
Ba lựa chọn phổ biến: Nginx, Caddy, Traefik
Nginx: mạnh, phổ biến, nhiều tài liệu
Nginx là lựa chọn lâu năm, cực kỳ phổ biến. Ưu điểm:
– Tài liệu và ví dụ rất nhiều.
– Linh hoạt, mạnh mẽ.
– Phù hợp khi bạn muốn kiểm soát chi tiết.
Nhược điểm:
– Cấu hình có thể dài và dễ sai với người mới.
– SSL tự động thường cần thêm công cụ như Certbot.
Nginx hợp với người muốn hiểu sâu và chấp nhận đầu tư thời gian cấu hình.
Caddy: dễ dùng, rất hợp self-hosting cá nhân
Caddy nổi bật vì cấu hình đơn giản và hỗ trợ HTTPS tự động rất tốt. Với nhiều người tự host 3-10 dịch vụ, Caddy là lựa chọn “ít đau đầu” nhất.
Ưu điểm:
– Cấu hình ngắn, dễ đọc.
– Tự động lấy và gia hạn SSL.
– Hợp với người mới hoặc hệ thống nhỏ-trung bình.
Nhược điểm:
– Ít phổ biến hơn Nginx trong một số môi trường doanh nghiệp.
– Một số cấu hình nâng cao có thể ít tài liệu hơn.
Nếu mục tiêu của bạn là triển khai nhanh, ổn định, dễ bảo trì, Caddy rất đáng cân nhắc.
Traefik: rất hợp Docker và môi trường động
Traefik đặc biệt mạnh khi bạn chạy nhiều container Docker và muốn reverse proxy tự nhận diện service qua label.
Ưu điểm:
– Tích hợp tốt với Docker.
– Tự động route theo container metadata.
– Hợp với môi trường nhiều service thay đổi thường xuyên.
Nhược điểm:
– Khái niệm và cấu hình ban đầu có thể khó hơn Caddy.
– Nếu hệ thống nhỏ, đôi khi hơi “quá tay”.
Traefik phù hợp khi bạn đã quen Docker Compose hoặc đang hướng tới hạ tầng tự động hóa hơn.
Chọn công cụ nào cho trường hợp nào?
Một cách chọn thực tế:
– Muốn dễ, nhanh, ít lỗi SSL: chọn Caddy
– Muốn phổ biến, kiểm soát sâu: chọn Nginx
– Muốn tự động hóa theo Docker/service discovery: chọn Traefik
Không có công cụ “tốt nhất tuyệt đối”, chỉ có công cụ phù hợp nhất với cách bạn vận hành.
Đừng quên các tính năng bảo mật cơ bản
Dù dùng reverse proxy nào, hãy ưu tiên:
– HTTPS bắt buộc.
– Redirect HTTP sang HTTPS.
– Giới hạn expose chỉ những app cần public.
– Bật header bảo mật cơ bản nếu phù hợp.
– Cân nhắc basic auth hoặc SSO cho dashboard quản trị.
– Rate limiting cho các endpoint nhạy cảm.
– Log tập trung để theo dõi bất thường.
Reverse proxy không chỉ để “map domain vào port”, mà còn là tuyến phòng thủ đầu tiên.
Một cấu hình tư duy đơn giản cho người mới
Nếu bạn chưa biết bắt đầu từ đâu, đây là phương án cân bằng:
– VPS 2 vCPU, 4 GB RAM, SSD tốt.
– Một domain chính, dùng subdomain cho từng app.
– Docker Compose để quản lý service.
– Caddy hoặc Nginx làm reverse proxy.
– Backup database và volume định kỳ.
– Chỉ public những gì thực sự cần truy cập từ Internet.
Mô hình này đủ tốt cho phần lớn nhu cầu cá nhân, freelancer, nhóm nhỏ hoặc side project.
Kết luận: chọn để dễ vận hành, không chỉ để “chạy được”
Khi triển khai self-hosted app, sai lầm phổ biến nhất là chỉ tập trung vào việc dựng app lên cho chạy. Nhưng vận hành lâu dài mới là bài toán thật. Một VPS phù hợp giúp hệ thống ổn định. Một domain được tổ chức tốt giúp bạn mở rộng gọn gàng. Một reverse proxy đúng nhu cầu giúp HTTPS, routing và bảo mật trở nên đơn giản hơn rất nhiều.
Nếu phải nhớ một nguyên tắc duy nhất, hãy nhớ điều này: đừng chọn theo cảm hứng, hãy chọn theo cách bạn sẽ vận hành hệ thống sau 3 đến 6 tháng.
Một stack “vừa đủ nhưng sạch” gần như luôn tốt hơn một stack phức tạp mà chính bạn cũng ngại chạm vào. Self-hosting bền vững không nằm ở việc bạn dùng công nghệ gì cho oách, mà nằm ở việc hệ thống có dễ hiểu, dễ sửa, dễ backup và dễ mở rộng hay không.