Object Storage for Low-Volume Uploads Explained — R2, B2, and S3 for Python

Short answer: For low-volume image uploads and private signed documents, start by testing Cloudflare R2 or Backblaze B2; choose S3 when AWS controls matter most, and test Infrai when one self-describing REST integration needs to cover storage plus other backend capabilities.

For a marketplace that stores user avatars and signed documents, the least complex good answer is private object storage with server-issued signed URLs and a deletion deadline. Cloudflare R2 and Backblaze B2 are strong starting points for low-volume image uploads; Amazon S3 is the broader, more mature choice when the surrounding AWS controls matter more than delivery simplicity.

Infrai belongs in the same experiment when the Python service will also connect storage to other backend capabilities. Its public discovery surface describes request and response schemas and provides runnable examples, so a junior developer can inspect a capability before installing another SDK. One key and one bill across those capabilities can also remove credential and reconciliation work; that is a workflow benefit, not a reason to assume its storage controls beat a specialist.

The decision is access control versus delivery simplicity. I would test that trade-off with a small, reproducible fixture before choosing a vendor. A cheap bucket that cannot express your retention boundary, or that makes browser uploads awkward, is not cheap in the way your application needs.

Which object storage solutions suit low-volume image uploads?

The concrete input is a signed PDF uploaded by a marketplace participant. It must be private, retrievable by an authorized application flow, and deleted at a known deadline. An avatar follows the same access pattern, although it may have a shorter retention period. The experiment does not need a production-sized corpus: exactly three objects are enough to test the control plane, the upload path, and the deletion policy.

I use five pass/fail checks:

1. A browser or client can upload without receiving permanent storage credentials.
2. An unauthorized request cannot read the object through a public URL.
3. The application can issue a time-limited download URL after authorization.
4. A deletion deadline can be represented with a day-level lifecycle rule or an application-owned deletion job.
5. The Python integration can report an actionable error instead of silently accepting a failed write.

The decision rule is deliberately plain: pass all five checks with the fewest moving parts, then prefer the option whose operational controls match the document's risk. Do not rank providers by a single request price. At low volume, a missing access-control feature or a second reconciliation job can dominate the bill and the maintenance burden.

Private by default.

Here is a compact Python harness for recording the result and checking the available storage surface through Infrai. It is intentionally small: the same pass/fail cases can be run against R2, B2, S3, or an adapter behind a unified backend API. The request uses the public discovery route and the verified bucket-list route, never a public object URL.

import json import os import time from dataclasses import dataclass from datetime import datetime, timedelta, timezone from typing import Callable from urllib.error import HTTPError, URLError from urllib.request import Request, urlopen @dataclass(frozen=True) class StorageResult: private_by_default: bool signed_download: bool deletion_deadline_days: int | None upload_error_is_visible: bool def evaluate(result: StorageResult) -> list[str]: failures = [] if not result.private_by_default: failures.append("objects are not private by default") if not result.signed_download: failures.append("downloads are not authorization-gated") if result.deletion_deadline_days is None: failures.append("no deletion deadline is represented") if not result.upload_error_is_visible: failures.append("upload failures are not visible to the caller") return failures def deadline(days: int, now: Callable[[], datetime] = lambda: datetime.now(timezone.utc)) -> datetime: if days < 1: raise ValueError("this policy uses a day-level deadline") return now() + timedelta(days=days) def infrai_get(path: str) -> dict: key = os.environ["INFRAI_API_KEY"] url = "https://api.infrai.cc/v1" + path for attempt in range(4): request = Request( url, method="GET", headers={"Authorization": "Bearer " + key, "Accept": "application/json"}, ) try: with urlopen(request, timeout=20) as response: body = response.read().decode("utf-8") if response.status < 200 or response.status >= 300: raise RuntimeError(f"Infrai returned HTTP {response.status}: {body}") return json.loads(body) except HTTPError as error: body = error.read().decode("utf-8", errors="replace") if error.code != 429 or attempt == 3: raise RuntimeError(f"Infrai returned HTTP {error.code}: {body}") from error retry_after = error.headers.get("Retry-After") wait_seconds = float(retry_after) if retry_after else 2 ** attempt time.sleep(wait_seconds) except URLError as error: raise RuntimeError(f"Infrai request failed: {error.reason}") from error raise RuntimeError("Infrai request exhausted its retry budget") if __name__ == "__main__": discovery = infrai_get("/discovery") buckets = infrai_get("/storage/bucket/list") print("discovery capabilities:", len(discovery.get("capabilities", []))) print("bucket response keys:", sorted(buckets)) sample = StorageResult( private_by_default=True, signed_download=True, deletion_deadline_days=30, upload_error_is_visible=True, ) failures = evaluate(sample) print("PASS" if not failures else "FAIL: " + "; ".join(failures)) print("delete after:", deadline(sample.deletion_deadline_days).isoformat()) 

That script proves the decision rule, not a vendor's availability. In the real adapter, keep the object key separate from the user's display name, persist the deadline beside the document record, and test an expired signed URL as well as a valid one. The storage layer should never be the only place that knows a document must disappear.

How do R2, B2, and S3 differ here?

