大型電商圖片的預簽名 URL 上載及其取捨

To use presigned URLs for uploading AI-generated images, let your backend authorize a short-lived upload and let the client send the bytes directly to object storage. Large product images never pass through your application server, and the browser or worker never receives a permanent access key.

That is the short answer to using presigned URLs for AI-generated images in Node.js: generate a URL for one bucket and object key, preserve the headers used to sign it, then make an HTTP PUT with the image bytes. The hard part is not the PUT. It is choosing a key scheme, making retries harmless, and accepting the storage features your workload actually needs.

How do I use presigned URLs for uploading AI-generated images?

A presigned URL is a temporary capability. Your backend authenticates the caller and asks the storage service to create a URL scoped to a particular object. The uploader gets permission to perform that operation without getting the bucket credentials.

That is the boundary.

The scope matters. For a product-image pipeline, the key should carry tenant and job identity, such as tenant-42/products/job-781/hero.webp. The worker that creates the image can receive permission for that object; it should not receive permission to list every tenant's objects.

Signing does not make an image private after upload. It also does not solve every concurrency problem. A retry can overwrite the same key unless the application chooses a new key or coordinates writes. There is no If-Match conditional write in the described storage surface, so strict mutual exclusion belongs in a queue or database.

Headers are part of the contract. If the presigned request was generated with Content-Type: image/webp, send that same header on the upload. A mismatch can invalidate the signature or leave downstream consumers with misleading metadata. This is the sort of small edge case that tends to appear only after the first batch of generated images is already in production.

How should the upload flow handle large files?

For a large-file workload, keep the control plane and the data plane separate:

1. The tenant-authenticated backend validates the requested object key and image type.
2. It generates a presigned URL for that exact bucket and key.
3. The Node.js worker uploads the generated bytes directly with PUT.
4. The backend records the object key, tenant, generation job, content type, and upload result in its own database.

The presign operation is POST /v1/storage/object/presign/{bucket}/{key}. The subsequent upload goes to the returned URL, not to your application endpoint. Keep the presigning endpoint behind the normal tenant authorization boundary; a signed URL is powerful precisely because it can be used by whoever obtains it until it expires.

Here is a small control-plane example. It requests a presigned URL from Infrai, using the same HTTP behavior a Node.js worker would implement with Axios or the built-in https module. The URL and headers must come from the presign response; they are deliberately not reconstructed in the client.

import json
import os
import time
from pathlib import Path
from urllib.error import HTTPError
from urllib.request import Request, urlopen


def request_presign(bucket: str, key: str) -> dict:
    endpoint = f"{os.environ['INFRAI_BASE_URL'].rstrip('/')}/storage/object/presign/{bucket}/{key}"
    request = Request(
        endpoint,
        data=b"{}",
        headers={
            "Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}",
            "Content-Type": "application/json",
            "Idempotency-Key": f"image-presign:{bucket}:{key}",
        },
        method="POST",
    )
    for attempt in range(4):
        try:
            with urlopen(request) as response:
                if response.status < 200 or response.status >= 300:
                    raise RuntimeError(f"presign failed with HTTP {response.status}")
                return json.load(response)
        except HTTPError as error:
            if error.code != 429 or attempt == 3:
                detail = error.read().decode("utf-8", errors="replace")
                raise RuntimeError(f"presign failed with HTTP {error.code}: {detail}") from error
            retry_after = error.headers.get("Retry-After")
            time.sleep(float(retry_after) if retry_after else 2 ** attempt)
    raise RuntimeError("presign failed after retries")


def upload_image(presigned_url: str, image_path: str, content_type: str) -> None:
    image_bytes = Path(image_path).read_bytes()
    request = Request(
        presigned_url,
        data=image_bytes,
        headers={"Content-Type": content_type},
        method="PUT",
    )
    with urlopen(request) as response:
        if response.status < 200 or response.status >= 300:
            raise RuntimeError(f"upload failed with HTTP {response.status}")

