Open Source Client Portal Software

Every client portal claims to be secure. But that claim means something very different when you can inspect the code yourself, host it on your own server, and migrate away without asking permission. Open source turns 'trust us' into something you can actually verify.

Why does the license matter when sharing client files?

The license determines who controls the software -- and by extension, where your client data lives and what happens when you want to leave. Open source means you can read every function, run the code on any infrastructure, and move your files without requesting an export from a vendor support team.

A closed SaaS portal stores your files on infrastructure you cannot inspect, under terms of service that can change without notice. That is fine when you trust the vendor completely. It becomes a problem when pricing doubles, a feature gets sunset, or the company is acquired. For firms handling client financials, legal filings, or creative deliverables, the control question is not hypothetical.

Open source software licensed under GPLv2 gives you a concrete guarantee: the code stays open, and any modifications must stay open too. No vendor can quietly relicense it into something proprietary. That is the kind of commitment you can point to -- not just a marketing promise.

What open source actually gives you

Four things a closed portal cannot match:

• Inspect the code: see exactly how files are stored, encrypted, and logged. No black box, no guessing about how your client data is handled.
• Self-host: run the software on your own server, with your own backup and retention policy. The hardware is yours; the rules are yours.
• Migrate freely: the code is GPLv2, which means it stays open regardless of what any hosted provider decides. You can always take the code and run it elsewhere.
• No single point of failure: if a cloud service shuts down tomorrow, the open source project still exists. You are not stranded.

ProjectSend: 4.8 million installs and still maintained

ProjectSend is an open source client portal with 4.8M+ Docker downloads, 4,000+ active self-hosted instances worldwide, and 1,900+ stars on GitHub. It supports 70+ languages, 45 granular permission levels, resumable uploads (5 GB+), enforced 2FA, audit trail export, and in-app notification digests. It has been actively maintained for over a decade.

The source is on GitHub, and the project home is projectsend.org. The license is GPLv2 -- not AGPL, not MIT. GPLv2 means you can use it commercially, self-host it without network-use restrictions, and fork it freely. That was a deliberate choice by the maintainers -- see the open source commitment -- and it is part of why the project has lasted this long.

If you are comparing the self-hosted project against the official hosted option, this breakdown of ProjectSend hosted vs. self-hosted covers the operational differences in detail.

Self-hosted versus hosted: which fits your situation?

Running ProjectSend yourself means managing the server, SSL certificate, mail delivery, backups, and version upgrades. That is a reasonable trade if you already have infrastructure and someone who enjoys running it. It is extra overhead if you do not -- and it compounds with every other service you operate.

ProjectSend Cloud is the official hosted version of the same codebase, run by the team that builds the open source project. Architecturally, a self-hosted install is just one tenant: the software is identical. Migration runs in both directions -- we move self-hosted instances to Cloud in under 48 hours, and we export cleanly back if you want to return to self-hosting. The open source project has always been a valid choice, and that does not change when you host with us.

You can read more about how the platform works and compare what each plan includes on the pricing page.

What to look for in any open source client portal

If you are evaluating options beyond ProjectSend, these are the criteria worth checking carefully:

• License: GPLv2 permits commercial self-hosting with no network-use restrictions. AGPL adds an obligation to release modifications if you run the software as a service -- important to understand before you build on it.
• Audit trail: can you see who downloaded which file and when? Is that log exportable? For client-facing work, the ability to prove delivery is often as important as the delivery itself.
• Granular permissions: file-level and folder-level access per client is not a given. Check that you can isolate what each client sees before you commit.
• Active development: check the GitHub commit history. An open source project that has not shipped in 18 months is accumulating security and compatibility debt without you knowing it.
• White-label: your clients should see your name, not the portal's. Separate controls for logo, login domain, and outgoing email domain are the baseline for a professional delivery.
• A managed option: an official hosted version means the project has a business model behind it. That is usually a good signal for long-term maintenance and support availability.

If you want to start self-hosting, the full source code is at ProjectSend.org -- GPLv2, no licensing fee, ready to deploy. If you want the same software without the server work, ProjectSend Cloud is the official hosted option: Free at $0, no credit card, no time limit.