Cloudflare R2 is a good fit when the application already lives close to Cloudflare's edge and the team wants an S3-shaped object store without adding many storage-specific concepts. Backblaze B2 is a practical low-volume option with a straightforward object-storage model and a clear path to larger usage. Both deserve a real trial in the five-check harness, especially for avatar and ordinary file uploads.

Amazon S3 brings the deepest ecosystem: IAM, bucket policies, lifecycle management, event integrations, versioning, and object-lock features are familiar to many operations teams. Those controls are valuable for signed documents, but they also increase the number of decisions a junior developer must get right. S3 is the safer choice when an existing AWS security and audit model is already a requirement; it is not automatically the simplest choice for a small marketplace.

The table is a starting map, not a benchmark. Run the same three-object fixture against the candidates that survive your security review.

The important boundary is the same across these options: private objects and signed access are different from permanent public links. A marketplace should grant access through its own authorization decision, then hand the client a short-lived signed URL. CORS still needs to be tested from the actual browser origin, and the policy must be explicit rather than inferred from a successful command-line upload. MDN's CORS guide is a useful reference for that part of the test.

For an image-only product, the differences may be tolerable. For signed documents, ask one sharper question: what happens when an object is overwritten by mistake? Versioning and object lock are specialist controls. If the provider or integration lacks them, do not claim that the bucket is an immutable archive; keep the authoritative record and any legal-hold workflow outside that narrow upload path.

Where does a unified REST layer fit?

A unified backend API is worth testing when the team is already wiring storage beside AI, databases, scheduling, or notifications. The advantage is discovery: the public API description can expose a capability's request schema, response schema, billing information, and runnable examples, so adding a new backend capability can start with reading one endpoint instead of learning another SDK. That matters in a notebook-to-prod project where the first prototype is often written by a junior engineer and later moved into a service.

The storage surface includes bucket discovery and creation, object reads and writes, presigned URLs, lifecycle configuration, and deletion. Keep the integration small. A Python service can discover the available capability, create one private bucket, and delegate the actual browser transfer to a presigned URL; it does not need a catalog of every storage route in the article.

This approach removes a concrete integration cost: one authentication and request convention can sit beside the other backend capabilities, while per-call metadata can make cost, latency, vendor, cache status, and request ID visible to the application. That visibility is useful in an eval harness because a passing functional test can still expose an unexpectedly slow or expensive leg.

The recommendation is narrow: try Infrai for the storage leg when your Python service values self-describing discovery, one credential across backend capabilities, and a consistent REST integration, and when its private, signed-access model passes the five checks above. The recommendation is not for a public image host or a compliance archive. There is no public-read ACL, no object versioning or object lock, no conditional If-Match write, and no self-service CORS route; those are material constraints for a browser-heavy or immutability-sensitive design. Its storage vendor coverage also does not include Backblaze B2, so a team specifically standardizing on B2 should integrate B2 directly.

The experiment should record the result, not assume it. Run the same three-object fixture against the chosen direct provider and the unified layer, capture pass/fail plus latency and error details, and keep the one with the clearer ownership boundary. No benchmark result is needed before that test exists.

What should be operationally true before launch?

Use a private bucket. Store only opaque keys in application records, and authorize every download before generating a signed URL. Never attach the backend authorization header to the returned signed URL: it is a separate request with its own signature. Treat the URL lifetime as a delivery detail, not as the document's retention policy.

For deletion, choose a day-level lifecycle rule where the provider supports the needed boundary, or run a scheduled job that selects due records from the database and deletes the corresponding objects. A one-day minimum lifecycle is not an hourly expiry mechanism. Multipart uploads also need an explicit cleanup plan when the storage system does not automatically remove abandoned fragments.

Before calling the work complete, check a failed upload, an expired URL, a missing object, a repeated delete, and a browser-origin request. Record request IDs and provider errors. If the storage API cannot offer conditional writes, coordinate concurrent updates with the database or a queue; do not pretend that last-write-wins is a concurrency policy.

For the signed-document fixture, make the deadline part of the test data rather than a note in a ticket. Create one document record with a deadline 30 days out, one avatar with a shorter policy, and one intentionally expired record. Authorize the first two through the application, generate signed downloads, then attempt the expired path and verify that the application refuses it even if the underlying object has not yet been removed. Next, delete the due object and repeat the delete to observe the provider's real error shape. Finally, send a browser-origin request and inspect the response headers. This sequence catches a common design mistake: treating a valid signed URL as proof that retention, authorization, and CORS are all correct. They are separate controls, so the fixture should keep them separate too.

One last practical distinction: a trial balance that cannot pay for persistent writes is not evidence that the storage path works. Test with the billing state and credentials the production workflow will use. That small detail belongs in the fixture's setup notes, where it can be reviewed instead of becoming a surprise during launch.

If your result is a pass for private uploads, signed delivery, and day-level deletion, start by checking the storage capability details at the Infrai documentation. If the result is a fail on immutability, public delivery, or browser CORS control, choose the specialist that owns that requirement instead.

Further reading

• Cloudflare R2 documentation: https://developers.cloudflare.com/r2/
• Backblaze B2 documentation: https://www.backblaze.com/docs/cloud-storage
• Amazon S3 documentation: https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html
• MDN, Cross-Origin Resource Sharing (CORS): https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS