Media Management in SAP Commerce: Storage, Conversion, Secure Access, and the CDN

Media is the quiet majority of a storefront's page weight and a surprising amount of its operational complexity. Product images, their responsive format variants, downloadable assets, gated content, and the CDN that delivers all of it: the platform models this carefully, and CCv2 changed the storage rules underneath it in ways that break naive on-premise habits. This guide covers the media model, format conversion, secure access, and delivery, with the ephemeral-storage reality that means media never lives on the node. It connects to the catalog synchronization guide (media is catalog data), the web architecture guide (the CDN), and the Cloud Portal ops guide (the ephemeral-storage rule).

The Model: Media, MediaContainer, MediaFormat#

The type system (the type system guide) models media as first-class items:

• Media: a single asset with its binary, mime type, and metadata, catalog-version-aware like other catalog data (so a product's image is Staged or Online, syncs with the catalog, the catalog sync guide).
• MediaContainer: groups the format variants of one logical asset. A product photo is a container holding the thumbnail, the gallery size, the zoom size, each a Media in a MediaFormat.
• MediaFormat: a named format (thumbnail, product, zoom) that variants are generated into.

This structure is why a storefront can request "the product-format image" and get the right variant: the container resolves the format to the specific Media. Designing your formats to match your responsive image needs (the sizes the storefront actually serves) is the modeling decision that makes efficient image delivery possible.

Format Conversion: The Cloud Service Replaced ImageMagick#

Generating those format variants (resizing, reformatting) historically required ImageMagick installed on the server, which is impossible on CCv2 where you do not control the node's binaries. The platform's answer is the cloud media conversion service, enabled by including the cloudmediaconversion extension in the manifest (the Cloud Portal ops guide). It provides image conversion as a managed service, so the responsive variants generate without a server-side binary you cannot install.

The architectural note: conversion is work, and doing it at the right time matters. Converting on upload (as media is onboarded) keeps it off the request path; converting on-demand at first request trades storage for latency on the first hit. For a catalog with predictable formats, convert ahead; the high-traffic guide's warm-up thinking applies to media too. Third-party needs beyond the standard resize-and-format pipeline (DAM workflows, AI cropping) are a side-by-side service (the side-by-side guide), not a platform extension.

Ephemeral Storage: Media Lives in the Cloud, Not the Node#

The rule that breaks on-premise habits, from the Cloud Portal ops guide, applies with full force to media: CCv2 application nodes have ephemeral disks. Media written to a node's local disk vanishes when Kubernetes recycles the node. Therefore:

• Media persists in cloud-backed storage, not on the application server. The platform's media storage abstraction handles this, but custom code that writes an uploaded file to a local path and expects to read it back later is broken on CCv2.
• Bulk media onboarding rides Cloud Hot Folders (the cloud hot folders guide): drop images in Azure Blob Storage, and the hot folder processes them into the media model, including URL media (importing a remote asset by URL rather than shipping the binary).
• Never assume a local media directory. Any migration from on-premise must audit media handling for local-disk assumptions (the migration testing guide validates exactly this: that media resolves and renders from the new storage).

Secure Media: Gating Access#

Not all media is public. Downloadable purchases, gated B2B documents, and personalized assets need access control, and the platform provides secure media: assets stored in secure media folders whose delivery is gated through the application (checking the requesting user's entitlement) rather than served as an open URL. The design points:

• Public media (product images) can be CDN-cached and openly served, because there is no secret in a product photo.
• Secure media must route through the access check, which means it cannot be naively CDN-cached at a public URL (that would bypass the gate), and its delivery is a controlled, authenticated path. The security hardening guide's "lock down folders holding non-public files" is exactly this.
• The salt matters: the media storage hash salt (the security hardening guide) must be changed from default before media exists, so secure-media URLs are not guessable.

Deciding public-versus-secure per asset type is a design step, because getting it wrong leaks gated content (secure asset served publicly) or breaks caching (public asset needlessly gated).

Delivery: The CDN Owns Page Weight#

Media is where the CDN earns most of its value, because images and static assets dominate page weight and are the most cacheable content you have:

• Front public media with the CDN (the web architecture guide's sandwich pattern): the CDN caches product images and static assets at the edge, close to the customer, offloading the origin and cutting latency dramatically. The performance engineering guide's budgets are largely a media-delivery story.
• Set cache headers correctly: long max-age for immutable asset variants (a resized image at a content-hashed URL never changes), with cache-busting via URL versioning when an asset is replaced, so customers get the new image without stale-cache problems.
• Serve responsive variants: deliver the format variant matched to the device (the MediaFormat model plus responsive markup), so a phone does not download the zoom-size image. This is where the media model and the delivery layer combine to control real page weight.
• Secure media bypasses the public CDN cache by necessity (above); its delivery is authenticated and typically not edge-cached at a public URL.

Checklist#

• Media modeled with containers and formats matching the storefront's responsive image needs
• cloudmediaconversion enabled; format variants generated (ahead-of-time where predictable), no server-side ImageMagick assumption
• No local-disk media assumptions; media persists in cloud storage; bulk onboarding via Cloud Hot Folders / URL media
• Public-versus-secure decided per asset type; secure media gated through the access check, not openly served
• Media hash salt changed from default before media exists
• Public media fronted by the CDN with correct long-max-age and URL-versioned cache-busting
• Responsive variants served per device to control page weight; secure media kept off the public cache
• Migration audits confirm media resolves and renders from the new storage

Media management is easy to underestimate and expensive to get wrong: it is most of your page weight, it broke in a specific way when CCv2 made storage ephemeral, and it splits into public assets that want aggressive CDN caching and secure assets that must not be cached at all. Model the formats, convert through the cloud service, keep media off the node, gate what must be gated, and let the CDN carry the public majority, and media becomes the fast, invisible layer it should be rather than the source of stale images and vanished uploads.