How Breazzy backs up your Android photos
Breazzy reads your phone's photo library, signs each upload with S3 SigV4 using credentials you provide, and PUTs the file directly to your own bucket on Backblaze B2, Cloudflare R2, or Amazon S3. There is no Breazzy server in the middle, no Breazzy account, and no proprietary file format. Originals only; videos included; background sync optional.
The architecture, in one sentence
Your phone is the client; your S3-compatible bucket is the server; Breazzy is the bridge that turns "photo on phone" into "object in bucket". Nothing else exists.
The five things Breazzy actually does
- Reads your photo library via Android's MediaStore through the
photo_managerFlutter plugin. Breazzy never copies your library into its own database — it just keeps a list of which photo IDs have already been uploaded. - Filters by album and rules. You pick which albums to back up. You can restrict uploads to Wi-Fi only, charging only, or always-on. Defaults favour Wi-Fi + charging because that is what most people actually want.
- Signs the request with S3 SigV4. The credentials you paste (access key + secret) never leave the device. They are used to compute an HMAC-SHA256 signature for each upload, the same algorithm awscli, rclone, and Cyberduck use.
- PUTs the object directly to your bucket. Each photo is uploaded as a single S3 PUT request to your provider's endpoint — for example
https://s3.us-west-004.backblazeb2.com/your-bucket/IMG_2026_05_20.jpg. The phone talks to the storage provider directly. Breazzy never sees the bytes. - Records the upload locally. A small SQLite-style record on the device tracks which photo IDs are done. If you swap phones, you re-link the bucket and Breazzy resumes from what is already in the bucket.
Background sync, explained
Once initial backup is done, Breazzy registers a foreground service (using flutter_foreground_task) and a periodic worker (workmanager). When Android tells the app that new photos exist — or every few hours, whichever comes first — Breazzy wakes briefly, uploads anything new, and goes back to sleep. The foreground service shows a small notification while it is working so Android does not kill it; the notification disappears when the queue is empty.
Battery usage is dominated by radio time for the actual upload, not by the app itself. A 5 MB photo over Wi-Fi costs roughly the same battery as opening an Instagram story.
What the files look like in your bucket
Breazzy preserves the original file extension and writes a flat layout by default:
your-bucket/
├── IMG_20260518_142233.jpg
├── IMG_20260518_142234.heic
├── VID_20260519_090114.mp4
└── ...No re-encoding, no thumbnails, no proprietary index file. If you want a folder structure (by year, by album), set it in the app's destination settings. The bucket remains useful with any S3 client.
What it does not do
- No client-side encryption today. If you need at-rest encryption, enable server-side encryption on your bucket — all three providers support SSE-S3 transparently.
- No face recognition, no AI tagging, no shared albums. Breazzy is a backup tool, not a viewer.
- No account creation, no email collection, no analytics. The app never makes a network request to a Breazzy domain because there isn't one.
- No iOS version yet, as of May 2026.
Why direct-to-bucket matters
Most photo backup apps proxy your uploads through their own infrastructure. That has three consequences: they can see your photos, they can lose your photos in an outage, and they have to charge you to cover their bandwidth bill. Direct-to-bucket sidesteps all three. The trade-off is that you configure a bucket once. That is a 5–10 minute task, walked through here: