Upcoming domain change to ensure delivery of your video content

Hi everyone, Brendan here, Product Manager for Cloudflare Stream. Wanted to let everyone here know about an upcoming change that we’re making to ensure delivery of your video content.

Starting Aug 15, 2022, Cloudflare Stream will begin serving on-demand videos and live streams from a subdomain that is specific to your Cloudflare account: customer-{CODE}.​cloudflarestream.com. The existing domains that serve Stream and Stream Live content, videodelivery.net and cloudflarestream.com, will continue to work as they do today. Stream Player embed codes in the Dashboard and Stream API responses will use this new subdomain.

Do I need to take action?

Only if you use Content Security Policy (CSP) on your website. Otherwise, no action is required.

  • If you use CSP and the Cloudflare Stream Player, add *.cloudflarestream.com to the frame-src CSP directive.
  • If you use CSP and a 3rd party player, add *.cloudflarestream.com to the media-src, img-src, and connect-src directives, or the fallback directive, default-src.

You can read more documentation here.

All existing Stream Player embed codes and requests to videodelivery.net and cloudflarestream.com URLs will continue to work.

How does this change benefit me?

  • This change gives you the option to use Content Security Policy directives specific to your Stream subdomain, to ensure that only videos from your Cloudflare account can be played on your website
  • This change gives you the control to allowlist only your Stream account subdomain at the network-level to ensure that only videos from a specific Cloudflare account can be accessed on your network

Still have questions?

Comment below on this post. I’ll be reading all replies — we’re here to support you with this change and answer any questions you might have.


Will this change also help with the ongoing issues with local ISPs on videodelivery.net in any way?

E.g. the warning on the dash: “Cloudflare is investigating reports of videodelivery.net being inaccessible from certain local ISPs…”

Yes — by providing a subdomain that is specific to your Cloudflare Account, we’re trying to ensure that if an ISP does take action, the impact is isolated to the account hosting this content, and you are not impacted by the actions of other Stream customers.


I use both the signed URLs and allowed origins features. Will this change impact that at all? I want to confirm since my site has customizations to use signed URLs.

Several questions about this change -

  1. Are thumbnails going to continue using apex cloudflarestream[dot]com domain (and videodelivery[dot]net) after Aug 15 or will we be able to use customer-{code} for iframes and thumbnails? (can’t post a URL but title of doc is Display thumbnails · Cloudflare Stream docs)
  2. Do we know what customer-{code} will be yet? I didn’t see it in the dashboard

This change will not impact how signed URLs or allowed origins behave.

See below an example of how it will change the response from the Stream API.

  • Previously, the preview URL came from the domain watch.cloudflarestream.com, and the thumbnail URL from videodelivery.net.
  • With this change, these URLs each come from customer-m033z5x00ks6nunl.cloudflarestream.com, where m033z5x00ks6nunl is the code specific to your Cloudflare Account.
  "result": {
    "uid": "8d717d9d1b0920ea247a4eebd747b1fd",
    "preview": "https://customer-m033z5x00ks6nunl.cloudflarestream.com/b236bde30eb07b9d01318940e5fc3eda/watch",
    "thumbnail": "https://customer-m033z5x00ks6nunl.cloudflarestream.com/b236bde30eb07b9d01318940e5fc3eda/thumbnails/thumbnail.jpg",
    "readyToStream": false,
    "status": {
      "state": "downloading"
    "meta": {
      "downloaded-from": "https://storage.googleapis.com/stream-example-bucket/video.mp4",
      "name": "My First Stream Video"
    "created": "2020-10-16T20:20:17.872170843Z",
    "size": 9032701,
  "success": true,
  "errors": [],
  "messages": []
1 Like

Thanks for the questions @m.alfih.

  1. After Aug 15 you will be able to use any of these — videodelivery.net, cloudflarestream.com, or customer-{code}.cloudflarestream.com, for iFrames and thumbnails. We recommend the latter.
  2. The code specific to your Cloudflare Account will be available in the Dashboard and in API responses starting August 15.

We have lot of zones hosting competing clients, although serving them all from a host specific to our Cloudflare account is an improvement, is there on a horizon support for a zone specific Stream?

In the announcement you mentioned “add *.cloudflarestream.com to the frame-src CSP directive” isn’t that unnecessarily broad? i.e. shouldn’t the customer-{code}.cloudflarestream.com host be sufficient?

Hi @libor1!

  1. allowedOrigins might help you achieve what you’re looking for with zones: Secure your Stream · Cloudflare Stream docs
  2. Yes, if you want further control, you can restrict frame-src to your own subdomain, customer-{code}.cloudflarestream.com. This subdomain will be available in the Stream Dashboard and via the Stream API starting Aug 15th.
1 Like

Any update on the release date? We are seeing the new domain on our dashboard in an informative message, but get 404 trying to access the videos and thumbnails using that domain.

This change is now live.


@irvinebroque The change is not as seamless as it was made out to be. Previously, we were able to embed iframe.videodelivery.net/<signed_video> - the same worked with iframe.cloudflarestream.com/<signed_video>. HOWEVER, with the customer specific url, the iframe is located at customer-{CODE}.​cloudflarestream.com/<signed_video>/**iframe**.

Hey @m.alfih — thanks for the feedback. We’re working on some additional updates to our docs to make this clearer.

With this change the domain you make requests to is now consistent — rather than sometimes making requests of some types to a subdomain (ex: iframe.cloudflarestream.com) and others directly to cloudflarestream.com, now everything runs through customer-<CODE>.cloudflarestream.com. Hope that moving forward this is clearer and easier to work with — apologies that this didn’t feel as seamless as it could have been to you.


Great to know and hopefully anyone struggling will see this thread. I just wished this information was made available as soon as you announced the new domain - we tried to be ready in advance with configurations to just switch and we ended testing after version release and finding it didn’t work and need another tiny hotfix.

Thank you for your assistance with this @irvinebroque.

Currently, I’m not aware of a way to use the API to retrieve the subdomain / customer-{CODE}, except to list videos and parse a URL from from something like a listed thumbnail. If there are no uploaded videos, presumably it’s not possible.

Ideally, the subdomain / customer-{CODE} might be provided as part of the response from a zone endpoint:

curl -X GET "https://api.cloudflare.com/client/v4/zones/SOMEZONEID" \
-H "Authorization: Bearer SOMETOKEN" \
-H "Content-Type:application/json"

Or an account endpoint:

curl -X GET "https://api.cloudflare.com/client/v4/accounts/SOMEACCOUNTID"
-H "X-Auth-Email: [email protected]" \
-H "X-Auth-Key: SOMEAPIKEY" \
-H "Content-Type: application/json"

Thanks @Bink!

This subdomain should be something you only need to retrieve once — it will not change, and is account level — when you use Stream, you never have to think in terms of zones.

That said, we’ll be adding the subdomain soon to the Cloudflare Dashboard to make this easier and clearer for everyone. Your point about needing to first have uploaded a video is spot on — appreciate the feedback.

1 Like

The use case for this request, is with respect to the WordPress plugin update.

Ideally, when a user installs the plugin and enters their Cloudflare credentials, the subdomain / customer-{CODE} is automatically pulled from Cloudflare and set. From that point on (if the user activates the optional setting), the subdomain can be locally referenced for generating content embed code.

The alternative, is to require users to manually enter it, or probe for it in other places, such as when video content is uploaded or requested. These are fallback options, but perhaps less elegant.

1 Like