ProjectSend: a self-hosted client file portal, and what the rebuild changed
Share files with your clients, from your own server. Free, open source (GPLv2), self-hosted — or use ProjectSend Cloud, the official hosted version run by the same team.
At a glance
- What is it?
- ProjectSend gives each client a private login page for the files you share with them, running on your own server under GPLv2. The current codebase is a rebuild of the older ProjectSend, so the interesting questions are about migration and operations, not features.
- Who is it for?
- Adopt ProjectSend if you send documents to named clients on a recurring basis and want the files to stay on infrastructure you control. Do not adopt it if you need a public link you can paste into an email or a chat message, or if you cannot run a PHP 8.4 application with a database and a background worker.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem ProjectSend picks: files for named people, not links for anyone
Most file sharing is built around a link. You upload something, you get a URL, you paste it wherever the recipient happens to be. ProjectSend inverts that. The README describes the model directly: you upload what you want to send, choose exactly who can see it, and each client signs in to their own private page to download it. There is no public link to pass around, and no third-party service holding the documents.
That constraint is the product. It fits agencies, accountants, consultancies, and any small organisation that hands documents to a defined set of clients and would rather not run a shared drive or a public bucket. The README also frames the commercial side plainly: ProjectSend Cloud is the official hosted version run by the same team, and the README states that every subscription funds the free software. So the free core and the hosted product are maintained by one group, with the boundary between them documented in LICENSING.md rather than left implicit. If you are evaluating this for a business, that file is the one to read before anything else, because it defines what you get for free and what you would be paying for.
How the pieces fit: clients, groups, and a per-client view
The architecture visible in the README is a conventional PHP web application with a database and a background worker. On one side there is an administrative interface: a file library with folders, categories, thumbnails, and a sharing status per file, plus a dashboard showing counters for files, clients and groups, storage usage against quotas, a month of uploads and downloads as a line chart, and recent activity. On the other side there is the client portal, which shows only the files shared with that client.
Sharing targets are not limited to individual clients. The README lists sharing with one client, a whole group, or publicly, and attaching an expiry date or a download limit to a share. That combination is what makes it a portal rather than a folder: the same file can be visible to a group, invisible to everyone else, and stop being available on a date you set. Access control extends upward into the installation too, with roles and permissions so that an uploader account is not an administrator, and sign-in options covering LDAP, social sign-in, or email and password.
Storage is pluggable. The README names local disk, S3-compatible storage, and Google Cloud Storage as the backends. That matters for the operational story, because it determines what you actually need to back up and where the bytes live when you move a container.
Getting it running: Docker first, zip second
The README recommends Docker and gives a three-step path. You fetch the example compose file, edit it, and start it:
curl -O https://raw.githubusercontent.com/projectsend/projectsend/main/docker/production/compose.example.yaml docker compose -f compose.example.yaml up -d
The README states that the published image ships with its dependencies and its frontend already compiled, so there is nothing to build. After starting, opening APP_URL shows a setup screen that creates the administrator account, unless you uncomment ADMIN_EMAIL and ADMIN_PASSWORD in the compose file first, in which case the account is created with the password you set. The README also tells you to edit the passwords and APP_URL in the file before bringing it up, and to read DOCKER.md before putting real files in, specifically for where the database and uploads live, how to relocate them, and how to back them up so an upgrade does not take them with it.
The non-Docker path is a release zip. The README says you do not need Composer or npm on the server because the zip ships ready to run, and points at INSTALL.md for requirements, the .env file, nginx configuration, the background worker and cron, updating, and troubleshooting. That background worker and cron entry are easy to skim past. If you install from the zip and skip the worker, the parts of the application that depend on background processing will not run, and the README treats that setup as part of the install rather than an optional extra.
There is a trap worth naming. Cloning the repository is not an installation. The README states that dependencies and the compiled frontend are deliberately not in git, so a clone needs Composer and npm before it runs at all. If you want to run the software, use the image or the zip; clone only if you intend to work on ProjectSend itself.
Where it will not fit: no public links, and a real server to run
The design decision that makes ProjectSend useful to an agency makes it the wrong tool for a lot of other jobs. If your workflow is sending a one-off file to someone whose email address you have but who will not create an account, this is not the product. There is no anonymous share-by-URL at the centre of it. The README does list public sharing as an option alongside per-client and per-group sharing, but the framing throughout is a client signing in to their own page, and the README notes that in the migration from the older version, clients will notice one change: they sign in with their email address now, using the same password. Accounts are the model.
The second constraint is operational. This is a PHP application with a database, a background worker, and cron, and the README badges state PHP 8.4 or later. You are running a server. That is a smaller commitment than it sounds if you already run Docker, and a larger one if you do not. The README is explicit that the Docker route is the quickest and the recommended one, and that the zip exists for servers where Docker is not an option. Either way, somebody has to own the database, the upload directory, and the upgrade path.
A third limitation is the one the README names itself. This is a rebuild, not an upgrade. Moving from the previous generation is an import, not an update. That is a meaningful distinction for anyone with an existing installation and a body of client history, and it is the single fact most likely to change an adoption decision.
Migrating from ProjectSend Legacy is an import, not an upgrade
The previous generation lives at projectsend/legacy, and the README is direct that the current code is a rebuild. The migration route is a separate tool, projectsend/v1-migration-tool, which the README says brings across accounts, clients, groups, categories, folders, files and history. You install fresh and then import.
Two properties of that tool are stated in the README and are worth repeating because they reduce the risk of the operation. It never writes to your old install, so the source system stays intact while you work. And any run can be undone with a single command, which means you can practise the import against a copy and discard the result. MIGRATING-FROM-V1.md is where the detail lives: what actually comes across, the two routes (same machine, or a portable export from a server you cannot reach), and the client-visible change to email-based sign-in.
What the README does not give is a statement about how long a large migration takes or what happens to files that were stored in a way the tool does not expect. Treat the documented undo command as the reason you can find out for yourself on a staging copy rather than in production. If your old installation has years of download history attached to client accounts, that history is listed as part of what comes across, so the migration is not just a file copy.
The alternative: Nextcloud, and the difference in shape
The obvious comparison for a self-hosted file tool is Nextcloud. The two solve different problems, and the difference is structural rather than a matter of feature counts.
Nextcloud is a general collaboration platform. It gives every user an account with their own storage, desktop and mobile sync clients, calendars, contacts, document editing, and a large app ecosystem. Sharing is one feature inside a much bigger product, and a share is typically a link or a user grant inside a file tree that both parties can see and modify.
ProjectSend is narrower by design. There is no sync client in the README's feature list and no general-purpose user storage. Clients do not get a drive; they get a page listing what you shared with them, with search, filtering, sorting, zip download of several files or a whole folder, optional comments on a file, and email notifications in their own language. Storage quotas, custom client fields, and a full activity log with download history are administrative features aimed at the person running the portal, not at end-user collaboration. The README also lists a REST API with scoped tokens and generated OpenAPI docs, plus privacy controls including account erasure with a grace period, which suggests the target is an organisation with compliance obligations toward its clients.
If you want one platform for internal collaboration and external sharing, Nextcloud covers more ground and you will pay for it in surface area and operational weight. If what you need is a controlled handoff to clients with per-client visibility, quotas, and an audit trail, ProjectSend's narrower model means less to configure and fewer ways for a client to see something they should not. The trade is that anything outside that handoff is out of scope.
Upgrades, licensing, and what to check before you commit
The project moves quickly. The release list shows v2.4.0, v2.3.0 and v2.2.1 within roughly two weeks, which is a fast cadence for an application that holds client documents. The README points to UPDATE.md for the mechanics: one command on Docker, one script on a self-hosted install, plus what to check afterwards in both cases. A fast release cadence is only a problem if your upgrade path is manual and undocumented, and the README's insistence on reading DOCKER.md before adding real files reads as an acknowledgement that the data directory is the part people get wrong.
On licensing, the README states the project is free software under the GNU General Public License v2, or at your option any later version. It also states that commercial licenses are available for organisations that cannot work under copyleft terms, and that contributions require signing a CLA. Those two facts together are the reason LICENSING.md exists and the reason you should read it rather than assume. If you intend to modify ProjectSend and distribute the result, or to embed it in something you ship, the copyleft terms apply and the commercial option is the alternative the project offers. That is a question for your own counsel, not for a review.
The practical checks are short. Confirm your PHP version against the 8.4+ requirement in the README badges. Decide where the database and upload directory will live before you import anything, because DOCKER.md is where that is explained and moving data afterwards is the scenario the README warns about. If you are on the older ProjectSend, run the migration tool against a copy first and use the documented undo to discard it. And read LICENSING.md if your organisation's use of GPL software is not already settled. ProjectSend is a good fit for a small team that already runs a server and wants client files under its own control; it is a poor fit for anyone who wants to hand out a link and be done.
Editorial conclusion
Adopt ProjectSend if you send documents to named clients on a recurring basis and want the files to stay on infrastructure you control. Do not adopt it if you need a public link you can paste into an email or a chat message, or if you cannot run a PHP 8.4 application with a database and a background worker. Before committing, verify three things against your own setup: that your PHP version meets the 8.4+ requirement stated in the README badges, that the resumable upload path works through whatever reverse proxy or upload size limit sits in front of it, and, if you are coming from the older ProjectSend, that the v1 migration tool carries your folder and history structure across in a test run before you touch production.
Community notes