Intermittent stylesheet errors on Heroku installation

(Kenny Meyer) #1

We have a Discourse setup on Heroku, running the latest Beta version 1.3.0.beta2.

We randomly get 404s on stylesheet GET requests - they look like:


The weird thing is that, if you do a few page refreshs the stylesheet is eventually found.

In addition to that, we use for asset caching, but the above mentioned URL is not a URL to our instance.

I also noticed that there’s a GlobalSetting.cdn_url setting, however on our site it set to nil and I cannot find a place in the admin to set it. Can it be related to the error I am getting?

The copy of that stylesheet is found on

Related topics:

(Kenny Meyer) #2

I just removed the __ws= part of the stylesheet URL, and it works more reliably now.

What do I lose with that? The possibility to live-update CSS?

I think it has to do with the websocket connection not being established with the client. It may be Heroku’s fault.

(Sam Saffron) #3

that is there for multi-site CDN support its unlikely you really need it. sounds really weird it would be causing an issue though.

(Kenny Meyer) #4

Hi @sam, you’re right - the __ws is unrelated to the bug. It still happens for me randomly on Heroku, and it’s driving us crazy. It’s the only file which is served intermittently, and it’s re-occurring even after several deploys.

(Sam Saffron) #5

Curious, is there a specific reason you are on heroku, its hard to get a tuned setup there like we do with our docker base image.

(Kenny Meyer) #6

For convenience reasons… what would you rather recommend in combination with Docker?

(Sam Saffron) #7

For convenience only I would, of course, recommend us.

If cost is a concern I would recommend Digital Ocean. You even have a web page you can go to to upgrade Discourse, its a far superior end user experience.

(Kenny Meyer) #8

Sorry, but to get back on-topic - we are still experiencing this issue. I just pushed the latest master, and it’s still serving that stylesheet intermittently.

(Sam Saffron) #9

I can’t really help much supporting heroku, its not a configuration we are familiar with … or support. Anything running on discourse_docker is 100% supported, free and way cheaper to host.

(Jeff Atwood) #10

We apologize, we are a small team and are limited in what we can support given the infinity of Linux distros and options. Docker is a survival mechanism for us, plus, it has worked very well and we use it exclusively for all our internal hosting.

(Kenny Meyer) #11

Ok, thank you guys - I’ll convince my team to opt for docker-friendly hosting solutions.

(Dave Lane) #12

Hi, I’m experiencing something that appears similar. I’m running 2 instances of Discourse on the same physical server, using 3 docker containers, one for data, and one docker “web” container for each instance. We are using nginx to proxy the sites served from the docker containers. We’re running into the problem that the CSS ceases to serve (returning 404) after a time. A restart of either of the web containers (’./launcher restart web’ or ‘web2’) restores the CSS’s availability temporarily. But after a few minutes or hours (not sure which), the CSS file ends up unavailable. It’s currently working here: after a restart…

Note, I’ve written up the details of our installation here: Multiple Discourses, multiple containers, one server

Multiple Discourses, multiple containers, one server
(fearlessfrog) #13

I can’t help with @lightweight’s issue (but perhaps it is related to file state) but I’m familiar enough with heroku to know that @kennym’s issue looks related to the ephemeral file system the heroku web dynos use:

In short summary, heroku doesn’t offer cross-dyno/server file reading, as in each dyno you allocate allows file writes fine, but it will appear completely random if that file is ever there again - unless your request gets routed back to the same dyno that wrote the file. You can test this out by scaling to a single dyno and it might then magically work (at least for a while).

Now even if you are using S3 for upload storage, it may be the case that a Discourse cache or something like


will get generated in a production env using the local file system just on the initial dyno call or asset build. The trouble is it is not being generated on every separate dyno file system, so will 404.

In even shorter summary, use a docker container and not heroku for Discourse. :smile:

(I realize this was an old issue, but wanted to at least explain why the original issue appeared on heroku).