Amba
Platform

Media Serving & CDN

How uploaded assets are served — the CDN domain, edge caching, image transforms, and byte-range requests for audio and video seek.

Every asset you upload is served from your project's CDN domain through Amba's global edge network, cached close to your users. This page covers the serving behavior end to end: the URL pattern, cache lifetimes, on-the-fly image transforms, byte-range support for media seek, and how updates propagate.

The serving domain

Assets are served from your project's dedicated CDN hostname:

https://{projectId}.cdn.amba.host/{bucket}/{filename}

For example, an asset registered in the default media bucket as episode-42.mp3 is served at:

https://{projectId}.cdn.amba.host/media/episode-42.mp3

Public buckets (like the default media bucket) serve without any authentication — the URL is the asset. Private buckets require a signed download URL issued by the API; see Media Management for the upload and registration flow.

Edge caching

Responses are cached at the edge so repeat reads are served near the user instead of round-tripping to storage:

ResponseEdge cacheBrowser cache
Original asset (no query params)5 minutes5 minutes
Transformed image (?w=, ?fmt=, ...)1 hour24 hours

The headers behind that table, as served:

  • Original assets: Cache-Control: public, max-age=300
  • Transformed images: Cache-Control: public, max-age=86400, s-maxage=3600

Transformed responses also carry Vary: Accept, because the output format is negotiated from the client's Accept header when you don't pin one with ?fmt=.

Image transforms

Append query parameters to any image URL to get a resized, re-encoded variant on the fly — no pre-generation step:

ParamValuesEffect
w110000Target width in pixels
h110000Target height in pixels
fitcover, contain, crop, scale-downHow the image fills the target box
fmtwebp, avif, jpeg, png, autoOutput format (auto negotiates)
q1100Quality (lossy formats)
dpr0.54Device pixel ratio multiplier
https://{projectId}.cdn.amba.host/media/hero.png?w=800&fit=cover&fmt=auto

Malformed transform values are dropped rather than erroring — a typo'd parameter serves the closest valid variant instead of failing the page load. Each transformed variant is cached independently, keyed by the full URL including its query parameters.

Byte-range requests (audio & video seek)

Asset responses advertise Accept-Ranges: bytes, and Range requests are honored on original assets — so media players can seek into a large audio or video file without downloading the whole thing. Players and browsers do this automatically; there's nothing to configure.

Behavior:

RequestResponse
Range: bytes=0-1023206 Partial Content with the first 1,024 bytes
Range: bytes=1024- (open-ended)206 from byte 1,024 to the end of the file
Range: bytes=-500 (suffix)206 with the final 500 bytes
Start position past the end of the file416 with Content-Range: bytes */<size>
Multiple ranges (bytes=0-1,5-9)200 with the full body
Malformed Range header200 with the full body

Every 206 carries a Content-Range header (bytes <start>-<end>/<total>) and a Content-Length matching the slice, with the same content type, ETag, and cache headers as a full read.

Ranges apply to original assets only. A Range header on a transformed image URL is ignored — transformed output is generated per request, so the full image is returned.

Updates and cache freshness

There is no manual purge step — freshness is TTL-driven:

  • Overwriting an asset at the same path serves the new bytes once the edge cache expires: within 5 minutes everywhere, sooner at edges that hadn't cached it.
  • Transformed variants are keyed by their full URL, so they refresh on the same schedule as their cache lifetime (up to 1 hour at the edge, 24 hours in browsers that already fetched the old variant).
  • Need an instant update? Upload under a new filename (for example, version-suffixed: hero-v2.png). A new URL is never cached anywhere, so it serves fresh immediately — the recommended pattern for assets you expect to replace.

Inspecting the headers

curl -I issues a HEAD request and shows exactly what the edge serves:

curl -I https://{projectId}.cdn.amba.host/media/episode-42.mp3
HTTP/2 200
content-type: audio/mpeg
accept-ranges: bytes
cache-control: public, max-age=300
etag: "9a0364b9e99bb480dd25e1f0284c8555"
x-amba-project-id: proj_x1y2z3

And a ranged read, the way a media player seeks:

curl -s -D - -o /dev/null -H 'Range: bytes=0-1023' \
  https://{projectId}.cdn.amba.host/media/episode-42.mp3
HTTP/2 206
content-type: audio/mpeg
content-range: bytes 0-1023/8388608
content-length: 1024
accept-ranges: bytes
cache-control: public, max-age=300
etag: "9a0364b9e99bb480dd25e1f0284c8555"
x-amba-project-id: proj_x1y2z3

On this page