HolyArrs gom sáu app quản lý media vào một bản Docker 15 MB, nhưng nó không thay Plex

Sáu app trong bộ *arr được thay bằng một tiến trình, tổng tải về từ 718 MB còn 14,9 MB

Ai từng dựng máy chủ media tại nhà đều biết cảnh chạy cùng lúc Sonarr cho phim bộ, Radarr cho phim lẻ, Lidarr cho nhạc, Prowlarr quản lý nguồn tìm kiếm, Bazarr lo phụ đề và Overseerr nhận yêu cầu từ người nhà. Mỗi app một cổng, một tài khoản, một khoá API và một chu kỳ cập nhật riêng; khi một tập phim không về, người dùng phải mở sáu nơi để tìm xem nó kẹt ở đâu. Đó cũng là lý do CoderLuii đưa ra khi làm HolyArrs: muốn một app, một tài khoản, một cổng 6262, một chỗ để nhìn.

Con số gây chú ý nhất nằm trong bảng so sánh ở README của dự án, đo ngày 08/11/2026 trên ảnh Docker nén của linuxserver.io, kiến trúc amd64.

Ứng dụng	Dung lượng tải về (amd64, nén)
Sonarr	87,9 MB
Radarr	91,0 MB
Lidarr	121,3 MB
Prowlarr	80,8 MB
Bazarr	156,4 MB
Overseerr	180,8 MB
Sáu app cộng lại	718,2 MB
HolyArrs	14,9 MB

Số liệu: README của HolyArrs trên GitHub.

Phép chia 718,2 cho 14,9 ra gần 48, khớp với mức “nhỏ hơn khoảng 48 lần” tác giả ghi. Có điều bảng này chỉ so dung lượng tải về; cột RAM lúc chờ của sáu app cũ để trống, nên chưa có con số nào cho thấy HolyArrs tiết kiệm bộ nhớ bao nhiêu so với cả stack đang chạy. Với người đang chạy đủ sáu container, mức tiết kiệm thực tế còn tuỳ từng máy.

Một tiến trình Go cộng SQLite giải thích vì sao nó nhẹ, còn con số RAM thì lệch giữa hai nguồn

Trang chủ holyarrs.com mô tả kiến trúc khá thẳng: một tiến trình Go cho toàn bộ máy chủ, một cơ sở dữ liệu SQLite dùng chung cho thư viện, giao diện viết bằng Svelte, đóng gói trong Docker. Bộ *arr gốc đi theo hướng khác, Sonarr và Radarr là máy chủ .NET, Bazarr chạy Python, Overseerr chạy Node.js, tức là mỗi app mang theo một runtime riêng. Gộp tất cả vào một binary Go loại bỏ cả đống runtime lặp, và đó là chỗ phần lớn con số 15 MB đến từ.

Về RAM, README ghi khoảng 140 MiB lúc chờ, đo với thư viện 10.000 tựa và 55.000 phim, tập phim. Bài của XDA Developers ngày 08/11 lại dẫn con số 70 MB với 12.800 phim, chương trình. Hai nguồn đều đến từ chính tác giả nhưng khác thư viện thử và khác thời điểm, nên không nên chọn một số đẹp hơn; mốc 140 MiB trong README là con số mới và có điều kiện đo rõ ràng hơn. Theo XDA, CoderLuii cũng đặt giới hạn cứng về bộ nhớ, thời gian khởi động và dung lượng ngay từ đầu, rồi cho Claude viết app theo hai cách và chọn bản nhẹ hơn khoảng 3 lần, nhanh hơn rõ rệt.

Chi tiết về cách làm này đáng nhìn kỹ hơn chuyện “AI viết app”. Phần lớn dự án vibe-coding thất bại ở chỗ không có ràng buộc đo được; ở đây tác giả biến dung lượng và RAM thành điều kiện đầu vào, và một con số đo công khai kèm ngày đo cho phép người khác kiểm lại.

HolyArrs không phát phim thay Plex, và bản 1.0 vẫn cần trình tải bên ngoài

