Client Delivery·Guide

Asset delivery economics

“Secure delivery” is not one product. On one side of the boundary, the storage host can read your objects (standard cloud storage with TLS and provider encryption). On the other side, only the client’s key unlocks the files (zero-knowledge). Most photography platforms, including ArtInStack, live on the first side. What studios usually buy next is entitlement and brand: who gets into the portal, whether client masters sit on a public CDN or in Private storage, and whether you hand out a permanent CDN URL or a short-lived signed one.

What “secure” must specify

Four questions before you trust a delivery link

  1. Who holds the key

    Provider-managed encryption at rest is normal. Zero-knowledge means the host cannot decrypt. Do not score them as the same checkbox.

  2. Public CDN vs gated download

    A public object URL on a CDN hostname is world-readable if someone has the path. Private portfolio masters never get that hostname. Portal and purchase downloads still use short-lived signed URLs after entitlement, not a permanent CDN link in email.

  3. Who is entitled

    Invite-plus-access-code, a shared password, or an anonymous transfer link create different leak surfaces.

  4. Where the brand sits

    A transfer page that looks like someone else’s product trains clients that the job is temporary and optional.

The boundary the hero draws

Left of the line: the storage provider (and usually the SaaS) can access plaintext objects. Files travel over TLS; at rest they use provider keys. Access control is the product story: who may enter the portal, which grant they hold, and what URL shape you return for a download.

Right of the line: zero-knowledge or end-to-end models where the service never holds a usable key. That class exists in niche file products. It is almost never what “client gallery software” means in photography marketing, even when the landing page says encrypted.

ArtInStack is honest about the left side. We do not claim zero-knowledge. If a job truly requires that the host cannot decrypt, you need a different product class, not a prettier gallery.

Why zip links still feel cheap

WeTransfer-style handoffs optimize for one-shot archive moves. They are fine when proofing is already finished and you only need bytes to leave the building. They fail as a delivery system: no entitlement model tied to a client, no studio queue, no quiet path back into print or a branded portal.

The economic waste is rematch labor and brand erosion. You already paid to shoot and edit. Paying again in email archaeology (“which folder?”) and in a third-party download page that looks nothing like the site they hired is how a finished job still feels unfinished.

Replace the zip ritual with a portal grant when the client still needs to decide, shortlist, or return later. Keep a transfer link for the rare case where the only remaining job is “here is the archive.”

What ArtInStack actually delivers

The platform is public-first for the CMS. Media library uploads and normal public portfolios live on a public R2 custom domain so site pages, embeds, and marketing surfaces can use a CDN path. That is deliberate for work you mean to publish, not a claim that every client file shares that hostname.

Private portfolios are a separate path. Upload into a Private gallery and those masters land in a private R2 bucket (no public CDN domain). Client Portal viewing and downloads still require invitation auth and entitlement; the API then returns short-lived signed GETs for display and archival files. Purchase downloads follow the same idea: token route, then a signed redirect.

Signing a public object does not make it secret: anyone with the permanent CDN path can still fetch it. Real exclusivity for client work comes from Private storage: the object is not on the public hostname at all. Do not confuse that with zero-knowledge, and do not confuse a watermarked public preview with archival delivery.

ModelWho can decryptStudio reality
Anonymous transfer linkProvider + anyone with the linkFast archive dump; weak entitlement
Public portfolio / CMS mediaProvider + anyone with the CDN pathArtInStack public R2 for site and embeds
Private portfolio + portal handoffProvider + entitled clients onlyArtInStack private R2; auth gate, then signed GET
Zero-knowledge vaultClient key holders onlyRare in photo delivery; different product

Where each option actually fits

Choose ArtInStack when delivery must sit on the same spine as proofing and the public site: branded portal, Private galleries for client masters, granted downloads, and a path back to print without rematching files.

Choose a zero-knowledge file product when the contract literally requires that the host cannot decrypt. Expect a second system beside your gallery.

Use a plain transfer link only for one-shot archives after decisions are closed. It is logistics, not a client room.

Deliver files without the zip ritual

Invite the client. Grant the download. Use Private galleries when masters must stay off the public CDN. Keep everything on the same spine as the site.

Also in Guides: Client galleries that convert · Client experience architecture · The myth of unlimited storage

All Client Delivery guides · Guides home