Object storage: COS, OSS, S3
Object storage is for people who will not carry a disk but still refuse to hand originals to a photo company. The in-app declarations page is blunt: there is no Azalea server; you pick the store.
What the form actually persists
Display name is yours. Provider is chosen at the entry point and is read-only in the form. Bucket, endpoint, region, root, access key, secret key. Changes debounce then upsert. Secrets go in the iOS Keychain or Android EncryptedSharedPreferences, not a world-readable prefs file.
S3-compatible gateways work if list/put behave. Do not store a short-lived session token as if it were a long-lived key unless you know the expiry.
English-language setups we actually ran in April 2026 used S3 Standard in us-west-2, not COS. The client does not care which vendor, only the signature and the key layout.
Index shape
index/{deviceId}/manifest.json plus index.sqlite. Object keys match iOS, so a second client pointed at the same bucket can claim it. Android maps one MediaStore row to one resource and cannot reuse iOS local_identifier values. After a claim, matching is by content, not a 1:1 recreation of the old Moments album.
Cost gut check
On 8 Mar 2026 list prices, 214.7 GB on S3 Standard was about $59 / year. PUT volume for tens of thousands of stills is real but usually below storage. If the invoice is the fear, a USB disk is the other column in the cost case.
First things to check on failure
- Wrong region shows up on the first list as a signature error or a 301.
- A sub-user with GET but no PUT dies on the first photo.
- If the OS kills the background task, progress is not lost; unfinished keys remain in the index. Opening the app continues.