Cách XDA đặt tiêu đề “Plex-like” dễ khiến người đọc hiểu nhầm. Giao diện của HolyArrs lướt theo hàng như dịch vụ streaming, di chuột vào một tựa thì phát trailer, nhưng đó là giao diện để duyệt và yêu cầu nội dung. Phim không được phát từ HolyArrs: nó tìm bản phát hành trong các nguồn, chọn bản tốt nhất theo quy tắc người dùng đặt (dung lượng, chất lượng, ngôn ngữ), gửi cho trình tải, rồi đổi tên và xếp vào thư viện để Plex, Jellyfin hoặc Emby nhận.

Phần tải file cũng chưa nằm trong app. HolyArrs hiện kết nối qBittorrent, Transmission, Deluge, SABnzbd và NZBGet; một trình tải tích hợp mới nằm trong kế hoạch cho bản sau. Nguồn tìm kiếm là bất kỳ indexer Torznab hoặc Newznab nào, hoặc qua Prowlarr, Jackett. README liệt kê thẳng những thứ bản 1.0 chưa có: tự tải, tính năng AI hoặc MCP, app điện thoại và TV, còn mục nhạc trong Explore đang được làm, việc tìm phụ đề trực tuyến để sau 1.0. Dùng web trên điện thoại thì được.

Một chi tiết đáng cân nhắc: README cho biết app lấy tên phim, ảnh bìa và bảng xếp hạng từ máy chủ metadata do chính tác giả trả tiền duy trì hàng tháng, nhờ vậy người dùng không phải đi xin khoá API riêng. Tiện, nhưng mỗi bản cài đặt đều phụ thuộc vào một máy chủ do một người vận hành bằng tiền tài trợ.

Chuyển từ Sonarr, Radarr sang có thể thử trước mà không động vào hệ thống cũ

Phần được cân nhắc kỹ nhất của HolyArrs là cách chuyển nhà. Trong Settings, người dùng nhập địa chỉ và khoá API của từng app cũ (hoặc một file backup), chọn thứ cần mang qua, chạy chế độ thử rồi mới chuyển thật, và có thể hoàn tác sau đó. Tác giả cam kết app chỉ đọc các app cũ chứ không sửa gì trong đó, nên hai bên chạy song song được cho đến khi người dùng tin tưởng.

Thứ được mang qua gồm thư mục thư viện, tựa phim, hồ sơ chất lượng (thành quy tắc chọn bản), danh sách loại trừ, cách đặt tên, indexer và trình tải; yêu cầu đang chờ từ Overseerr cũng sang theo. Khoá và mật khẩu thì phải nhập lại, còn custom format, tag và lịch sử không được chuyển. Với người đã chỉnh custom format kỹ trong Radarr hoặc Sonarr, đây là điểm trừ lớn nhất cần biết trước khi quyết định.

Với homelab Việt Nam: hợp Raspberry Pi và NAS nhỏ, nhưng đừng gỡ stack cũ vội

HolyArrs miễn phí, cài bằng một file docker-compose và có bản amd64, arm64, armv7, tức là chạy được trên PC, NAS, Apple silicon, Raspberry Pi đời mới và cả các board ARM 32-bit cũ. Với người dùng Việt Nam hay tận dụng TV box arm64, Raspberry Pi hoặc NAS mini RAM ít để làm máy chủ media, việc đổi sáu container lấy một là lý do hợp lý để thử. Hiện chưa có ai công bố số đo trên đúng các thiết bị này, nên mức tiết kiệm trên Pi vẫn là suy luận từ con số 140 MiB, chưa phải kết quả đã kiểm chứng.

Dự án còn trẻ: ngày lấy tư liệu, kho GitHub mới có 19 commit, 553 sao và 73 issue đang mở, và README nhắc rõ phải tạo tài khoản chủ ngay lần truy cập đầu vì ban đầu chưa có mật khẩu mặc định, đồng thời không nên mở cổng 6262 ra internet mà nên đi qua VPN như Tailscale hoặc reverse proxy có HTTPS. Cách hợp lý nhất là dựng HolyArrs song song với stack hiện có, dùng chế độ thử để xem nó đọc được bao nhiêu cấu hình, và chỉ gỡ các app cũ khi custom format cùng quy trình hằng ngày đã chạy ổn trên bản mới.

Nguồn tham khảo: HolyArrs trên GitHub, holyarrs.com, XDA Developers