ProjectSend là gì? Hướng dẫn cài đặt, triển khai và kinh nghiệm thực chiến gửi file cho khách

Hướng dẫn triển khai ProjectSend cho cổng gửi file khách hàng: preconditions, upload limits, hardening, backup, verify và rollback rõ ràng trong production.

NHT
· 8 phút đọc
ProjectSend là gì? Hướng dẫn cài đặt, triển khai và kinh nghiệm thực chiến gửi file cho khách

Vì sao mình “chốt đơn” ProjectSend?

Một lần cần gửi gấp 2GB tài liệu. Email nghẹn họng, link Google Drive thì cứ “xin quyền”. Mình quay xe dựng ProjectSend trên máy của mình, tạo tài khoản cho khách, gán đúng file, nhấn là tải — không lo lộ kho lưu trữ. Từ đó… ghiền luôn. Tự chủ dữ liệu, kiểm soát truy cập, có log. Gọn mà chuẩn bài cho kịch bản trao file cho khách.

ProjectSend là gì? Dùng khi nào?

ProjectSend là phần mềm chia sẻ file tự host, tập trung vào kịch bản “gửi file cho khách hàng/đối tác” có kiểm soát. Bạn tạo Client, nhóm client, gán file theo người hoặc theo nhóm, đặt hạn dùng, bật thông báo email, và thậm chí cho khách upload ngược lại khi cần. Xem thêm tại trang chủ ProjectSend và tài liệu chính thức:

Điểm mình thích: giao diện gọn, logic theo “dự án + khách”, audit log đầy đủ, triển khai được ở nhiều môi trường từ shared hosting đến Docker.

Yêu cầu hệ thống (đủ xài là chạy)

  • PHP 7.4+ và MySQL 5.0+ hoặc MariaDB.
  • Web server: Apache hoặc Nginx. Khuyến nghị bật X‑Sendfile/X‑Accel để tải xuống mượt, không “kẹt” qua PHP.
  • PHP extensions thường gặp: pdo, pdo_mysql, mbstring, gettext, fileinfo, gd2, xml, zip. Thêm cURL càng tốt.
  • Nên tăng memory_limit, post_max_size, upload_max_filesize nếu upload lớn.

Tham khảo chi tiết trong tài liệu: Requirements.

So nhanh với Nextcloud và FileRun

  • Nếu mục tiêu chính là “cổng trao file cho từng khách” kèm log chi tiết: ProjectSend là “điểm ngọt”.
  • Cần đồng bộ đa thiết bị, lịch, apps mở rộng: Nextcloud phù hợp hơn.
  • Muốn file manager mạnh, UI quản lý file kiểu truyền thống: FileRun là lựa chọn đáng cân nhắc.

Góc nhìn cộng đồng về ProjectSend vs Nextcloud: LibHunt và bảng so sánh khác trên SourceForge.

Ba cách triển khai mình khuyên dùng

1) Windows Server + Laragon + Cloudflare Tunnel

Kịch bản: máy tại nhà hoặc VPS Windows, không IP tĩnh, không mở port. Dùng Cloudflare Tunnel để public domain an toàn.

  • Cài Laragon (Apache/Nginx + PHP + MySQL). Tải tại: Laragon
  • Tải bản phát hành mới của ProjectSend, kiểm tra checksum rồi giải nén vào thư mục web. ProjectSend
  • Tạo database và user mới (phpMyAdmin có sẵn trong Laragon).
  • Truy cập domain nội bộ để chạy installer.
  • Dùng Cloudflare Tunnel để xuất bản ra ngoài, không cần mở cổng: Cloudflare Developers
  • Lưu ý ingress nên trỏ thẳng tới cổng web gốc, tránh rewrite kiểu /projectsend.

2) Ubuntu LEMP/LAMP (VPS phổ biến)

  • Cài Nginx hoặc Apache + PHP 8.x + MariaDB.
  • Tạo database, cấp quyền user.
  • Giải nén mã nguồn vào /var/www/... rồi chown/chmod cho www-data.
  • Truy cập domain để chạy installer, cấu hình SMTP nếu muốn gửi thông báo.
  • Tham khảo cách cấu hình Apache + Let’s Encrypt: Cộng đồng Linux

