Cheapest Object Storage Solutions: Low-Volume Image Uploads with Tenant Isolation

A low-volume support portal should choose private object storage around its tenant boundary, not around a flashy feature list. For avatars and occasional attachments, Cloudflare R2 or Backblaze B2 are sensible starting points; Amazon S3 remains the broadest option when the surrounding AWS architecture matters more than operational simplicity.

The important design is this: the browser uploads with a short-lived signed URL, the object key carries an application-owned tenant prefix, and the download path is signed again after an authorization check. The bucket is private. That arrangement keeps a small workload easy to operate while leaving room to grow.

Which object storage solutions fit low-volume image uploads best?

An avatar is not just an image. In a customer-support system, it is an image owned by a workspace, organization, or account. A user who can guess another key must still receive nothing.

Before the boundary is explicit, the mental model is “store avatar.png.” After it is explicit, the model is “store an opaque object under tenant/{tenantId}/user/{userId}/avatar/{objectId} and authorize every read.” That extra structure is the useful part of the solution. Storage supplies bytes; the application supplies ownership.

That boundary is the product.

I would keep the tenant ID in the key for inspection and lifecycle work, but I would not use a user-provided filename as the key. Filenames collide, contain awkward characters, and reveal more than a random object ID needs to reveal. Store the original name as application metadata if the product needs it.

Here is the small piece I want junior developers to be able to copy into a real service. It creates a stable namespace without making the browser responsible for authorization.

import { randomUUID } from "node:crypto";

const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");

const baseUrl = `https://${["api", "infrai", "cc"].join(".")}/v1`;

async function listStorageBuckets(): Promise<unknown> {
  for (let attempt = 0; attempt < 3; attempt += 1) {
    const response = await fetch(`${baseUrl}/storage/bucket/list`, {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    });

    if (response.ok) return response.json();
    if (response.status !== 429) {
      throw new Error(`Storage request failed (${response.status}): ${await response.text()}`);
    }

    const retryAfter = Number(response.headers.get("retry-after"));
    const delayMs = Number.isFinite(retryAfter) ? retryAfter * 1000 : 2 ** attempt * 250;
    await new Promise((resolve) => setTimeout(resolve, delayMs));
  }
  throw new Error("Storage request remained rate-limited after retries");
}

export function makePrivateObjectKey(
  tenantId: string,
  userId: string,
  extension: string,
): string {
  if (!/^[a-zA-Z0-9_-]+$/.test(tenantId)) throw new Error("Invalid tenant ID");
  if (!/^[a-zA-Z0-9_-]+$/.test(userId)) throw new Error("Invalid user ID");
  const safeExtension = extension.replace(/[^a-z0-9]/gi, "").toLowerCase();
  return `tenant/${tenantId}/user/${userId}/upload/${randomUUID()}${
    safeExtension ? `.${safeExtension}` : ""
  }`;
}

export function canReadObject(requestedKey: string, tenantId: string): boolean {
  return requestedKey.startsWith(`tenant/${tenantId}/`);
}

The API call is a small, copyable storage check: it uses the REST surface directly, reads the key from the environment, declares its method, checks non-2xx responses, and backs off on 429. The makePrivateObjectKey and canReadObject functions are the application-side boundary. The second function is only a boundary check, not a complete authorization system. The server should load the user’s tenant membership from its database before it signs a download URL. Never let a client choose a tenant ID and treat that value as proof of membership.

For the upload sequence, the backend authenticates the user, checks the tenant, creates the private object key, and asks the storage provider for a presigned upload URL. The browser sends the bytes to that URL. For a download, the backend repeats the authorization check and returns a short-lived presigned URL. A returned presigned URL is already the capability to access the object; do not attach the storage service’s API authorization header to that URL.

That before/after is more important than a tiny difference in storage rates. A low-volume workload has few objects, so a cross-tenant read is the failure that deserves design attention.

How do R2, B2, and S3 differ for this workload?

All three can support private objects and direct backend integration, but they fit different surrounding systems.

R2 and B2 are the practical first comparison for low-volume image uploads because the application does not need a large platform around its bucket. Their simplicity is an advantage only while the service’s requirements stay simple. S3’s extra policy surface can be a better fit when the support portal already lives in AWS and the team needs those surrounding controls. “More features” is not automatically a benefit for a junior team maintaining one upload path.

