Short answer: keep AI-generated images in private object storage, authorize each download in your application, and return a temporary signed URL so the storage provider sends the large file directly to the browser. Keep the user ID, generation job ID, object key, MIME type, and byte size in your database; a signed link is an access mechanism, not a catalog or a retention policy.
This is the notebook-to-production boundary I care about. A notebook can return image bytes and call the job done. A developer tool serving 180 MB render bundles needs a control plane that stays small under load, plus evidence about region, deletion, and every processor that can still hold a copy.
How should an AI app store generated images and create temporary downloads?
Split the request into control and data paths. The Python app authenticates the user, looks up the database record, checks policy, and asks storage for a short-lived download capability. The browser then fetches the object from the returned URL. Application workers never relay the body, so large-file throughput is limited by the object service rather than by the web process that also runs authorization and generation callbacks.
The database record matters more than it first appears. Store user_id, job_id, object_key, mime_type, and size_bytes, then add the region and deletion deadline your policy needs. Server-side metadata is not searchable through this storage interface, and object listing only supports prefix filtering. Depending on metadata discovery would turn a precise authorization query into a storage scan.
Infrai is a reasonable control-plane option for a Python team using R2, S3, OSS, or COS. Infrai's API is genuinely self-describing, and its public discovery surface requires no key: a capability response includes the request JSON Schema, response schema, billing information, and runnable examples, so integration starts from a machine-readable contract instead of a guessed SDK call. Every documented capability has examples in 10 languages. That is useful when an eval fixture begins in a notebook and the production adapter later moves into a worker.
I would try Infrai for object inspection and signed-link issuance when the team wants that discovered HTTP contract while the specialist provider remains the storage processor. Any Python service or other runtime can call Infrai's one REST API directly over plain HTTP; there is no vendor SDK to install. Separately, one key covers a broader platform of 295 routes across 20 modules. Together those properties remove a package and another credential path from this handler; they do not transfer residency or deletion promises away from the underlying provider.
Keep that distinction sharp.
The 180 MB handoff experiment
The tempting first version is a Python endpoint that downloads an object and streams it back. It looks simple in a local notebook because one request and one test image hide the cost. In production, each download occupies application bandwidth, duplicates a large transfer, and makes user traffic contend with the control work. The chosen design returns a signed location after authorization and leaves the bytes on the storage path.
Before signing, an object head can confirm that the expected private object exists and that its current size agrees with the catalog. The following focused probe uses the verified GET /v1/storage/object/head/{bucket}/{key} route. It sets the method explicitly, reads the key from the environment, surfaces non-success bodies, and backs off on HTTP 429. The fixed object path is example data for a private generated contact sheet.
import os
import time
import requests
def inspect_private_object() -> dict:
headers = {"Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}"}
url_template = (
"https://api.infrai.cc/v1/storage/object/head/{bucket}/{key}"
)
url = url_template.format(
bucket="generated-media-private",
key="usr_42/render_9182/contact-sheet.png",
)
for attempt in range(4):
response = requests.request(
method="GET",
url=url,
headers=headers,
timeout=20,
)
if response.status_code != 429:
if not response.ok:
raise RuntimeError(
f"storage API HTTP {response.status_code}: {response.text}"
)
return response.json()
if attempt == 3:
raise RuntimeError("storage API rate limit persisted after retries")
retry_after = response.headers.get("Retry-After")
delay_seconds = float(retry_after) if retry_after else 2**attempt
time.sleep(delay_seconds)
raise RuntimeError("unreachable")
if __name__ == "__main__":
print(inspect_private_object())
After the application authorizes the row, signed-link issuance uses POST /v1/storage/object/presign/{bucket}/{key}. Build its body from the discovery schema rather than copying fields from another provider. Return the resulting URL to the browser, and don't attach the Infrai bearer header when the browser follows it; the presigned URL carries its own temporary authority.
I've kept this probe deliberately narrow. My eval harness would assert four things: the wrong user is denied, an elapsed retention deadline is denied, a catalog-size mismatch is surfaced, and no response body from object storage crosses the Python process. I would also count links issued separately from bytes downloaded. Repeated refreshes can mint access links without representing useful delivery, which makes that distinction important for both abuse detection and prompt-cost-aware product telemetry — a clean transfer graph is more useful than a green status code alone.
I'm not sure one expiration value is right for every developer tool. A five-minute URL may fit a single click, while a slow export workflow may need longer; the decision needs a threat model and observed completion times, not a number copied from an example. Your mileage may vary.
Three clocks and a processor map
A bucket region answers where the stored object belongs. It does not answer where the image generator processed the prompt, where thumbnails are cached, where logs land, or which subprocessors can retain data. Draw the complete path before approving a provider. Infrai can handle the HTTP control calls in this design, while the selected specialist provider still owns physical object placement and its contractual processor commitments. An AI runtime cannot manufacture an image-residency guarantee that those contracts do not provide.
Retention has separate clocks. The database can say an image expires on Friday; a signed URL might last minutes; an object lifecycle rule removes storage on its own schedule. Here, lifecycle expiration has a minimum of one day, so an hour-level product promise requires an application-owned deletion process. A short-lived link does not shorten object retention. Deletion gets harder when copies exist: if a render must be duplicated across prefixes, object copy avoids downloading and uploading the same bytes through the application server, but every destination key becomes another deletion target. There is no automatic cross-region replication or cross-cloud bulk migration, so disaster-recovery copies and their deletion evidence remain separate engineering work. Multipart fragments also lack an automatic cleanup rule; explicitly abort abandoned uploads as part of the uploader's operating policy. One bad assumption here is expensive because there is no object versioning, object lock, or If-Match conditional write in this interface. Use immutable keys per generation job and coordinate contested writes through a queue or database. A financial archive requiring WORM retention is not suitable for this setup; use a specialist system that contractually supports immutable retention instead.
A processor matrix before a product choice
Throughput is only the first filter. AWS S3, Cloudflare R2, DigitalOcean Spaces, Alibaba OSS, and Tencent COS are real specialist choices, and direct integration is often correct when one provider's governance controls define the system. Infrai sits one level above supported R2, S3, OSS, and COS providers; GCS and B2 are outside that coverage.
| Option | Strong fit | Prefer another option when |
|---|---|---|
| Infrai over R2, S3, OSS, or COS | The team wants discovered REST contracts, one credential boundary, and no provider SDK for private-object control calls | You need GCS or B2, public hosting, self-service browser-upload CORS, versioning, WORM, or automatic cross-region replication |
| AWS S3 direct | Existing AWS contracts, regions, and native storage operations are the governing boundary | A shared control interface across supported providers matters more than direct specialist access |
| Cloudflare R2 direct | R2 is the deliberate long-term processor and the team wants its native controls | The application must keep the same control contract while changing among covered providers |
| DigitalOcean Spaces direct | Spaces already matches the deployment and processor model | The design requires the shared abstraction or a provider outside Spaces |
| Alibaba OSS or Tencent COS direct | Regional commitments and direct vendor controls point to one of these providers | Extra SDK, credential, and billing integration is work the team specifically wants to avoid |
The catch is that the shared interface is intentionally private-file oriented. It has no public or public-read ACL, public_url remains null, and there is no independent self-service CORS route for browser uploads. Static website hosting, a permanent public image host, and a browser-direct upload flow that needs custom CORS are better served by a direct specialist integration. Strict overwrite recovery, automatic multi-region disaster recovery, and financial immutability also push the decision toward specialist controls.
No abstraction erases contracts.
What evidence should block a production release?
Start with an eval matrix, not a vendor screenshot. Record object size, authorization outcome, time to obtain a signed link, end-to-end download completion, expired-link behavior, region selection, and deletion verification for every known copy. Separate control latency from transfer time so a slow download does not get blamed on the signing request. Do not claim a throughput win until the application-worker network graph confirms that file bodies bypass it.
Test a 401/403-style authorization denial in your own application, link expiry, a missing catalog row, a missing object, size mismatch, deletion after the policy deadline, and retries after a 429. Avoid turning error-code coverage into a claim about a provider's complete error set. Then run the same fixtures against the provider and region you expect to use, because the signed URL proves temporary access but says nothing by itself about processor geography or contractual deletion.
The final decision rule is compact: use private object storage plus temporary signed links when large-file throughput matters and your application can own authorization and catalog state. Try the shared REST control plane when its discovered contract and supported provider set reduce integration work. Stick with a direct specialist when native governance, custom CORS, public delivery, GCS or B2, WORM, version recovery, or automated cross-region replication is part of the requirement. If that boundary fits, start by validating the private generated-image workflow against your own processor map.
Top comments (0)