3) Docker (nhanh – gọn – dễ cập nhật)

  • Dùng image do LinuxServer.io duy trì. Lợi thế: mount volumes cho config và uploads, update container không lo mất dữ liệu.
  • Hướng dẫn và compose mẫu: LinuxServer.io ProjectSend

Cài đặt nhanh trong 5 bước

  1. Tải bản r1945 từ trang chủ và xác minh SHA‑256 checksum.
  2. Tạo database MySQL và user riêng cho ProjectSend.
  3. Giải nén mã nguồn, nếu cần đổi includes/sys.config.sample.php thành sys.config.php và nhập thông tin DB.
  4. Truy cập http(s)://domain‑của‑bạn để chạy installer, tạo tài khoản admin.
  5. Cấu hình logo, SMTP, hạn mức upload, bật X‑Sendfile/X‑Accel nếu hạ tầng hỗ trợ.

Tài liệu cài chi tiết: Manual installationRequirements.

Best practices khi chạy production

  • Bắt buộc dùng HTTPS: Let’s Encrypt trên Nginx/Apache hoặc Universal SSL nếu đi qua Cloudflare.
  • Tách storage: đặt thư mục uploads ngoài webroot và để web server serve qua X‑Accel/X‑Sendfile.
  • Backup định kỳ: cả database + uploads, và test khôi phục.
  • Giới hạn loại file nguy hiểm, đặt quota theo client/nhóm, bật thông báo email với file “nhạy cảm”.
  • Quy trình client rõ ràng: đặt tên tài khoản theo dự án, xong dự án thì gỡ quyền, lưu log.
  • X‑Sendfile/X‑Accel tham khảo: mod_xsendfile

Mẹo hiệu năng và trải nghiệm

  • Bật HTTP/2, nén gzip, cache tĩnh cho CSS/JS.
  • Với file lớn, cân nhắc upload theo “chunk” để vượt giới hạn mặc định của PHP. Xem thêm: ProjectSend Docs
  • Đặt timezone PHP thành Asia/Ho_Chi_Minh để log đúng giờ VN.

Troubleshooting nhanh

  • Không đăng nhập được sau cài: kiểm tra session path và quyền thư mục tạm của PHP.
  • Lỗi 413 Request Entity Too Large khi upload: tăng client_max_body_size (Nginx) hoặc LimitRequestBody, post_max_size, upload_max_filesize (Apache/PHP). Tham khảo: Requirements
  • Link tải 404 khi đi qua proxy/Tunnel: soát lại ingress trỏ đúng cổng gốc, tránh rewrite path lạ.
  • Giao diện tiếng Việt: cài gói ngôn ngữ trong phần Languages của ProjectSend. Docs

FAQs

  • Có link công khai không? Có, nhưng vẫn nên ưu tiên phân quyền theo client để kiểm soát và log.
  • Upload tối đa bao nhiêu? Phụ thuộc cấu hình PHP/web server; chunk upload giúp ổn định với file lớn. ProjectSend Docs
  • Có SSO/LDAP không? Mặc định không. Nếu cần, dùng SSO ở reverse proxy hoặc cân nhắc Nextcloud.
  • Audit log thế nào? Có log hành động rất chi tiết. Xem giới thiệu: ProjectSend

Khi nào nên chọn ProjectSend?

Nếu bạn thường xuyên gửi tài liệu nặng cho khách, cần phân quyền rõ, cần log ai đã tải — mà vẫn muốn dữ liệu “nằm ở nhà mình” — ProjectSend là lựa chọn gọn, an toàn, dễ triển khai. Từ Windows + Cloudflare Tunnel, VPS Ubuntu đến Docker, bạn có thể dựng trong 15 phút là chạy. Hãy bắt đầu bằng bản r1945 mới nhất và tối ưu dần theo nhu cầu.

