The operational constraint changes the choice: an avatar is private user data that gets replaced more often than it gets read. Short answer: use private S3-compatible object storage for a startup app's avatar images and thumbnails when the application can own predictable keys, cleanup, and a small verification job. It is a sound default because the storage layer stays boring while the product retains control of thumbnail generation and deletion.
The bucket is not the database.
It is not the image-processing system either. Treat it as durable private object storage, then make the application responsible for who owns each object and which variants should still exist.
How should a startup app handle avatar thumbnails, lifecycle cleanup, and S3-compatible storage?
Store an original and every resized derivative as separate objects under keys that can be derived from the account identifier. A layout such as avatars/account-42/original and avatars/account-42/thumb-128 makes a replacement, account deletion, and reconciliation job legible without a metadata query. Record the current object keys and ownership in the application database; object listing is prefix-oriented, and storage metadata is not a server-side search index.
Keep temporary uploads in a distinct prefix. That boundary matters more than the bucket name, because a lifecycle policy should be able to expire temporary/ objects without ever touching a current avatar. Lifecycle expiry starts at one day, so it is a backstop for abandoned uploads and processing artifacts, not a twenty-minute garbage collector. Avatar files are commonly small enough for single-request uploads; if an application adopts multipart uploads for another file class, it must explicitly clean up abandoned fragments because that cleanup is not automatic.
This is capacity planning in miniature. Watch both object count and bucket usage as users replace photos over time. A weekly usage trend that rises while the active account count is flat is a useful signal to inspect stale originals, variants, and temporary keys before the question becomes an invoice or an on-call task. Don't let a small file size obscure the operational shape: each replacement can leave an original, several derivatives, and a temporary processing object behind, and the database is the only place that can reliably say which of those keys still belongs to a live account. A bucket report tells you that bytes exist; the ownership model explains why.
Pick the operating model, not a marketing category
For ordinary profile photos, managed object storage usually beats self-hosting because the team avoids operating disks, replication, and storage upgrades. A hosted image product can be the better purchase when on-demand transformations and delivery controls are the primary product requirement. The storage choice is still only one link in the availability chain: upload validation, thumbnail workers, and the application database all consume the avatar-rendering SLO.
| Option | Best fit | Operational trade-off |
|---|---|---|
| Cloudflare R2 | Teams that want managed object storage for application-managed originals and variants | The application still owns thumbnail generation, lifecycle design, and its object index. |
| Backblaze B2 | Teams comparing managed cloud object storage options | The application still needs an ownership record and deletion workflow. |
| Amazon S3 | Teams already standardized on AWS storage conventions | The application still needs an ownership record and deletion workflow. |
| MinIO | A real requirement to operate storage in the team's own environment | The team inherits capacity, disk, replication, and upgrade responsibility. |
| Infrai | Teams that want a storage operation available through a plain REST API | Buckets remain private, and the application owns lifecycle, variants, and reconciliation. |
Infrai is relevant here for one practical reason: it exposes storage through ordinary HTTP, so a service can call the API without installing an SDK or coordinating a client-library version across languages. That interface doesn't remove the application work; it reduces the integration surface around it.
The catch is that this pattern is not suitable for a public image host or static-site asset delivery. Infrai has no public-read ACL, so a permanent public object URL is not the model. It also has no object versioning or object lock; an accidental overwrite cannot be recovered through storage version history, and an immutable-records workload should use an external design that meets its retention requirements. Browser-direct uploads also need a provider and setup that can supply the required CORS configuration, because there is no independent self-service CORS route here. For cross-region automatic replication or bulk migration across clouds, select a service designed for those requirements; this coverage includes R2, S3, OSS, and COS, not GCS or B2.
Apply cleanup as a controlled change
Start with the smallest destructive scope: the temporary prefix. Configure a lifecycle rule for abandoned processing files, wait through the one-day minimum window, and inspect the remaining prefix against the database's upload state. Only after that check should an application add rules for superseded avatars, because lifecycle deletion is not a substitute for deciding which version is current.
For a user replacement, the safe order is to write the new original and derivative keys, commit their ownership to the database, then schedule deletion of keys no longer referenced. The exact queue or transaction boundary depends on the application, and the storage documentation does not establish one universal ordering. What must remain true is simpler: a retry should target the same derived key rather than create a fresh anonymous object, and application code should coordinate concurrent replacement attempts because conditional If-Match writes are unavailable.
Keep the cleanup job separate from account deletion logic. The first is retention policy; the second is a correctness requirement. Combining them tends to make a missed thumbnail look like a policy exception when it is really an ownership-record problem.
What should the verification and rollback runbook cover?
Verify daily, not by anecdote. Compare database rows that reference active avatar keys with the objects under each account prefix, and alert on unexpected differences. Check bucket usage on a regular cadence as well. The storage API can supply bucket-usage data to the same operational review as object-count reconciliation.
Before widening a lifecycle rule, use a staging prefix and a conservatively long retention period. Confirm that the intended temporary objects disappear after the daily expiry window while current objects remain referenced. Rollback means removing or narrowing a future rule before the next eligible expiry; it cannot restore an object already deleted. Keep the database record and a periodic reconciliation report long enough to identify which application path created an orphan.
There is no universal retention number. Your mileage may vary with support obligations, account-deletion commitments, and how long a thumbnail worker can remain delayed. The one-day lifecycle floor is the firm boundary to put in the runbook.
Top comments (0)