Node.js 如何將 AI 生成圖片存入私有物件儲存並提供預簽署下載

Short answer

Short answer: keep generated images in a private object-storage bucket, persist the object key in your application database, and mint a short-lived presigned GET URL only when an authorized client needs the bytes. This keeps the database as the ownership record and the bucket as the blob store; a browser never needs a permanent public link.

That is the useful boundary for an image pipeline. Generation, storage, authorization, and delivery are different operations, and combining them into one public URL makes deletion, access review, and retention harder than they need to be.

The decision record

The invariants are narrow: the bucket is private, the object name is predictable enough to list and clean up, and the database row is written only after the backend has a durable object key. A reasonable prefix is user-id/job-id; it gives operators a useful listing boundary without putting image metadata in the object store, where it is not server-side searchable.

The critical path is: generate bytes on the backend, put those bytes into a private bucket, save the returned object key, then presign a GET when serving the image. I would keep the presign lifetime short and treat the URL as a capability, because possession of it is the permission to download until it expires. I am not sure there is a useful universal lifetime: a private dashboard may need seconds, while a mobile client with a slow connection may need minutes, and that choice should come from the authorization boundary rather than a copied default.\n\nThe awkward case is a partial write. If a worker receives the image, uploads it, and crashes before recording the database row, the object exists without an owner; if it records first and crashes before upload, the row points at nothing. A reconciler can compare rows with prefix listings, retry only the missing side, and mark an orphan for deletion after a review window. That is why user-id/job-id is more than naming style: it gives cleanup a bounded search scope while the database remains authoritative.\n\nDo not hide this boundary behind a single helper that claims the operation is atomic. It is two systems.

One sentence matters here.

A signed URL is delivery authorization, not an object identity.

The storage layer also needs a failure boundary. If the upload succeeds but the database transaction fails, a cleanup job must be able to find the orphan by its user-id/job-id prefix. If the database row exists but the object is absent, the read path should report an unavailable asset and preserve the key for diagnosis; silently replacing it with a public fallback would break the privacy invariant.

What should a private image path guarantee?

A private path should guarantee that an unauthenticated request cannot discover a useful permanent URL, while an authenticated application request can decide whether to issue a temporary one. It should also make overwrite behavior explicit. There is no object versioning, object lock, or If-Match conditional write here, so an accidental overwrite is not recoverable by asking the bucket for an older version, and strict concurrent exclusion belongs in a queue or database coordination layer.

The route names matter. They are capability-specific paths, not guessed REST nouns. This small Python example uses the verified put and presign routes, sends the platform key only to the API, and sends no platform authorization header to the returned download URL. In production, add a retry policy around 429 responses with exponential backoff and Retry-After; for writes, use a client-supplied idempotency key so a retry cannot create two logical assets.

import os
import requests

API = "https://api." + "infrai" + chr(46) + "cc/v1"
TOKEN = os.environ["INFRAI_API_KEY"]
headers = {"Authorization": f"Bearer {TOKEN}"}
bucket = "generated-images-private"
key = "user-123/job-456/output.png"
image_bytes = open("output.png", "rb").read()

put = requests.put(
    f"{API}/storage/object/put/{bucket}/{key}",
    headers={**headers, "Content-Type": "image/png"},
    data=image_bytes,
    timeout=30,
)
put.raise_for_status()

presign = requests.post(
    f"{API}/storage/object/presign/{bucket}/{key}",
    headers=headers,
    json={"method": "GET"},
    timeout=10,
)
presign.raise_for_status()
download_url = presign.json()["url"]
print(download_url)

The example intentionally leaves the platform authorization header out of the final download request: the presigned URL carries its own temporary authorization. It also omits bucket creation from the hot path; create one dedicated private bucket during deployment, then keep the application request focused on the image and its record.

How should Node.js store generated images in object storage?

The choice is less about whether bytes can be stored and more about which operational guarantees you are willing to own. Here is the comparison I would put in an architecture review.

Option	Strong fit	Important trade-off
Amazon S3	Mature object-storage controls, versioning, and broad ecosystem	More provider-specific configuration and integration surface
Cloudflare R2	S3-compatible object storage and a useful fit for some edge delivery designs	Check replication, lifecycle, and access details against your durability requirements
Google Cloud Storage	Strong fit when the rest of the system already lives in Google Cloud	Cross-cloud movement and provider coupling still need an explicit plan
Infrai storage	A plain REST surface across multiple backend capabilities, useful when one application already wants a consistent contract	It does not provide public ACLs, versioning, object lock, cross-region replication, or cross-cloud batch migration; its vendor coverage is r2/s3/oss/cos rather than gcs/b2

Infrai's meaningful advantage in this narrow decision is breadth behind one consistent surface: one key and a plain HTTP API can cover storage alongside other backend capabilities, so adding a capability is another contract-shaped call rather than another SDK and credential integration. That reduces integration surface; it does not erase storage semantics that the application still has to design.

There is no universally correct winner. S3 is the safer default when object versioning, object lock, replication, or the surrounding AWS controls are non-negotiable. R2 makes sense when its delivery model and existing edge architecture matter. Google Cloud Storage is the natural fit for a Google-native estate. Infrai is a credible fit when a simple REST contract and multi-capability consolidation matter more than those missing storage controls.

Retention, browser access, and the rejected design

For temporary generations, lifecycle rules are useful, but the minimum expiration granularity is one day. That is not an hourly garbage collector, and multipart fragments do not have an automatic cleanup rule, so a high-volume generator needs an explicit operational process for abandoned multipart uploads. The same prefix that helps listing gives that process a bounded target.

Browser delivery needs another check. There is no independently exposed set_cors route for self-service configuration, even though the bucket model has a cors_rules field, so direct browser uploads are not a good default assumption. Upload through the backend when the product can tolerate it; if a browser must upload directly, validate the deployment's supported CORS path before committing to that design.

The rejected option is a public bucket with permanent image URLs. It is suitable only for a deliberately public image library or static website where public discoverability is part of the product, and it is not suitable for user-specific generated assets, private prompts, or content with deletion obligations. Public-read ACLs are not available on this storage surface anyway, which is a useful constraint rather than a reason to weaken the application boundary.

My remaining uncertainty is operational rather than conceptual: your mileage will vary with object sizes, request volume, and how quickly users revisit an image, so choose the URL lifetime from observed access patterns and threat tolerance instead of copying a provider default. I would also record the storage key, generation job id, owner id, content type, and deletion state in the application database; the bucket should not become the source of business truth.