Configuring Bring-Your-Own (BYO) CDN for NextGen Live Playback

In this topic, you will learn how to enable your own CDN.

Prerequisites

  • Shared BCOV token from Brightcove Support.
  • Your Hostname value that pairs with the token.
  • Ability to configure your CDN/reverse proxy origin, request headers, and cache behavior.
  • HTTPS/TLS enabled for origin fetches.

Quick start

  1. Set the BYO origin to https://playback.live.brightcove.com.
  2. Append an auth header on origin requests: BCOV-CDN-Auth: <token-shared-by-support>. Do not require clients to send this header and do not expose it downstream.
  3. Set the forwarded host header on origin requests: X-Forwarded-Host: <hostname-assigned-to-token>. The value must exactly match the hostname.
  4. Respect origin caching: Honor Cache-Control, Expires, Last-Modified, and any relevant Vary directives. Do not override with more/less aggressive policies.
  5. Deploy and validate using the checks below.

Validation & troubleshooting

Quick checks

  • Confirm in CDN logs or origin debug tools that requests to Brightcove include both headers with expected values.
  • Request a known live playback URL through your BYO edge and verify successful playback and expected cache behavior (e.g., presence of Cache-Control).
  • Verify that private headers (BCOV-CDN-Auth, X-Forwarded-Host) are not exposed to clients.

Failure-path checks

  • Missing token → Expect 401/403
  • Bad token → Expect 401/403
  • Wrong or mismatched X-Forwarded-Host → Expect 403

Cache behavior

  • Verify Cache-Control headers from the origin are preserved.
  • Repeat requests should show increasing Age when served from cache.

Common pitfalls

  • Adding headers to client responses instead of origin requests
  • Enforcing a fixed CDN TTL that conflicts with origin Cache-Control
  • Typos or case differences in X-Forwarded-Host vs. the hostname
  • Leaking BCOV-CDN-Auth downstream to clients
  • Overriding the Host header for origin fetches (unless instructed by Support)