denkfabrik-li 7045da7450 Leave the test workflow one concurrency block, so it parses again
c05927c1 added a `concurrency:` block on the premise that the suite never
got one. It already had one, four lines above -- the hunk header of that
diff reads `@@ -50,6 +50,23 @@ concurrency:`, which is the existing block
it was appended below.

A YAML mapping cannot carry the same key twice, so the file has not
loaded since. GitHub still creates a run and then schedules nothing:

  553f5fd2  (last green)  run 33036453748  jobs=1  ci -> success
  d58e4830  (main)        run 33114046849  jobs=0  failure

Every run since has that shape, and the run list names it in passing:
those runs appear as `.github/workflows/tests.yml` where the green ones
appear as `tests`, because the `name:` key sits inside the file that did
not parse. `linter` is unaffected -- it carries one block -- which is why
351da21e shows a green linter beside a failed tests run, and the tree
reads as half-checked rather than unchecked.

Reproduced with a parser rather than inferred from the job count:

  before -> THREW: Duplicate key "concurrency" detected at line 66.
  after  -> parsed ok, top-level keys: name,on,concurrency,jobs

Kept the second block, verbatim, because it is the one c05927c1 meant to
end up with and its comment carries the reasoning -- including the
tradeoff that an intermediate commit on `main` can end up with no run of
its own. The two group keys are interchangeable: `github.workflow` is
constant within a workflow, so `tests-${{ github.workflow }}-${{ github.ref }}`
and `tests-${{ github.ref }}` produce the same grouping. Worth knowing
that lint.yml still uses the first shape, if you would rather the two
files read alike.

No test. The failure is loud on the next push, and a test that parses a
workflow file would be a second place to keep the same rule.
2026-08-27 23:53:37 +02:00
2026-08-14 01:38:12 -03:00
2026-08-14 01:38:12 -03:00
2026-08-14 01:38:12 -03:00
2026-08-14 01:38:12 -03:00
2026-08-14 01:38:12 -03:00
2026-08-14 01:38:12 -03:00
2026-08-14 01:38:12 -03:00
2026-08-14 01:38:12 -03:00
2026-08-14 01:38:12 -03:00
2026-08-14 01:38:12 -03:00
2026-08-14 01:38:12 -03:00
2026-08-14 01:38:12 -03:00
2026-08-14 01:38:12 -03:00
2026-08-14 01:38:12 -03:00
2026-08-14 01:38:12 -03:00
2026-08-14 01:38:12 -03:00
2026-08-14 01:38:12 -03:00
2026-08-18 17:35:18 -03:00
2026-08-14 01:38:12 -03:00

ProjectSend

Share files with your clients, from your own server.

License: GPL v2 or later PHP 8.4+ Self-hosted


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, S3-compatible storage, or Google Cloud Storage

Screenshots

The dashboard: counters for files, clients and groups, the clients using the most storage against their quotas, a month of uploads and downloads as a line chart, and recent activity

The dashboard — what is in the installation, and what has been happening in it.

The file library, showing folders and files with thumbnails, sharing status and download counts

Your library — folders, categories, and who each file is shared with.

A client's own page, listing the files shared with them with download buttons

What your client sees — only their files, nothing else.

Getting started

With Docker — the quickest path, and the one we recommend. Nothing to build: the published image ships with its dependencies and its frontend already compiled.

curl -O https://raw.githubusercontent.com/projectsend/projectsend/main/docker/production/compose.example.yaml
# edit the passwords and APP_URL in it, then:
docker compose -f compose.example.yaml up -d

Open APP_URL and the first thing you see is a setup screen that creates your administrator account — or uncomment ADMIN_EMAIL and ADMIN_PASSWORD in the file first, with a password of your own, and it is created for you.

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, one script on your own server, and what to check afterwards either way.

Want to work on ProjectSend itself? Cloning the repository gets you a development copy, not an installation: the dependencies and the compiled frontend are deliberately not in git, so a clone needs Composer and npm before it runs. CONTRIBUTING.md has the sequence, and it is short.

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.

S
Description
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.
Readme GPL-2.0 66 MiB
Languages
PHP 74.8%
TypeScript 24%
Shell 0.7%
Dockerfile 0.2%
CSS 0.2%