Kiểm tra điều kiện trước khi cài

Requirements của ProjectSend có thể thay đổi theo release. Trước khi tải mã nguồn, hãy đọc requirements của bản cụ thể, kiểm tra PHP extensions, database engine, quyền ghi thư mục và khả năng cấu hình web server. Không nên dùng mốc PHP 7.4/MySQL 5.0 cho một bản mới nếu tài liệu release đã nâng yêu cầu.

php -v
php -m | grep -E 'pdo|pdo_mysql|mbstring|fileinfo|gd|xml|zip|curl'
mysql --version
nginx -v 2>&1 || apache2 -v
upload_max_filesize=$(php -r 'echo ini_get("upload_max_filesize");')
post_max_size=$(php -r 'echo ini_get("post_max_size");')
echo "$upload_max_filesize / $post_max_size"

Tạo database và user riêng, quyền tối thiểu trên đúng schema; không dùng tài khoản root. Ghi lại phiên bản mã nguồn, checksum, PHP, database và web server vào runbook để lần khôi phục sau không phụ thuộc trí nhớ.

Upload lớn và loại file: phải giới hạn từ nhiều lớp

Giới hạn upload không chỉ nằm ở PHP. Cần đối chiếu upload_max_filesize, post_max_size, giới hạn request của Nginx/Apache, timeout proxy, disk quota và giới hạn ứng dụng. Sau mỗi thay đổi, thử một file hợp lệ nhỏ và một file vượt ngưỡng để xác nhận thông báo lỗi không làm lộ đường dẫn hệ thống.

LớpĐiểm cần kiểm traNguyên tắc
Ứng dụngAllowed extensions, MIME, quota, client permissionChỉ cho phép loại file thật sự cần.
PHPupload/post size, memory, execution timeĐặt theo file lớn nhất có lý do nghiệp vụ.
Web server/proxybody size, timeout, bufferingKhông mở không giới hạn toàn hệ thống.
Storagedisk quota, permissions, backupTheo dõi dung lượng và thử restore.

Danh sách extension cần chặn phải bao gồm script có thể thực thi trên web server, nhưng vẫn phải kiểm tra MIME và nội dung chứ không chỉ dựa vào đuôi file. Thư mục upload không được phép thực thi PHP; nếu hạ tầng hỗ trợ, tách storage khỏi webroot hoặc dùng X-Sendfile/X-Accel để download sau khi ứng dụng kiểm tra quyền.

Hardening production

  • Bắt buộc HTTPS, cookie bảo mật và mật khẩu mạnh; bật MFA nếu bản cài và workflow hỗ trợ.
  • Tắt directory listing, khóa file cấu hình và file backup, chặn truy cập trực tiếp vào thư mục không cần public.
  • Cập nhật ProjectSend, PHP và dependency theo maintenance window; đọc release note trước khi thay đổi.
  • Tách tài khoản admin, client và tài khoản database; thu hồi client cũ khi dự án kết thúc.
  • Ghi log đăng nhập, upload, download và thay đổi quyền; đặt cảnh báo với hành vi bất thường.
  • Backup database cùng uploads, mã hóa bản backup và kiểm tra khôi phục định kỳ trên môi trường tách biệt.

Verify, backup và rollback

# Checklist smoke test sau cài đặt hoặc nâng cấp
curl -I https://files.example.com/
# đăng nhập bằng admin test và client test
# upload file hợp lệ, file vượt giới hạn và file bị chặn
# kiểm tra download khi còn quyền và sau khi thu hồi quyền
# kiểm tra email/SMTP, timezone, log và dung lượng storage

Trước upgrade, lưu mã nguồn release cũ, file cấu hình, database dump và thư mục uploads. Ghi checksum và test một bản restore. Nếu release mới lỗi, đưa web server về artifact cũ, khôi phục database theo hướng dẫn migration tương ứng và kiểm tra quyền truy cập; không chỉ copy ngược một phần uploads rồi coi là rollback hoàn tất.

Tài liệu tham khảo