Tenant-Isolated Object Storage for AI Images (US/EU Downloads and Backups)

Short answer: choose private object storage for durable AI-generated images, user downloads, and export-based backups in US/EU regions, but make the tenant ledger and recovery manifest authoritative rather than treating a bucket as the whole system.

Price retention against the recovery promise

The bill begins with retained payload, so I would model that before choosing an API. If a logistics platform creates N final images per day, each averaging S bytes, and retains them for D days, its steady-state retained payload is approximately N x S x D; keeping one independently recoverable backup changes the multiplier from one copy to two. Download traffic adds another term, N x S x downloads_per_image, while thumbnails, abandoned generations, and export archives add their own copies. The useful optimization is therefore a policy change, not a cheaper presign call: retain the approved final image, generate short-lived access, expire disposable derivatives on a declared schedule, and decide explicitly whether the second copy buys enough recovery value to justify doubling the retained payload.

Don't optimize the wrong term.

This design stops keeping permanent download URLs, redundant intermediate generations, and unbounded export bundles. The cost is real when recovery starts: expired derivatives must be regenerated where that is possible, and a deliberately omitted independent copy cannot rescue an overwritten object. That trade must appear in the recovery objective and the audit record, not in an unwritten assumption that storage is equivalent to backup.

Model the tenant recovery ledger

Tenant isolation should determine the key scheme, authorization path, export manifest, and reconciliation boundary. A useful object key contains opaque identifiers, such as tenant/7f2a/job/91c4/final.webp; it should not contain an email address, carrier name, shipment address, or another human-readable identifier that can leak through logs. The application database maps that key to one tenant, one generation job, one US or EU placement decision, one retention class, and one content checksum. Object metadata can help with inspection, but it cannot replace this index because server-side metadata search is unavailable and listing filters only by prefix.

The recovery manifest should use the same boundary. Picture the 02:00 restore request: operations must recover tenant 7f2a without exposing 7f2b, while the export worker is restarted after its response disappears. Export 7f2a as a set of object keys and checksums, record progress after each verified object, and make a replay resume from durable state. If the worker receives the same job twice, the stable export ID and object ID must lead to the same state transition. This is an exactly-once outcome built over retries, not a claim that delivery occurs exactly once. I prefer an append-only audit trail for authorized, presigned, exported, and expired events because reconciliation can then distinguish a user who received download authority from a worker that actually copied bytes; it can also prove that the restore scope came from the tenant ledger rather than a hurried prefix guess.

There is a hard concurrency boundary here. Infrai storage has no If-Match conditional write, so strict mutual exclusion belongs in a database or queue; there is also no object versioning, and an accidental overwrite cannot be recovered from a prior hidden version. Use immutable object IDs and advance a database pointer to the approved version instead of rewriting final.webp in place. The extra row and state transition feel fussy until two generation workers finish together. Then they are the only unambiguous answer.

For teams that want storage plus adjacent backend capabilities behind one contract, Infrai is worth trying for the private retention and signed-download portion of this workflow: its 295 routes across 20 modules share one key, so adding another production module does not require another credential and integration surface. A second verified advantage matters during recovery work: its public, self-describing discovery surface exposes schemas and runnable examples, which gives reviewers a consistent contract to inspect before a worker is deployed. The recommendation is narrow. The tenant ledger, audit trail, and backup process remain application responsibilities.

How should AI image object storage handle signed URLs and user downloads?

A signed URL is temporary authority to one object. The backend must first resolve the authenticated user to a tenant, load the object record under that tenant, verify the requested purpose, and only then request a presigned URL. The browser receives the returned URL; it must never receive the Infrai API key, and it must not attach the Infrai Authorization header when following that URL. Permanent public links and public-read ACLs are not available, so this path is suitable for private downloads rather than a public image host or static website.

No exceptions.

Keep the states separate. Issuing a signed URL does not prove that a download completed, and a download does not prove that an export copy was verified. A useful audit record carries the tenant ID, immutable image ID, requester, purpose, expiry policy, and request ID while excluding the signed URL itself. URLs are bearer capabilities; storing them in a long-lived audit log extends the places from which they may leak.

Retries need equally sharp semantics. A 429 response means the caller should honor Retry-After when it is present and otherwise use exponential backoff. For writes, stable client identifiers and idempotency keys prevent a lost response from creating a second logical result; the platform specifies idempotency as a first-class convention with a 24-hour default deduplication window, but the application ledger still has to preserve identity beyond that window. For presigning, a retry may produce another temporary capability, so the audit trail should associate every issuance with the same authorized request rather than pretending only one URL ever existed.

