If you want to use a custom CDN url (e.g cdn-discourse.yourdomain.com) you must create a zonealias. Otherwise, you can use the zone url provided by KeyCDN which will look similar to: http://discourse-1.kxcdn.com.
Update your app.yml file by uncommenting the CDN line and adding your custom CDN or zone url:
## the origin pull CDN address for this Discourse instance
DISCOURSE_CDN_URL: //discourse-cdn.yourdomain.com
Rebuild your Docker container:
./launcher rebuild app
Finally, double check your Page Source to verify that the urls have been modified and reflect the CDN url you have specified in step 4.
Setting up KeyCDN for Discourse was very easy and simple. So far liking the service.
However, I am unable to enable Brotli in KeyCDN zone settings. Their tech support says that when enabling the setting, the system verifies whether the origin support Brotli – this test fails on my standard Discourse 1.9 Docker instances.
I assumed that Discourse does support Brotli compressed assets and snooping the source of Meta supports this. Is this a glitch at KeyCDN (Brotli support is very new) or with Discourse?
At least I don’t have references to .br* assets in the HTML source, like you do here at Meta. I don’t know how KeyCDN validates this, but apparenty my sites fail the test. So does Meta, btw.
Edit: Looking at a rebuild process, I do see some things Brotli going on, even without the environment variable set. So I guess the assets are indeed generate, but for some reason not good enough for KeyCDN.
Well, one thing is verified - KeyCDN has very good support staff. They really drilled into this, for a small-time customer:
I’ve checked back and discourse is a bit of a special case here. Discourse is using service workers on the client side to do the handling and switch when to use br assets with client-side JavaScript.
Your pages are already delivering Brotli-encoded content through the CDN as can be seen in the Chrome Dev Tool. (Screenshot)
So @sam’s comment was the real deal. I just could not verify it personally.