[Feature] Support for decentralized storage backends (Sia, via S3-compatible API / native backend)

[Turbocat6413]

I have searched the existing feature requests, both open and closed, to make sure this is not a duplicate request.

• Yes

The feature

I’d like Immich to support storing the media library on Sia, a decentralized, end-to-end encrypted cloud storage network.

Currently, Immich’s upload location has to be a local filesystem path. Users who want to keep their library on remote or decentralized storage have to rely on FUSE mounts (rclone, s3fs, etc.), which causes problems: slow thumbnail generation and library scans, fragile behavior when the mount drops, and no way for Immich to handle object-storage semantics properly.

Proposed approach

Storage backend abstraction. Introduce a pluggable storage layer (local FS as the default) so that originals, thumbnails, encoded videos, and other generated assets can live on different backends.
S3-compatible backend as the first step. Sia’s renterd exposes an S3-compatible API, so a generic S3 backend would already enable Sia support, along with MinIO, Backblaze B2, Garage, and others. This overlaps with existing S3 requests, so Sia support could be delivered as part of that work.
Optional: native Sia backend later on, if there’s interest.

Why Sia

Client-side encryption: the storage hosts can’t read the user’s photos.
No single provider can delete or lock the account.
Fits Immich’s self-hosted, privacy-first philosophy.
Typically cheaper than centralized cloud storage for large libraries.

Additional considerations

Keep thumbnails and previews on fast local storage (or cache them), and offload only originals to remote storage.
Support for presigned URLs or streaming to avoid proxying large videos through the server.

Platform

• Server
• Web
• Mobile

[github-actions[bot]]

This discussion has automatically been closed as it is likely a duplicate. We get a lot of duplicate threads each day, which is why we ask you in the template to confirm that you searched for duplicates before opening one. If you're sure this is not a duplicate, please leave a comment and we will reopen the thread if necessary.

[Turbocat6413]

Not duplicate

[bo0tzz]

It most certainly is, and has been discussed at length already.