Why R2 is a strong fit for file hosting
For many self-hosted projects, the web server should control the user experience while object storage handles the large binary files. R2 fits that model well. You keep the application logic, users, packages, and indexing on your own site while the storage backend handles the raw file parts and stored objects.
Multipart uploads matter more than the bucket itself
The real storage win is not only where the file ends up. It is how the file gets there. fyuhls uses multipart direct-to-storage uploads so the client can upload parts directly to the storage provider after the app creates the upload session and signs the required requests.
This keeps PHP out of the full-file relay path and makes resume-aware uploads more practical for large files.
Do not forget bucket CORS
For browser multipart uploads to work correctly with R2, your bucket CORS rules need to allow the right methods and expose the right headers. In the fyuhls documentation and README, the key requirements are allowing PUT, GET, and HEAD, and exposing ETag.
Without that, uploads can fail even when the storage credentials are valid. You also need your site CSP to allow direct uploads to the R2 endpoint.
When to choose R2 over local storage
- When you want the web server and file storage separated.
- When large uploads are important.
- When you expect storage growth that would outpace a small VPS disk.
- When you want a cleaner path to CDN-style delivery later.
Local storage still makes sense for small deployments, testing, or extremely simple setups. The good part is that fyuhls supports both models.