Varnish config for discourse

(Quintin Par) #1

Is there an official config for discourse that I can use?

(Joshua Rosenfeld) #2

There is not an official Varnish config for Discourse.

(Eli the Bearded) #3

Not official, but there have been some stabs at it before.

(Quintin Par) #4

Thanks. A bit surprised there since Discourse has official support for Fastly and that means there should be a config the team uses.

(Sam Saffron) #6

Fastly does standard origin pull, you don’t need to fuss with Varnish. We have already 2 howtos that cover this depending on your level of adventure/pain. is configured using “full site CDN acceleration”

(Quintin Par) #7

Please correct me if I am wrong, but don’t you need to do invalidation when some one replies, update categories pages when new content is added etc. My understanding is that one needs to run the invalidation logic from the code to caching system. Therefore I thought Discourse should be having a varnish config file that’s probably deployed on Fastly.

(Sam Saffron) #8

no not really, you only have to invalidate stuff you are caching.

(Richard - #9

Discourse can only use a CDN for static assets, not for content.

(Quintin Par) #10

Ohh ooh. That’s a revelation. Huge bummer.

(Jeff Atwood) #11

I don’t think what @RGJ said is correct; you can visit our hosted Fastly community at which goes entirely through Fastly, content and all.

(Quintin Par) #14

Thanks Jeff. Huge relief. Am I right in assuming that ‘s varnish config is by them and not by the discourse community.

(Jeff Atwood) #15

We generally don’t recommend this config because it is quite complicated and does not get you much that a traditional (and far, far simpler) CDN of static assets does not already deliver.

(Quintin Par) #16

CDN, in this case is not for performance but for high availability – I offload everything and my single server is hardly hit with more than 1 RPS (almost only the logged in people). In the eventuality that my server goes down(which often does), the read-only site is always up, even if the login and such functionality is limited.

(Sam Saffron) #17

Hmmm … no … we never cache any dynamic content. Any caching we do is done in the app.


It is possible that a vary by x-discourse-username would allow us to cache for anon via headers. I never experimented with that implementation.

As it stands all dynamic requests like looking at this page hit the app.

(Quintin Par) #18

Thank you for the clarification. I’ll also post this question on in case they have something interesting.