Creating a CDN resource

How to plan and create a CDN resource: domains and aliases, origins and origin groups, standard versus video delivery, and the limits to design around before you configure.

LAST REVIEWED

A CDN resource is the unit that binds domains to origins and defines every delivery behaviour downstream: caching, access, headers, TLS, and logging. Creating one is mostly a planning exercise — decide the model first, then the configuration follows. This page covers the decisions that are expensive to change later.

Read CDN overview first if you are choosing a delivery mode.

Domains and aliases

A resource has one primary domain and any number of aliases — additional hostnames that serve the same configuration and cache. Group hostnames into one resource only when they should share cache entries, headers, and access policy.

  • Keep a dedicated certificate per brand. A shared certificate can leak one property’s identity into another’s.
  • Force HTTPS and set the minimum acceptable TLS version; modern clients negotiate HTTP/2 and HTTP/3 automatically.
  • If two properties must not share cache or logs, give them separate resources even when they share an origin.
  • Plan www and bare-domain aliases deliberately. A redirect at the edge is cheaper than a second cache entry.

Origins and origin groups

An origin is where the edge fetches on a miss. Point at a single origin, or define an origin group with a primary and one or more backups so a failing origin is not a viewer-facing outage. For adult platforms the common patterns are:

Origin patternUse caseNotes
Object storagePackaged media, originals, derivativesCheap, durable; treat as the canonical copy
Private originApplication/API and protected mediaMust only accept edge addresses
Origin groupDeploys, storage migrations, DRPrimary plus warm standby

Keep origins private. If an origin is reachable from the public internet, viewers can bypass caching, access control, and edge security entirely. Use allow-lists, mutual TLS, or a private link between edge and origin, and rotate credentials on the origin rather than embedding them in URLs.

Standard versus video resources

The two resource types differ in how they handle byte ranges, manifests, and large objects.

  • Standard delivery serves websites, APIs, thumbnails, and prepared downloads. It optimises small-object caching and header/security policy.
  • Video delivery is built for HLS, DASH, MP4, and FLV: it honours byte ranges end to end, caches segments and manifests intelligently, and protects origin from seek-heavy traffic. See Adult video CDN.

Most platforms run several resources: one for the portal and API on standard delivery, one or more for video, and separate resources for anything that needs different access or caching rules. Do not put cacheable media and uncacheable API responses behind one resource.

What to decide before configuring

  1. Traffic class — website/API, prepared video, live, or mixed.
  2. Domain set — primary plus aliases, and which certificate each needs.
  3. Origin architecture — single, group, or object storage, and how it is locked down.
  4. Cache strategy — cacheable bytes, TTLs, and key composition. See Cache control and cache keys.
  5. Access model — public, signed, token-gated, or geo-restricted. See Secure token and signed access.
  6. Failure behaviour — origin failover and request collapsing. See Origin shielding and failover.
  7. Observability — logs to export and metrics to alert on.

Resource limits

Design within the platform’s per-resource limits rather than discovering them in production:

  • Aliases per resource are bounded; split into multiple resources when you exceed the practical hostname count.
  • Origins per group are bounded; use weighted groups and health checks rather than an unbounded origin list.
  • Header size and count — custom request and response headers count against a fixed budget.
  • Rule and policy counts — caching, access, and header rules per resource are limited; consolidate overlapping rules.
  • Certificate coverage — each alias must be covered by a certificate the resource serves.

If a planned resource would exceed a limit, split by concern (media vs API, brand vs brand) rather than stretching one resource.

Where AdultInfra fits

AdultInfra provisions and tunes these resources for adult workloads — range-heavy seeking, volatile live concurrency, and origin-egress cost — and can validate the design on a controlled slice before a full migration. Bring one hostname and the metric you want to improve and talk to us.

Need this configured for your platform? Get a test plan and an engineer will map the resource, cache, and delivery design to your workload.