Short answer: keep one immutable, private original per tenant, derive named thumbnail sizes asynchronously with Sharp, and make the object key—not a client-supplied filename—the isolation boundary. Store a manifest that records the source version and every derivative, then authorize reads before issuing a short-lived URL.
This is the boring answer, which is why it survives audits. A B2B SaaS receipt may be cropped for an avatar-like account thumbnail today and needed at its original resolution during a dispute six months later. Overwriting the upload or putting tenant IDs only in metadata creates a dangerous dependency on every reader getting every check right.
Consider a pipeline that returns a 403 for a cross-tenant thumbnail request while its cache key omits the tenant. The first request is denied; a later cache hit may never reach that check. Error code 403, correct in isolation, does not make the architecture safe. Don't patch this with another try/except—the authorization decision and cache partition must use the same tenant context.
How can Node.js Sharp implement avatar crop and resize in private object storage?
Treat the original as the source of truth and derivatives as disposable projections. A request creates an upload record with tenant_id, an opaque asset ID, content type, byte length, checksum, and a state such as pending. The worker validates the bytes, writes the original once, and produces only the sizes your UI actually needs, for example 64x64, 256x256, and 1024x1024. The API never accepts a path such as tenant-a/avatar.png from a browser.
The key can be predictable to your own service while remaining meaningless to clients: tenants/{tenant_id}/assets/{asset_id}/original and tenants/{tenant_id}/assets/{asset_id}/thumb-256.webp. Keep the original extension out of the security decision; sniff the decoded format, enforce a pixel and byte ceiling, and reject an image that expands far beyond its upload size. Sharp in a Node.js worker is a sensible implementation of the decode, rotate, crop, and encode steps, but the storage contract remains valid if the worker is later replaced.
The manifest belongs in a transactional database, not in the object name. It should say which original hash produced each derivative, the crop anchor or focal point, dimensions, media type, and processing version. A new crop creates a new derivative version; it does not silently mutate the audit source.
One sentence is enough for the invariant: a tenant-scoped authorization check must happen before a private object key is resolved or cached.
Keep it private.
Tenant data governance starts in the manifest
The critical path has four boundaries: upload, validate, derive, and serve. Each boundary has a different failure mode. Upload may be interrupted, validation may discover a decompression bomb, derivation may run out of worker capacity, and serving may race with a newly published manifest. Keeping those states separate lets an operator retry the safe step instead of replaying an entire request. In a receipt workflow, that distinction matters during a burst: a database row can remain pending while the queue drains, the original can be available to an auditor before every thumbnail is ready, and a failed derivative can be re-enqueued without accepting a second upload. The manifest is the join point for those observations, so it should carry a monotonic processing version and a timestamp for each transition rather than a single mutable boolean.
| Decision | Chosen rule | Why | Trade-off or limit |
|---|---|---|---|
| Original | Immutable private object, keyed by opaque asset ID | Preserves audit evidence and supports reprocessing | Storage grows; lifecycle retention must be deliberate |
| Derivatives | Versioned thumb-{size}.{format} objects |
Cacheable and reproducible from a known source | More objects and a manifest to maintain |
| Isolation | Tenant in the server-built key and database predicate | Prevents filename and path traversal from becoming authorization | Cross-tenant administration needs an explicit audited role |
| Processing | Queue work after a committed upload record | Keeps request latency bounded and retries idempotently | The UI must represent pending rather than pretending the image exists |
| Delivery | Private read followed by a short-lived signed URL or proxy | Object storage is not exposed as a public bucket | URLs expire; clients need a refresh path |
The rejected option is a single public object with query-string resizing. It is attractive for a prototype because there is no worker or manifest, but it makes revocation and tenant deletion harder and lets a URL become a bearer credential. It is valid for deliberately public marketing media; it is not a good default for receipts or account images tied to a customer record.
Test the worker before trusting the output
The following Python sketch mirrors the contract I would put behind a Node.js and Sharp worker. It does not pretend to be a storage SDK: put_private and read_private are narrow adapters that enforce the bucket's private policy. Sharp can implement the same transform in the production worker; the important behavior is deterministic keys, bounded input, and no overwrite of the original.
from dataclasses import dataclass
from hashlib import sha256
from io import BytesIO
from typing import Protocol
from PIL import Image, ImageOps
class PrivateStore(Protocol):
def put_private(self, key: str, data: bytes, content_type: str) -> None: ...
@dataclass(frozen=True)
class Asset:
tenant_id: str
asset_id: str
def build_keys(asset: Asset, size: int, fmt: str) -> tuple[str, str]:
prefix = f"tenants/{asset.tenant_id}/assets/{asset.asset_id}"
return f"{prefix}/original", f"{prefix}/thumb-{size}.{fmt}"
def process_avatar(store: PrivateStore, asset: Asset, original: bytes, sizes=(64, 256, 1024)) -> dict:
if len(original) > 15 * 1024 * 1024:
raise ValueError("upload exceeds byte limit")
source_hash = sha256(original).hexdigest()
with Image.open(BytesIO(original)) as source:
source.verify()
with Image.open(BytesIO(original)) as source:
if source.width * source.height > 40_000_000:
raise ValueError("image exceeds pixel limit")
normalized = ImageOps.exif_transpose(source).convert("RGB")
original_key, _ = build_keys(asset, sizes[0], "webp")
store.put_private(original_key, original, "application/octet-stream")
derivatives = []
for size in sizes:
thumb = ImageOps.fit(normalized, (size, size), method=Image.Resampling.LANCZOS)
output = BytesIO()
thumb.save(output, format="WEBP", quality=84, method=6)
_, key = build_keys(asset, size, "webp")
store.put_private(key, output.getvalue(), "image/webp")
derivatives.append({"size": size, "key": key, "source_hash": source_hash})
return {"asset_id": asset.asset_id, "tenant_id": asset.tenant_id,
"original_hash": source_hash, "derivatives": derivatives}
There are two details worth keeping. verify() runs before the second decode, so a truncated or malformed upload fails before any derivative is published. EXIF orientation is normalized before the square crop; otherwise a phone portrait can become a sideways thumbnail while the original looks fine in an audit viewer. The production adapter should also use conditional creation or an idempotency token so a retried job cannot replace an existing original with different bytes.
Retry and failure semantics for missing thumbnails
A queue retry is normal. A key collision is not. Include the asset ID and a processing version in the job; the worker can safely re-run a job when the destination key is already present with the same source hash. If the hash differs, stop and raise an operational alert. Never “repair” that mismatch by deleting the original automatically.
A derivative can be missing while the original is healthy. The read API should return a stable pending or ready state from the manifest and avoid guessing from a 404. This also gives dashboards useful signals: derivative lag, validation rejection rate, queue age by tenant, and signed-URL issuance failures.
Deletion has a wider blast radius than upload. A tenant deletion workflow should mark the database records, stop new jobs, remove all keys under the server-generated prefix, and retain an audit event about what was removed. Object-store versioning and retention policies may mean physical deletion is delayed; state that policy plainly to the customer and to the compliance owner.
Your mileage may vary on exact thumbnail sizes. I am not sure a 1024-pixel derivative belongs in every product; measure the largest viewport and the network budget first. The decision is about preserving the original and isolating tenants, not about collecting a fashionable menu of formats.
Migration limits for a public media workload
This pattern fits a SaaS product that needs private receipt evidence, repeatable crops, and independent cache lifetimes. It is not suitable when images are intentionally public and a global CDN URL is the product requirement; a public media pipeline can be much simpler. Stick with a public bucket and immutable content hashes when the data has no tenant confidentiality.
The catch is operational ownership. You now own a queue, image-library upgrades, pixel limits, key cleanup, and an authorization test matrix. A managed storage service can remove some pager work, but it cannot decide your tenant policy or prove that a cache key includes the right principal. Test those controls with two tenants, an expired URL, a deleted manifest, a duplicate job, and a deliberately rotated EXIF image before calling the design done.
For delivery, set Content-Disposition deliberately when a browser should download an original rather than display it inline; the header's inline and attachment semantics are defined by HTTP, and a safe filename is still derived by the server. Keep object names opaque even when the response filename is friendly.
The storage rule is easy to state.
A useful review question is simple: can an operator reconstruct the exact original bytes, processing version, tenant decision, and access event for one receipt without reading application logs from three unrelated services? If the answer is no, adding another resize preset will not fix the storage design.
Top comments (0)