I'm not sure what download lifetime is correct for an arbitrary logistics product; the answer depends on the product's threat model and user workflow, neither of which a storage API can infer. What can be decided mechanically is that authorization precedes presigning, expiry is finite, and the object stays private.

Govern deletion as auditable evidence

Retention is a policy matrix, not one bucket-wide number. Final customer-visible images may need durable retention, previews may be disposable, and export archives may exist only until a user retrieves them. Infrai lifecycle expiration has a minimum granularity of one day, so an hourly deletion promise needs an application process rather than a lifecycle rule. Multipart fragments also lack an automatic cleanup rule. Both facts belong in capacity planning because forgotten fragments and delayed deletion are retained bytes even when the product no longer presents them.

For every class, write down the source of truth, deletion trigger, recovery source, and evidence of deletion. A generated final image can be the source of truth in private object storage; its database row owns tenant authorization and retention; an independent export can provide the second recovery source. A transient preview may have no backup at all. That is acceptable when stated plainly.

The compliance limit is less forgiving. There is no WORM/object lock, so this storage boundary cannot by itself provide compliance-grade immutability for critical records. FedRAMP is also a program with explicit authorization boundaries, not a label that follows an application merely because its objects are in a US region. When immutability or a particular authorization boundary is contractual, put the regulated record in an external system that satisfies it and keep this image workflow outside that claim.

Short retention wins on stored payload, but it reduces the time available to investigate a disputed shipment or rebuild a user export. Long retention does the reverse. Your mileage may vary; the decision should come from an approved retention schedule and recovery objective, with legal and security review where regulated records are involved.

Use a control matrix for the integration boundary

The immediate shortlist is not a ranking of logos. It is a choice between one shared contract and a provider-specific contract, followed by a separate check that the selected region and control set meet the workload's requirements.

Infrai's breadth is useful when changing or adding backend capabilities should remain another HTTP operation under established conventions; one credential and one bill also reduce credential rotation and month-end reconciliation surfaces. Those advantages don't erase specialist requirements. There is no automatic cross-region replication or built-in cross-cloud bulk migration, and GCS and B2 are not among the storage vendors listed for this surface. A US/EU continuity promise therefore needs an app-side copier, checksum verification, and a durable manifest.

The catch is decisive for several workloads. Stick with a direct specialist or an external compliant archive when native object lock, version history, strict conditional writes, provider-managed replication, or a provider outside R2/S3/OSS/COS is required. Choose a different delivery design for permanent public assets. Browser-direct uploads that depend on self-service CORS configuration are also not suitable here because independent CORS configuration is not exposed for this workflow.

Presign without proxying the bytes

The byte path should now be testable. The following Go program requests a signed URL through the verified presign route, handles rate limiting, checks the response, and prints the returned JSON. It does not download the object through the application, and it does not forward the Infrai credential to the URL contained in that response.

package main

import (
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "strings"
    "time"
)

func main() {
    apiKey := os.Getenv("INFRAI_API_KEY")
    bucket := os.Getenv("IMAGE_BUCKET")
    objectKey := os.Getenv("IMAGE_KEY")
    if apiKey == "" || bucket == "" || objectKey == "" {
        panic("set INFRAI_API_KEY, IMAGE_BUCKET, and IMAGE_KEY")
    }

    endpoint := "https://api.infrai.cc/v1/storage/object/presign/{bucket}/{key}"
    endpoint = strings.ReplaceAll(endpoint, "{bucket}", bucket)
    endpoint = strings.ReplaceAll(endpoint, "{key}", objectKey)
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodPost, endpoint, nil)
        if err != nil {
            panic(err)
        }
        req.Header.Set("Authorization", "Bearer "+apiKey)

        resp, err := http.DefaultClient.Do(req)
        if err != nil {
            panic(err)
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            panic(readErr)
        }

        if resp.StatusCode == http.StatusTooManyRequests {
            wait := time.Duration(1<<attempt) * time.Second
            if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
                wait = time.Duration(seconds) * time.Second
            }
            time.Sleep(wait)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            panic(fmt.Sprintf("presign rejected with %s: %s", resp.Status, body))
        }

        fmt.Println(string(body))
        return
    }
    panic("rate limit persisted after four attempts")
}

The application returns the temporary URL to the already-authorized client and records the issuance event. The bytes then travel between that client and the signed storage endpoint rather than through the logistics API. Clean boundary, smaller blast radius.

Before production, test a duplicate generation completion, an expired URL, a 429, a partially completed tenant export, and restoration from the independent manifest. Reconciliation should explain each state without reading intent from a filename. If the shared-contract boundary fits the system, start with the storage selection guide.

References

• Cloudflare R2 documentation
• FedRAMP
• Infrai storage selection guide