The client file portal you own: send big files and collect theirs, no WeTransfer clock
Share large files and let clients upload theirs — on a box you own, with links that expire when you say and no per-seat fee
Version history
Emailing a big file still fails in 2026, and the free tool everyone reaches for now deletes it after three days and forbids business use in its own terms. Here is the version you own: files out, client uploads in, links that die when you say — for the price of a server you may already run.
The problem
Two everyday jobs, one broken channel. You need to send a client 200 MB of photos, a signed contract or a short video — and email bounces it at the 25 MB mark. Or you need the client to send you their files, and "just reply with the attachments" turns into six emails and a missing page. WeTransfer's free plan now caps you at 3 GB across ten transfers a month, deletes the transfer after three days, shows ads, and — read the terms — is "individual, non-commercial use only," which a business is not. The paid way out is €8–23 a month for one person, or €19 per user per month for a team, to push your own files through someone else's server. This blueprint puts the whole thing on a box you control: a page where you drop a file and hand over a link that expires when you choose, and a reverse link where the client uploads to you.
The architecture
▼
[ ProjectSend (self-hosted, PHP+MySQL) — the client file portal ]
│ clients & groups, per-file access, expiry dates
│ send (download) + receive (upload request), full logs
▼
[ Your own domain behind HTTPS — files.yourbusiness.example ]
├─ send: private link, password + expiry, download tracked
├─ receive: an upload link the client uses, no account needed
└─ storage: local disk, or an S3-compatible bucket when files grow
One container plus a database, behind a reverse proxy that handles HTTPS. The portal owns access and expiry; the disk — or an object-storage bucket — owns the bytes. Keep those two separable so you can move the files to cheap object storage the day your small server runs out of room, without touching the sharing logic.
Tool choices — and why
ProjectSend (GPL-2.0, ~1.9k stars, active — last push 14/07/2026) is the default when the job is client file delivery. It is built for exactly this: named clients and groups, per-file permissions, upload requests, download statistics and logs, running on ordinary PHP+MySQL any host supports. It is not the prettiest tool on this list, but it is the one aimed squarely at "send files to my clients, and see who actually got them."
Pingvin Share X (BSD-2-Clause, active — v1.21.0, 01/07/2026) if you want a lightweight, WeTransfer-style drop: expiry dates, visitor limits, passwords, email-to-recipient, reverse shares, optional virus scanning, and local or S3 storage. One thing you must know, because most guides get it wrong: the original Pingvin Share was archived by its author in 2025 and is now read-only — every tutorial pointing at stonith404/pingvin-share is pointing at a dead project. Pingvin Share X is the maintained community fork. It is younger and has a smaller following (~260 stars), so weigh that against ProjectSend's decade of history before you commit client files to it.
Nextcloud (AGPL-3.0, actively developed) if you already run it, or want file-sharing as one feature of a full office suite — files, calendar, contacts, the lot. It does secure share links, expiry dates and upload folders perfectly well; it is simply far heavier than a job that only needs "send a link." Do not stand up Nextcloud just for file transfer — but if it is already on your box, you may not need anything else here.
Monthly cost. Software: €0 for all three. Hosting: nothing extra if this rides on the small server already running your other tools; a dedicated box is ~€3–6/month. Storage is the only real variable — local disk is free until it fills, and an S3-compatible bucket runs cents per gigabyte if your files get large. No per-person fee, no per-transfer fee, ever.
Setup outline
1. Deploy ProjectSend (official Docker image) behind HTTPS on a subdomain — files.yourbusiness.example. Never on plain HTTP; these are client files.
2. Create your first client and a group. Access in ProjectSend is per-client, so a customer only ever sees their own files, not everyone else's.
3. Set a default expiry — say 14 days — so old links die on their own instead of lingering forever.
4. Test the receive path: send yourself an upload-request link and add a file as if you were the client. This is the leg people forget to check until it fails in front of a customer.
5. Turn on email so clients get the link automatically, using your own mailbox's SMTP.
6. Set SPF, DKIM and DMARC on the sending domain, or the notification lands in spam.
7. Decide storage: local disk is fine to start; switch to an S3-compatible bucket before the disk fills, not after.
8. Back it up (see the 3-2-1 backup blueprint). A file portal with no backup is a single point of failure for documents a client trusted you with.
Pitfalls — the real ones
Half the tutorials point at a dead project. The self-hosted-WeTransfer advice online overwhelmingly names Pingvin Share; that repo was archived in 2025. Use the maintained fork (Pingvin Share X) or ProjectSend, and check the last-commit date on anything you install.
A public upload form is an open door. A reverse-share link with no password and no expiry is an invitation for strangers to fill your disk. Password-protect upload links, cap the size, and set an expiry on every one.
Client files are personal data (GDPR). Contracts, ID scans and photos on your box are your responsibility: encrypt the disk, expire links, and delete files when the job is done. Self-hosting does not lift the duty — it puts you in charge of it.
HTTPS is not optional. A file link over plain HTTP can be read in transit. Terminate TLS at a reverse proxy (Caddy does it in two lines — see the password-vault blueprint) before the first real file goes out.
Expiry is the whole point — use it. The reason a client's file is safer with you than on a free tool is that you can make it disappear on a schedule. Set a default expiry so "temporary" shares don't quietly become permanent.
Verified repos
ProjectSend — GPL-2.0, ~1.9k stars, active (July 2026)
Pingvin Share X — BSD-2-Clause, ~260 stars, active (v1.21.0, July 2026) — maintained fork of the now-archived Pingvin Share
Nextcloud — AGPL-3.0, actively developed (2026)
Get the next blueprint as it publishes — free, practical, verified tooling only.
Subscribe · Want this audited or extended for your business? DM @RXed_EU
Get this blueprint tailored to your business — free
Tell us what you run and where. We research your sector's specifics — rules, tools, customer habits — and send you a version of this blueprint rebuilt for your situation, usually within 24 hours.