Transloadit

What are Multiple CDN Domains?

Using multiple CDN domains distributes asset URLs across distinct hostnames for separation, migration, branding, or routing. Each hostname may use different certificates, cache policies, or origins.

How Multiple CDN Domains work

Splitting assets across hostnames began as a performance technique called domain sharding. Browsers limit the number of simultaneous connections per domain, so serving assets from several subdomains let a page download more files in parallel. HTTP/2 and HTTP/3 carry many requests on one connection, which removes that reason, and MDN now describes multiple domains as an anti-pattern for performance because each one can add a DNS lookup and connection setup. What remains are the uses that have nothing to do with parallel downloads: a hostname per customer, per security boundary, per class of media, or per CDN during a migration. To a browser each hostname is a separate origin, and on the CDN each one needs its own DNS record, certificate coverage, and routing, even when all of them reach the same CDN and the same origin server.

Key facts

  1. Do extra hostnames still speed up page loads? Not as a rule on HTTP/2 or HTTP/3. Domain sharding worked around the browser’s per-domain connection limit; MDN calls it obsolete once HTTP/2 is enabled, because each extra hostname can cost a DNS lookup and a new connection. A browser may reuse an existing connection for a second hostname only when the server is authoritative for it. Under HTTP/2, RFC 9113 ties reuse to the hostname resolving to the same IP address and, for https resources, additionally to a certificate that is valid for that hostname; RFC 9110 adds that a server can lift the DNS check by sending an ORIGIN frame. Under HTTP/3 the client must validate the server’s certificate for the new hostname. A server can refuse reuse with a 421 (Misdirected Request) response.
  2. Does a browser treat a second hostname I own as the same origin? No. An origin is the combination of scheme, host, and port, and RFC 9110 states that two origins are distinct if they differ in any of the three, even when the same entity controls both. A page on www.example.com that calls fetch() against media.example.com, or loads a web font from it, needs CORS headers from the media hostname. An image that is only displayed loads without CORS approval, but drawing it into a canvas taints the canvas, and reading the canvas back then throws a SecurityError.
  3. Will cookies reach a separate media hostname? Only if their scope covers it, and scope alone does not guarantee delivery. A cookie set with Domain=example.com can be sent to example.com and to its subdomains, such as media.example.com. A cookie set without a Domain attribute is returned only to the host that set it. No cookie scoped to example.com is sent to a hostname under a different domain. Within that scope the request still has to carry credentials: a cross-origin fetch() sends no cookies unless its credentials option is set to include, and MDN notes that third-party cookie policies can stop cookies from being sent even then. Verify both before relying on cookie-based access control on the media hostname.
  4. What does each additional hostname require on the CDN? A certificate that covers it, a DNS record that routes it, and a configuration that accepts it. Amazon CloudFront, for example, adds an alternate domain name only if the attached certificate covers it in its subject alternative names, and rejects a name that already exists on another distribution. It attaches one certificate to a distribution at a time, so that certificate has to cover every hostname on the distribution. The routing record is normally a CNAME, and CloudFront requires permission to create it with the domain’s DNS provider, so for a customer-owned hostname the customer has to create that record or give you that access. DNS does not allow a CNAME at the top of a domain (the zone apex), so this works for a subdomain such as media.example.net but not for example.net itself; for an apex, CloudFront documents an alias record in Amazon Route 53 or, with another DNS provider, Anycast static IP addresses. Certificates imported from a third-party authority must be monitored and renewed by you. AWS Certificate Manager renews the certificates it issues, but not unconditionally: a DNS-validated certificate renews automatically as long as it is in use by an AWS service and its validation CNAME records remain in public DNS, and an email-validated one needs the domain owner to act. For customer-owned domains, agree who maintains those records, and monitor expiry for every hostname, not just the main one.
  5. Is one file cached once or once per hostname? That depends on the CDN’s cache key. Cloudflare’s default key includes the host, so the same path requested through two hostnames is two cache entries. CloudFront documents its default key as the distribution’s domain name plus the URL path and states that no other value from the viewer request is included by default. This matters in both directions. If every hostname serves the same library, a key that separates hostnames stores duplicates, and CloudFront warns that duplicate objects lower the hit ratio and increase origin requests. If the response differs by hostname, as with one hostname per tenant, the key has to tell the hostnames apart, because requests that produce the same key receive the same cached object. CloudFront’s rule is to include in the key any request value that determines the origin’s response.

When Multiple CDN Domains matter

Use separate hostnames to isolate tenants or asset classes, to offer customer-branded delivery domains, or to migrate between providers gradually. A separate hostname gives a tenant its own browser origin, not its own cached responses: tenant-specific content also needs a cache key or cache configuration that tells the hostnames apart. Do not add hostnames only to speed up page loads on HTTP/2 or HTTP/3. Every extra hostname brings its own DNS record, certificate coverage, CORS behavior, cookie scope, and cache configuration.

How Transloadit helps with Multiple CDN Domains

Two documented Transloadit features involve the delivery hostname. Smart CDN URLs are served from a Workspace-specific hostname, [your-workspace].tlcdn.com, so each Workspace has its own delivery hostname. When an Assembly exports to your own bucket with the /s3/store Robot, the url_prefix parameter sets the prefix of the URL returned in the Assembly Status, which lets you hand out links on a CDN hostname that you operate in front of that bucket.

url_prefix changes the returned URL only; it does not change the bucket or its access permissions, and the hostname itself has to be configured with your CDN and DNS providers. The pages linked here do not describe serving Smart CDN URLs from a custom domain.

Explore Transloadit’s delivery capabilities

Sources

Turn media knowledge into a working pipeline

Connect uploads, processing, AI, storage, and delivery through one declarative API — with the encoding stack, scaling, and format churn handled for you.

Try Transloadit for free