Ignacio Nelson
ed0d36de25
Updating a server install cost nine artisan invocations plus a PHP-FPM
reload, written out in three places that had already drifted apart. One
of those steps is silently fatal to skip: with opcache.validate_timestamps
off — what production guides recommend and what our own image ships — the
database moves to the new version while every visitor keeps being served
the old code, and artisan reports the new version throughout.
`sudo ./update.sh` is now the whole procedure. It asks whether to check
GitHub, asks whether to download the release and verifies the checksum
published beside it, and asks whether there is a backup — offering to dump
the database when the answer is no. Then it takes the site down, replaces
the files, runs the update, reloads PHP-FPM, restarts the worker and
brings the site back. The application still has no self-updater: nothing
is fetched or applied unless somebody runs this and answers yes.
Underneath it is `php artisan projectsend:update`, which is everything an
update does that needs no root — and now the only definition of it. Both
container entrypoints call it instead of carrying their own copy of the
sequence, so the two paths cannot drift again.
Three findings worth keeping in the record, all from rehearsing rather
than reasoning:
- queue:restart has to come last. It writes its signal into the cache,
so clearing the cache afterwards deletes it and the worker runs old
code forever.
- optimize:clear is not safe to recommend. It runs cache:clear, which
on Redis is FLUSHDB — harmless on the default two-database layout,
but on a single-database Redis it takes the sessions and the queue
with it. The compiled caches are cleared individually instead.
- update.sh overwrites itself mid-run, because the zip contains it and
bash reads its own script lazily by byte offset. It re-execs from a
temporary copy before touching anything.
And when the reload is skipped anyway, the application now says so:
projectsend:update records the version it applied, and any staff page
compares that with what the running process actually compiled. The same
check catches the mirror image — new files in place, update never run.
Rehearsed end to end against real installs: a container upgrade (69 to 73
migrations, key and data intact, healthy), a scripted update on a real
nginx + php-fpm install with OPcache pinned (web process moved 2.1.0 to
2.1.1), the skipped-reload case (banner appears naming both versions, and
clears on reload), the refusals (downgrade, non-release zip, truncated
zip, URL passed to --zip, non-root), a database taken down mid-update
(site comes back out of maintenance mode by itself), and a real download
of the published 2.0.0 zip with its checksum verified.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
ProjectSend
Share files with your clients, from your own server.
ProjectSend is a self-hosted application for getting files to the people you work with. 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.
No public link passed around by email, no third-party service holding your clients' documents, no per-seat pricing. It runs on your server, and the files stay there.
What it does
For the people you send to
- A private area per client, showing only what has been shared with them
- Sign in with an email address, with optional two-factor authentication
- Search, filter and sort their files; download one, several as a zip, or a whole folder
- Optional comments on a file, so questions live next to the thing they are about
- Email notifications when something new arrives, in their own language
For you
- Resumable uploads that survive a dropped connection, so large files actually arrive
- Organise with folders, categories and client groups
- Share with one client, a whole group, or publicly — and set an expiry date or a download limit
- Thumbnails and previews for images and documents
- Storage quotas per client, and custom fields for the details you need to keep on them
- A full activity log and download history: who got what, and when
For the installation
- Roles and permissions for your own team, so an uploader is not an administrator
- Sign-in the way you already work: LDAP, social sign-in, or plain email and password
- Themes for the client-facing pages and for outgoing email
- 16 languages
- A REST API with scoped tokens and generated OpenAPI docs
- Privacy controls, including GDPR-grade account erasure with a grace period
- Local disk or S3-compatible storage
Screenshots
The dashboard — what is in the installation, and what has been happening in it.
Your library — folders, categories, and who each file is shared with.
What your client sees — only their files, nothing else.
Getting started
With Docker — the quickest path, and the one we recommend.
git clone https://github.com/projectsend/projectsend.git
cd projectsend
cp .env.example .env # set PROJECTSEND_EDITION=community
docker compose up -d
The app is at http://localhost:8090, and the first thing it shows you is a setup screen that
creates your administrator account.
Before you put real files in it, read DOCKER.md — where your database and uploads actually live, how to move them onto paths you chose, and how to back them up so an upgrade can't take them with it.
Without Docker — for servers where it isn't an option, install from a release zip.
INSTALL.md covers requirements, .env, nginx, the background worker and cron,
updating and troubleshooting. You do not need Composer or npm on the server; the zip ships ready to
run.
Already running it? UPDATE.md is how you move to a new version — one command on Docker, a short sequence on your own server, and what to check afterwards either way.
Coming from ProjectSend Legacy?
The previous generation of ProjectSend lives on at projectsend/legacy. This is a rebuild rather than an upgrade, so moving across is an import rather than an update — install fresh, then bring your old site into it with the migration tool: accounts, clients, groups, categories, folders, files and history.
It never writes to your old install, and any run can be undone with a single command. MIGRATING-FROM-V1.md explains what comes across, the two routes (same machine, or a portable export from a server you can't reach), and the one change your clients will notice: they sign in with their email address now, using the same password.
Contributing
Bug reports, translations and pull requests are all welcome — see CONTRIBUTING.md for how to set up a development copy, what the checks are, and the contributor agreement.
Found a security issue? Please report it privately through GitHub's security advisories rather than opening a public issue.
License
Free software under the GNU General Public License v2, or (at your option) any later version — see LICENSE. Use it, study it, change it, share it.
Commercial licenses are available for organizations that cannot work under copyleft terms; LICENSING.md explains both options. Contributions require signing a CLA, for reasons set out in CONTRIBUTING.md.