Từ lâu tôi đã muốn tự vận hành một máy chủ riêng, nhưng lại e ngại chi phí và độ phức tạp. Rồi tôi tình cờ biết đến Proxmox VE — và giờ nhìn lại, tôi tự hỏi tại sao mình không làm sớm hơn. Proxmox là một nền tảng ảo hóa miễn phí, mã nguồn mở, dựa trên Debian: KVM cho máy ảo đầy đủ, LXC cho container gọn nhẹ và một giao diện web thực sự giúp công việc hằng ngày dễ dàng hơn.
Điều tuyệt vời là bạn không cần một máy chủ đắt tiền. Khởi đầu của tôi là một chiếc mini PC đã qua sử dụng (Dell OptiPlex Micro) được nâng cấp RAM và gắn SSD NVMe — chạy êm, tiết kiệm điện và hoàn toàn đủ cho 10–15 container cùng vài máy ảo. Với giá điện ở đây, một chiếc mini PC tiêu thụ 10–15 watt khi rảnh tạo ra khác biệt rất lớn so với máy chủ rack.
Sau khi cài đặt, việc đầu tiên tôi làm là tắt kho Enterprise và thiết lập các kho Community, bảo mật đăng nhập SSH bằng khóa và cài Fail2ban. Sau đó là những dịch vụ đầu tiên: Pi-hole để chặn quảng cáo cho toàn mạng, Nginx Proxy Manager và Portainer. Thứ tự này đã chứng minh là hiệu quả — hãy bắt đầu từ nhỏ, đừng dựng ngay hai mươi container cùng lúc.
Lời khuyên quan trọng nhất của tôi, điều mà chính tôi đã phải học một cách đau đớn: Hãy thiết lập sao lưu trước khi cài dịch vụ đầu tiên. Theo quy tắc 3-2-1, và tính năng sao lưu snapshot tích hợp sẵn của Proxmox khiến việc này gần như quá dễ dàng. Nhân tiện, RAID không phải là sao lưu — điều này tôi cũng phải mãi sau mới hiểu ra.
Cứ bắt đầu thôi. Một container, một dịch vụ, và bạn sẽ học được về hạ tầng nhiều hơn bất kỳ khóa học trực tuyến nào. Còn ai chỉ muốn thử trước, cũng có thể dùng một máy chủ cloud giá rẻ để học.
Nguồn: Homelab Guide
Theo IT之家, NAS bốn khay QNAP Qu405-N150-8G hiện đã được bán trên JD.com. Máy có 8 GB RAM và được bảo hành tiêu chuẩn hai năm. Riêng thiết bị có giá 2599 nhân dân tệ, còn gói kèm ổ cứng Seagate IronWolf 4 TB có giá 3599 nhân dân tệ.
Thiết kế đơn giản. Khung máy có kích thước 165 mm x 168 mm x 217 mm và nặng 2,15 kg. Bộ xử lý là Intel N150 với 4 nhân và 4 luồng. Theo nhà sản xuất, máy có thể chuyển mã video 4K và chạy máy ảo cùng container Docker, đây là điểm thu hút lớn với người thích tự làm máy chủ tại nhà. RAM SODIMM DDR4 8 GB xuất xưởng có thể nâng cấp lên 16 GB.
Ở phần lưu trữ, máy có bốn khay cho ổ SATA 3,5 hoặc 2,5 inch. Bên trong còn có hai khe M.2 2280 NVMe chuẩn PCIe Gen 3 x1, có thể dùng làm bộ nhớ đệm hoặc lưu dữ liệu hệ thống và container. Các cổng kết nối gồm hai cổng mạng 2.5GbE, hai USB-A 3.2 Gen 2, một USB-C 3.2 Gen 2 và một HDMI 2.1.
Theo tôi, việc kết hợp hai cổng 2.5G với N150 đã trở thành cấu hình phổ biến của NAS gia đình phân khúc đầu vào trong hai năm qua. Máy chạy được Docker mà không tiêu tốn nhiều điện, và giá khá hợp lý. Tuy nhiên, bài viết chỉ nêu thông số kỹ thuật chứ không có thử nghiệm thực tế, nên nếu đang cân nhắc mua, bạn nên xem thêm đánh giá độc lập về độ ồn, mức tiêu thụ điện và trải nghiệm phần mềm.
Nguồn: IT之家
Synology đã công bố dòng neo+ mới dành cho thị trường Đức, gồm DS725neo+, DS925neo+, DS1525neo+ và DS1825neo+. ComputerBase mô tả đây là các phiên bản rẻ hơn của dòng Plus, chỉ khác ở cấu hình bộ nhớ.
Theo bài báo, chữ "neo" có nghĩa là "tùy chọn Non-ECC". Các thiết bị này dùng bộ nhớ thông thường không có ECC, và luôn chỉ có 4 GB. DS725+ và DS925+ có 4 GB RAM ECC, còn DS1525+ và DS1825+ có 8 GB RAM ECC, nên các phiên bản neo+ có bộ nhớ ít hơn. Ngoài ra, trang bị, tính năng và khả năng mở rộng đều giống dòng Plus, và DSM cùng các ứng dụng cũng hoàn toàn giống nhau.
Ở giá bán lẻ đề xuất, chênh lệch khoảng 200 euro: DS725neo+ có giá 549 euro chưa thuế, còn DS725+ là 748 euro chưa thuế. Tuy nhiên ngoài thị trường, khoảng cách không rõ rệt như vậy: DS725+ hiện có giá từ 663 euro, còn DS725neo+ từ 629 euro. Bộ nhớ sau này có thể nâng cấp lên RAM ECC một cách dễ dàng.
Synology viện dẫn tình hình hiện tại của thị trường bộ nhớ, tức là mức tăng giá đáng kể cũng đã ảnh hưởng đến dòng Plus.
Với máy chủ tại nhà, tôi thấy đây là một sự đánh đổi thú vị. Ai chủ yếu dùng NAS để sao lưu, lưu trữ media và vài container thì có lẽ 4 GB không ECC là đủ. Còn ai coi trọng tính toàn vẹn dữ liệu thì nên xem kỹ mình được gì với khoản chênh lệch đó.
Nguồn: ComputerBase
Hardware.com.br giới thiệu một homelab gây chú ý nhờ kích thước nhỏ gọn. Một người dùng Reddit đã đăng lên r/HomeServer một tủ rack 10 inch nhỏ, gồm tường lửa, ba mini PC, một NAS và toàn bộ hạ tầng mạng cần thiết để chạy hàng chục dịch vụ tại nhà.
Phần xử lý do ba mini PC đảm nhiệm, mỗi máy có bộ vi xử lý 8 nhân 16 luồng và 32 GB RAM, tổng cộng 24 nhân, 48 luồng và 96 GB dành cho ảo hóa. Chủ nhân dùng Proxmox để tạo máy ảo và container LXC. Các tác vụ đang chạy gồm một VM cho Jellyfin, bộ arr chạy trên Docker, một máy chủ Docker khác với Portainer, Pi-hole và các bảng điều khiển như Homer và Homepage, cùng các máy chủ game như Terraria và Core Keeper.
Lưu trữ nằm trong một HP ProLiant MicroServer với bốn ổ cứng 4 TB cấu hình ZFS RAIDZ1, nhờ đó vẫn truy cập được dữ liệu ngay cả khi một ổ bị hỏng. Dung lượng thô là 16 TB, nhưng dung lượng dùng được thấp hơn do phần parity. Mạng được quản lý bởi Fortinet FortiGate, đảm nhận định tuyến, VLAN và VPN SSL, còn bộ lưu điện APC Back-UPS 850 bảo vệ khỏi mất điện.
Theo tôi, phần thú vị nhất nằm ngoài nhà: chủ nhân có hai VPS chạy Debian ở các trung tâm dữ liệu bên ngoài, kết nối với homelab qua mạng WireGuard theo mô hình hub-and-spoke. Chúng đóng vai trò lớp công khai của hạ tầng, với Traefik làm reverse proxy.
Đây là ví dụ tốt cho thấy homelab không cần một tủ rack khổng lồ: với kế hoạch hợp lý, thiết bị nhỏ và cách sắp xếp gọn gàng, bạn vẫn có thể chạy rất nhiều thứ trên một không gian nhỏ.
Nguồn: Hardware.com.br
Khi một máy chủ chạy từ hai dự án trở lên, sớm muộn bạn cũng va vào cổng 80 và 443, vốn chỉ một tiến trình có thể lắng nghe. Một bài trên Habr từ blog Selectel hướng dẫn từng bước cách giải quyết điều này bằng Nginx Proxy Manager.
Tác giả giải thích trước vấn đề: các cổng đặc quyền, quy tắc một bộ lắng nghe cho mỗi cổng, lỗi CORS khi frontend và backend tách theo cổng, và việc thiếu HTTPS. Reverse proxy giải quyết bằng cách làm trung gian, định tuyến lưu lượng theo tên miền và đường dẫn. Một lợi ích khác là tường lửa chỉ cần mở cổng 22, 80 và 443.
Môi trường thử nghiệm là một VDS với 2 vCPU, 2 GB RAM và 40 GB NVMe, chạy Ubuntu 24.04 và Docker cài từ kho chính thức. Mạng được tạo bằng docker network create proxy, sau đó khởi chạy container jc21/nginx-proxy-manager với volume cho dữ liệu và chứng chỉ. Tôi thích việc trang quản trị ở cổng 81 chỉ gắn với 127.0.0.1 và truy cập qua đường hầm SSH.
Tiếp theo, cấu hình một proxy host: ô Forward Hostname điền tên container, còn chứng chỉ SSL được gắn ở tab SSL. Bài dùng traefik/whoami để kiểm thử. Trường hợp ứng dụng chạy trực tiếp trên máy chủ cũng được đề cập riêng: địa chỉ gateway của mạng Docker lấy bằng docker network inspect, và tường lửa được thiết lập để không thể truy cập ứng dụng bỏ qua proxy.
Cũng có một số điểm cần lưu ý. Các ví dụ trộn nhiều tên miền khác nhau, và image dùng thẻ latest nên khả năng tái lập có thể giảm theo thời gian. Dù vậy, đây là điểm khởi đầu tốt cho ai muốn chạy nhiều dịch vụ ở nhà hoặc trên VDS mà không phải sửa cấu hình nginx bằng tay.
Nguồn: Habr (blog Selectel)
Bản Self-Host Weekly tuần này của selfh.st tổng hợp các tin tức mà người chơi homelab nên biết. Tôi thích kiểu tổng hợp này vì nó tiết kiệm được rất nhiều thời gian đọc từng nguồn tin.
Tin nổi bật nhất khá rối rắm: một bộ công cụ mã nguồn mở mới tự giới thiệu là giải pháp thay thế Adobe bị chỉ trích là sao chép các dự án đã có, đặc biệt là Photopea, được cộng đồng yêu thích, và nhà phát triển của Photopea là một trong những người đầu tiên lên tiếng. Hai dự án ở trung tâm sự việc, PhotoSuite và PhotoCraft, có vẻ có liên hệ với nhau, và diễn biến khó theo dõi. Bản tin khuyên nên tránh xa cho đến khi họ chứng minh được rằng mình không chỉ là sản phẩm phái sinh.
Còn một số tin nhỏ đáng chú ý. Let's Encrypt thông báo rằng từ tháng 2 năm 2027, thời hạn của chứng chỉ SSL miễn phí sẽ rút ngắn từ 90 xuống 64 ngày, nên việc gia hạn tự động đáng tin cậy càng quan trọng với những ai chạy reverse proxy ở nhà. Nabu Casa sẽ đổi tên Home Assistant Cloud thành Home Assistant Link, vì từ "cloud" hiện mang ý nghĩa tiêu cực. Dự án chia sẻ bí mật mã hóa Hemmelig đã được lưu trữ trên GitHub. Còn NVIDIA Shield TV, hộp phát trực tuyến bảy tuổi được người chơi homelab ưa chuộng, tăng giá 100 đô la, và hãng cho rằng nguyên nhân là lạm phát phần cứng do AI thúc đẩy.
Tác giả cũng khởi động Khảo sát người dùng Self-Host 2026 với 45 câu hỏi về phần cứng, phần mềm, hệ điều hành, nhân khẩu học và AI. Khảo sát năm ngoái thu được hơn 4.000 phản hồi, còn năm nay đã có 2.000 phản hồi chỉ trong hai ngày. Khảo sát mở đến hết 31 tháng 10, và kết quả dự kiến công bố vào đầu tháng 11.
Riêng tôi, thay đổi về chứng chỉ là điều thiết thực nhất. Nếu cấu hình gia hạn của bạn hơi mong manh, bây giờ là lúc tốt để kiểm tra lại.
Nguồn: selfh.st
RedesZone trả lời một thắc mắc rất phổ biến của những người dựng máy chủ tại nhà: NAS có cần khởi động lại định kỳ không, hay có thể để bật suốt ngày đêm?
Câu trả lời ngắn gọn là có thể, NAS có thể bật 24 giờ mỗi ngày. NAS được thiết kế để hoạt động liên tục, dùng ổ lưu trữ chuyên dụng cho việc đó, và được dùng để sao lưu, giải phóng dung lượng trên thiết bị khác hoặc chia sẻ tệp lớn. Tất nhiên nó tiêu thụ điện, giống như router hay camera an ninh. Tuy vậy, các thiết bị này được thiết kế để tiêu thụ rất ít điện khi ở trạng thái nghỉ. Ngay cả sau nhiều tháng sử dụng liên tục, cũng không có lý do bắt buộc nào phải khởi động lại, trừ khi bạn muốn tiết kiệm điện hoặc đơn giản là không cần dùng nữa.
Vẫn có những tình huống nên khởi động lại: sau khi cập nhật hệ điều hành, firmware hoặc một số gói phần mềm, dù thiết bị không yêu cầu; khi có sự cố phần mềm, chẳng hạn ứng dụng ngừng hoạt động, dịch vụ chạy chậm, giao diện web hoạt động bất thường hoặc có lỗi ở một phần nào đó; sau khi thay đổi phần cứng; và sau mọi thay đổi lớn trong cách vận hành. Đôi khi một tiến trình bị treo hoặc một chương trình không đóng đúng cách, và khởi động lại sẽ đưa mọi thứ về bình thường.
Tôi thấy đây là lời khuyên hợp lý và không gây hoang mang. Với phòng lab tại nhà, quy tắc thực tế là để NAS tiếp tục làm việc và khởi động lại một cách có chủ đích, sau khi cập nhật hoặc khi có gì đó hoạt động lạ, thay vì làm theo thói quen.
Nguồn: RedesZone
Khi chạy ứng dụng mã nguồn mở trên máy chủ tại nhà, bạn thường cần gửi email cho những việc như đăng ký hay đặt lại mật khẩu. Tuy nhiên, gửi thư trực tiếp từ nhà đòi hỏi phải dựng máy chủ SMTP và cấu hình tên miền người gửi, mà việc này tốn công hơn bạn nghĩ. Bài viết tôi tìm thấy trên Qiita giải quyết vấn đề này một cách gọn gàng bằng Mailpit và Discord.
Mailpit vốn là công cụ để kiểm thử việc gửi email. Nó có thể dùng làm máy chủ SMTP và còn có API dành cho kiểm thử. Khi cấu hình webhook, nó có thể gọi một ứng dụng bên ngoài ngay khi có thư đến. Bài viết tận dụng tính năng này để xây dựng một hệ thống chuyển nội dung các thư đến sang Discord.
Cấu trúc khá đơn giản: hai container chạy bằng Docker Compose, gồm Mailpit và một webhook-handler. Webhook-handler là một ứng dụng Python nhỏ viết bằng FastAPI. Nó nhận webhook từ Mailpit, định dạng người gửi và người nhận, rồi chuyển đến một webhook của Discord. Thông báo còn có thể kèm đường dẫn tới giao diện web của Mailpit để xem thư khi cần. Các thiết lập như địa chỉ webhook được tách riêng trong tệp .env.
Ngay cả khi không gửi thư nào ra bên ngoài, việc biết ngay thư đặt lại mật khẩu đã đến cũng rất tiện. Với người chạy nhiều ứng dụng trong homelab, gom toàn bộ thư về một chỗ có lẽ sẽ giúp việc quản lý dễ hơn nhiều. Bài viết đăng vào tháng 8 năm 2026.
Nguồn: Qiita
Một câu chuyện nhỏ nhưng đáng suy nghĩ cho ai đang tự quản lý mạng ở nhà. Theo GenK, một người dùng X có tên @NomadsGalaxy nhận nhiệm vụ kiểm tra mạng Wi-Fi cho bố mẹ và phát hiện chiếc máy pha cà phê Keurig đã tạo ra khoảng 1 TB lưu lượng tải lên và gần 10 GB tải xuống chỉ trong 10 ngày.
Anh phát hiện sự việc khi xem hệ thống mạng UniFi tại nhà bố mẹ. Lượng dữ liệu bất thường này đã khiến một điểm truy cập Wi-Fi bị quá tải. Anh quyết định rút điện chiếc máy và mua cho bố mẹ một sản phẩm khác thay vì điều tra nguyên nhân. Theo bài viết, phần lớn lưu lượng dường như chỉ luân chuyển trong mạng nội bộ chứ không được gửi ra Internet, nên chưa có bằng chứng cho thấy máy đã chuyển dữ liệu của gia đình đến máy chủ bên ngoài. Nguyên nhân có khả năng cao nhất là lỗi phần mềm hoặc lỗi giao tiếp trong mạng, và khởi động lại có thể đã xử lý được.
Bài viết cũng nhắc đến bức tranh lớn hơn của nhà thông minh: càng nhiều thiết bị kết nối mạng, khả năng xuất hiện lỗi, lỗ hổng bảo mật hoặc dịch vụ ngừng hoạt động càng tăng. Thiết bị IoT có thể trở thành cửa ngõ tấn công nếu nhà sản xuất không cập nhật phần mềm thường xuyên, và một số sản phẩm mất phần lớn chức năng khi hãng đóng cửa máy chủ.
Với mình, bài học thực tế là nên có công cụ theo dõi lưu lượng theo từng thiết bị trong mạng gia đình, và cân nhắc tách các thiết bị IoT sang một mạng riêng. Không có số liệu thì rất khó nhận ra một chiếc máy pha cà phê đang làm gì.
Nguồn: GenK
Ai quản lý mạng gia đình hoặc một homelab nhỏ đều biết rõ hậu tố .lan: nó xuất hiện trên bảng điều khiển router, trên máy chủ DNS nội bộ và trong các địa chỉ chúng ta dùng để truy cập thiết bị mà không cần tên miền đã đăng ký. IlSoftware.it cho biết một đơn đăng ký gửi lên ICANN có thể biến nó thành tên miền Internet có thể truy cập trên toàn thế giới.
Đơn xin tên miền cấp cao nhất .lan do công ty Mỹ Coffee Danger nộp, và hiện vẫn đang ở giai đoạn Pre-Evaluation Processing. Điều này có nghĩa là tên miền chưa được phê duyệt và chưa thể dùng để đăng ký địa chỉ công khai. Đơn này nằm trong đợt phân bổ tên miền cấp cao nhất mới mà ICANN khởi động năm 2026, với sự tham gia của hàng trăm công ty: trong số người nộp đơn có Google với .browser, OpenAI với .openai và .chatgpt, Meta với .facebook, và công ty Ý Aruba với các tên miền như .pec, .vps, .lab, .roma và .ciao. Mọi đơn đăng ký vẫn đang chờ thẩm định.
Điểm nhạy cảm là .lan không phải là một cái tên thông thường. Nhiều kỹ thuật viên đã dùng nó từ lâu, chẳng hạn nas.lan, router.lan hay camera.lan. Nếu một tên được coi là nội bộ đi vào DNS công khai, rủi ro là lỗi hoạt động, truy vấn DNS rời khỏi mạng và kết nối có thể đến những đích khác với ý định ban đầu.
Là người yêu thích mạng gia đình, tôi thấy tin này là lời nhắc nhở hữu ích: với tên nội bộ, nên dùng những hậu tố được thiết kế cho mục đích đó thay vì dựa vào quy ước đã thành thông lệ. Hiện chưa có quyết định nào, nhưng đáng để theo dõi.
Nguồn: IlSoftware.it
Korben quay lại một lệnh của Cloudflare mà nhiều lập trình viên đã dùng: cloudflared tunnel --url. Lệnh này đưa một máy chủ đang chạy trên máy bạn lên một địa chỉ trycloudflare.com, không cần tài khoản, không cần tên miền và quan trọng nhất là không phải mở cổng nào trên router. Với người tự lưu trữ dịch vụ tại nhà, đây là cách đơn giản để cho ai đó xem dự án trong một bài thử ngắn.
Tính năng mới nhất là tùy chọn --allowed-mail. Trước đây, ai có liên kết đều có thể kết nối vào dịch vụ. Giờ bạn có thể giới hạn quyền truy cập cho một vài địa chỉ email do mình chỉ định, với mã dùng một lần được gửi qua Cloudflare Access.
Hướng dẫn bắt đầu bằng một máy chủ web cục bộ nhỏ ở cổng 8080, phục vụ trang thử nghiệm bằng Python. cloudflared là trình kết nối mã nguồn mở, thiết lập kết nối đi ra tới mạng của Cloudflare. Trên Mac, cài đặt qua Homebrew. Trên Debian hoặc Ubuntu, cần dùng kho chính thức của Cloudflare, và khóa ký của kho này vừa thay đổi, vì vậy tác giả khuyên nên dùng các lệnh hiện hành thay vì lệnh trong hướng dẫn cũ.
Có một điểm khiến tôi chú ý: nếu bạn để các agent AI làm việc với công cụ này, Cloudflare khuyến nghị một hook PreToolUse chặn mọi lệnh không có --allowed-mail, để agent không vô tình mở một đường hầm công khai.
Với homelab, đây là lựa chọn nhẹ thay cho việc mở cổng hay dùng VPN, miễn là bạn nhớ rằng đường hầm công khai vẫn là một lần phơi bày ra Internet, dù chỉ tạm thời.
Nguồn: Korben