presign = request_presign("catalog-images", "tenant-42/products/job-781/hero.webp")
upload_image(presign["url"], "hero.webp", "image/webp")

For very large objects, reading the whole file into memory is a poor worker design even though the request shape is correct. Stream the file in the Node.js implementation, cap concurrent uploads, and make the job retry policy explicit. If the image generator can produce a 300 MB asset, measure memory and socket pressure at that size instead of assuming that a small thumbnail test represents production.

Which storage option fits the constraint?

The main comparison is not a feature-count contest. It is about where large-file throughput, tenant isolation, and operational ownership sit in the system.

The last row needs a sober reading. A single credential and billing surface can reduce dashboard and invoice sprawl, and the same workflow gets a consistent REST boundary. That convenience does not replace an object-storage policy review. In particular, the available storage behavior has no public or public-read ACL outcome, no object versioning or object lock, and no independently exposed set_cors route for browser-direct configuration.

For a tenant-scoped export, private objects plus an application-controlled download path may be exactly right. For a static catalog that must serve permanent public URLs, it is the wrong tool. For regulated records that must be immutable, lack of WORM semantics is a decision blocker, not a footnote.

Keep the export private.

What failure cases should the worker own?

Presigned URLs do not remove failure handling; they move the bytes away from your web process. Treat a response outside the 2xx range as a failed upload and preserve the response body in structured job logs. A timeout is ambiguous: the server may have received the object even if the client did not receive the response.

The retry decision deserves more room than the happy path. A 429 should honor Retry-After when it is present, then back off instead of hammering the presign endpoint. A network timeout after the PUT needs a reconciliation step because the object may exist. Query the job database first, and only issue another write when the key policy says an overwrite is safe; otherwise create a new generation key and record it as the authoritative pointer. At 300 MB, that distinction is operationally more important than shaving a round trip from the presign request.

Use a deterministic object key for a generation job only when overwrite is acceptable. Otherwise, put a unique generation identifier in the key and make the database record the authoritative pointer. This is safer than retrying a write blindly when conditional writes are unavailable.

The lifecycle details also matter for throughput planning. The shortest lifecycle expiration is one day, and multipart fragments do not have an automatic cleanup rule. If the design later switches from one-shot uploads to multipart uploads for very large images, add an explicit abort and cleanup process. Do not assume abandoned parts will disappear on their own.

Browser uploads add another boundary: CORS. The browser must be allowed to send the signed request and its required headers, but the storage surface described here does not expose an independent route for setting CORS rules. A server-side worker avoids that browser configuration issue. If direct browser upload is a requirement, verify the bucket configuration and test the actual origin and headers before committing to the architecture.

A measured rollout for tenant exports

Start with one tenant, private keys, and a modest concurrency limit. Record object key, content type, byte count, generation ID, and the final upload status beside the export job. Compare end-to-end throughput against the application-proxy design; the useful metric is completed image bytes per worker hour, not the presign call count.

Then test the awkward cases: a retry after a client timeout, two workers targeting one key, an expired URL, an incorrect Content-Type, and an interrupted large upload. Add cleanup for failed jobs before increasing concurrency. I initially treated presigning as an authentication detail. It is really a write-coordination boundary, and that distinction is what keeps a tenant export from quietly publishing the wrong image.

The decision rule is compact. Choose presigned uploads when the goal is private, tenant-scoped object writes without exposing access keys and the system can coordinate keys and retries. The limitation is equally clear: choose a different storage path, or add external controls, when the product requires permanent public links, WORM retention, conditional mutual exclusion, browser-managed CORS, or cross-region replication.

Sources

• Infrai storage documentation, available through its official documentation site
• Amazon S3 presigned URLs
• Cloudflare R2 presigned URLs
• MinIO presigned operations
• MDN: Cross-Origin Resource Sharing (CORS)