From f7db586c7e909e0cc6de8caebd8478bdf415c853 Mon Sep 17 00:00:00 2001 From: ignacionelson Date: Mon, 24 Aug 2026 19:40:58 -0300 Subject: [PATCH] Say that files can live in Google Cloud Storage too MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Three lines still told readers S3 was the only option, which stopped being true and is the sort of thing somebody chooses a different product over. The install guide's storage section now says what each backend is for, that Test connection exists and is worth using before switching uploads over, and — the part people actually get wrong — that choosing a backend applies to new uploads and moves nothing that is already stored. --- INSTALL.md | 18 +++++++++++++++--- README.md | 2 +- 2 files changed, 16 insertions(+), 4 deletions(-) diff --git a/INSTALL.md b/INSTALL.md index 821f49f0..2d67ee96 100644 --- a/INSTALL.md +++ b/INSTALL.md @@ -84,7 +84,7 @@ Two ways out, if nginx really is impossible on your hosting: rather than as a misconfiguration. This applies to any proxy in front of ProjectSend, not just this one: Nginx Proxy Manager, Traefik and a hand-written nginx vhost all ship the same default. ([#1664](https://github.com/projectsend/projectsend/issues/1664)) -- Store your files in S3-compatible object storage instead (see +- Store your files in object storage instead — S3-compatible or Google Cloud Storage (see [Storing files somewhere other than this server](#storing-files-somewhere-other-than-this-server)). Files kept there are never on your server's disk, so downloads become a signed, expiring redirect to the storage provider and the web server is not involved at all. This is a genuine, supported @@ -447,8 +447,20 @@ the worker afterwards. ### Storing files somewhere other than this server Out of the box, uploads live in `storage/app/files/` on this machine. You can point ProjectSend at -S3-compatible object storage instead from **System → Settings → Storage** — useful when the files -outgrow the server's disk. +object storage instead from **System → Settings → Storage** — useful when the files outgrow the +server's disk. + +Two backends are offered. **S3-compatible** covers AWS S3 and everything speaking that API: MinIO, +Backblaze B2, Wasabi, DigitalOcean Spaces. Leave the endpoint blank for AWS itself, or set it to the +service's own address and turn on path-style addressing, which most of them need. **Google Cloud +Storage** takes a service account key with read and write access to the bucket, pasted in as the JSON +file Google issues; it is stored encrypted and never shown again. + +Whichever you choose, use **Test connection** before switching uploads over — it checks the +credentials actually reach the bucket, rather than leaving you to find out at the first upload. + +The setting applies to new uploads. Files already on local disk stay there and keep working, and +there is no migration between backends. ### Making it faster diff --git a/README.md b/README.md index fc96d138..057e749c 100644 --- a/README.md +++ b/README.md @@ -47,7 +47,7 @@ per-seat pricing. It runs on your server, and the files stay there. - 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 +- Local disk, S3-compatible storage, or Google Cloud Storage ## Screenshots