Discourse CDN set up with KeyCDN

(Cody Arsenault) #1

For those who are using Discourse and are looking to integrate with KeyCDN, here is a quick step-by-step set up guide.

  1. Login or sign up for a 30 day free trial if you don’t already have a KeyCDN account.
  • Create a Pull Zone within the KeyCDN dashboard and enter the origin url of your Discourse instance.

  • 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.

(Sven) #2

In case you installed Discourse in a subfolder - Subfolder support with Docker

Remove those 2 lines from the app.yml config before your rebuild the app:

- rm public/uploads
- rm public/backups

Otherwise will it remove your existing uploads and backups.

(ljpp) #3

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?

(Sam Saffron) #4

KeyCDN works with brotli just fine, be sure to rebuild your container so it has the enable brotli env setting.

(ljpp) #5

Is there a reason why it is not enabled by default (or even included in the .yml)? Risks, downsides?

(Sam Saffron) #6

It is:

@Falco added that magic a while back.

(ljpp) #7

Okay, “a while back” refers to 2.0 development branch, I presume.

(Sam Saffron) #8

Yeah, with the base image you are running, that “stable” thing you enter has no impact on it unless you somehow are running on a custom base_image

(ljpp) #9

Now you completely lost me.

Yes, I always use stable, so currently on 1.9. At least according to KeyCDN’s validation my intance is not Brotli enabled.

I added COMPRESS_BROTLI: 1 and rebuilt one of my instances, and KeyCDN still disagrees – trying to enable Brotli returns an error.

(Sam Saffron) #10

Have you confirmed you are actually not serving brotli, cause my CDN hack means it don’t matter what they say

(ljpp) #11

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.

(ljpp) #12

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.