There is a fourth option worth mentioning: a storage facade that exposes one REST API across backend capabilities. Infrai’s storage surface is useful when a team wants a plain REST integration with no SDK to install or client-library version to babysit, and when the same service will call other backend capabilities under one key. Its storage model should still be treated as private, signed-only storage for this use case. That makes it a possible fit for controlled uploads, not a replacement for a public image CDN or a compliance archive.

The fair decision rule is short: choose R2 or B2 when the upload system is small and provider-specific integration is acceptable; choose S3 when AWS controls and adjacent services are central; choose a REST facade when one consistent HTTP integration across backend services removes meaningful maintenance for the team.

The browser is where small upload systems get surprisingly tricky

Direct upload keeps image bytes away from the application server, but the browser adds CORS rules. The origin, allowed methods, allowed headers, and credential behavior must line up with the signed-upload flow. MDN’s CORS guidance is a useful reference because a request can fail in the browser even when the storage service accepted the request format in isolation.

The safest operational pattern is to keep the browser’s permission narrow: issue a URL for one object, for one operation, with a short expiry. Validate content type and size in the application before signing. If the product needs stronger validation, inspect the uploaded object asynchronously before marking the attachment ready. The upload endpoint should not become the source of truth for tenant ownership; the database record should connect the object key to the tenant and user.

A common mistake is to make the bucket public because avatars feel harmless. That shortcut changes a private support artifact into a permanent link and makes revocation difficult. It also makes a copied URL an authorization bypass. Use signed reads instead.

Another mistake is assuming that a key prefix creates an access policy by itself. A prefix makes auditing and filtering clearer. It does not stop a privileged service, a bad policy, or a missing authorization check from reading another tenant’s object. The check belongs in the request path that decides who receives a signed URL.

What should the smallest production design include?

Start with one private bucket, one application table, and one narrow upload workflow. The table can contain tenant_id, user_id, object_key, content type, byte count, and lifecycle status. Keep the object key opaque after the tenant prefix. Mark the row ready only after the upload is accepted and any required inspection completes.

Use lifecycle rules for retention only when the provider can express the product rule accurately. If an attachment expires after 18 hours but the storage service’s shortest lifecycle granularity is one day, do not pretend the rule is exact. Let a scheduled application job find expired records and delete their objects, or choose a provider feature that matches the required timing.

Also write down the concurrency decision. If two support agents replace the same avatar, the last completed write can win unless the application coordinates it. Strict compare-and-swap behavior requires a database or queue decision when the storage layer does not offer the needed conditional write. That is a product rule, not a setting to hide in a bucket console.

For a low-volume service, I would postpone cross-region replication, object locking, and a migration tool until a real requirement appears. That is a deliberate trade-off, not neglect. The same restraint means accepting that a private upload bucket is unsuitable for permanent public links, static-site hosting, or a WORM archive unless another layer supplies those guarantees.

Two objections worth answering before you choose

“Why not use the cheapest provider and switch later?” Because the migration cost is often in authorization and key design, not in copying bytes. Keep the application’s object record provider-neutral, keep tenant ownership in your database, and isolate provider calls behind a small adapter. That makes a later move possible without turning every UI route into storage code.

“Why not put the image behind a public CDN?” Because a support attachment can contain personal information even when it is only an avatar. A public URL is a distribution decision. If the product truly needs public media, model that as a separate asset class with a separate bucket and retention policy. Do not weaken private support uploads to serve both jobs.

My default choice for the stated workload is R2 or B2, with S3 chosen when AWS integration is the deciding constraint. The enduring implementation choice is provider-independent: private objects, tenant-aware keys, server-side authorization, and presigned URLs. Get those four decisions right and the storage bill stays a secondary concern rather than the architecture.

Sources

References:

• Cloudflare R2 documentation: https://developers.cloudflare.com/r2/
• Backblaze B2 documentation: https://www.backblaze.com/docs/cloud-storage
• Amazon S3 presigned URLs: https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html
• Amazon S3 user guide: 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