Aws deployed discourse is fetching assets from database url

Hi Team

I am running disource on aws ecs. When I am trying to run the application, the console tab in browser is failing with the below urls. Did I miss any configuration change?

Mixed Content: The page at ‘’ was loaded over HTTPS, but requested an insecure favicon ‘’. This request has been blocked; the content must be served over HTTPS.

In the above URL this is my database endpoint

I have given the above end point in database.yml file.

I deployed discourse in ECS using docker. When I try to access the application the network browser is fetching resources from below URLs instead of

This is our RDS endpoint which is used in database.yml file.

Mixed Content: The page at ‘’ was loaded over HTTPS, but requested an insecure favicon ‘’. This request has been blocked; the content must be served over HTTPS.

Refused to load the script ‘’ because it violates the following Content Security Policy directive: “script-src”. Note that ‘script-src-elem’ was not explicitly set, so ‘script-src’ is used as a fallback.

Looks like a misconfiguration of your S3 bucket.

How did you install Discourse? Did you use Discourse official Standard Installation or perhaps was it Troubleshooting Bitnami Installations?

I’m putting my money on a misconfigured CDN.
Can you share your config/discourse.conf ?
And search your site settings for c0fbtc and see if you get hits.

Hi Jay

Ive installed it as a regular rails application. Below are the steps Ive followed.

  1. Cloned the github repo.
  2. Bundle installed the gems.
  3. Modified database.yml file to point to AWS RDS endpoint.
  4. Modified discourse.conf file for pointing to AWS Elasticache.
  5. Did not use S3 bucket configuration anywhere.
  6. Copied the code inside a docker container and deployed it on ECS.

I did not use the prebuilt docker image. Ive built a docker image myself.

deleting config file

That does not seem right. If I were you I would check if my database wasn’t actually local and has a weird name.

I think it should look like this:

# host address for db server
# This is set to blank so it tries to use sockets first
db_host =
# database name running discourse
db_name = default

What is S3 used for? And also do I need to create a separate discourse.conf file without changing anything in discourse_defaults.conf file?

This has nothing to do with S3.

The discourse.conf file is generated from your app.yml, you should make changes there and rebuild.

1 Like


I cloned discourse from I couldnt find app.yml file anywhere in the repo.

All the discourse setup is pointing to discourse_docker which I dont want to use. I want to build my own container.

(I must warn you for trying to reinvent a perfectly working wheel. Also, some people over here are not going to be very enthusiastic about supporting you since it does not benefit the community).

Whatever you do, eventually you should make sure that those values end up in your discourse.conf correctly. If you edited it manually, you should at least put the AWS hostname in db_host and leave db_name to default.

1 Like

Hi Richard,

I am on the same team as Vijay. The specific use case we are trying to address here is to fork out Discourse and put in our company’s github. From here, we would build and deploy to AWS. The reason we want to have it in our github is to keep the flexibility of making changes as per our requirements. We would like to contribute back wherever applicable. Since we could not find a dockerfile in the discourse public repo, we ended up creating our own to build the docker image. Further, we use Github actions to deploy the docker to AWS ECS service.

Considering our requirement, do you think we could have taken any other approach?


Yes. My recommendation is to use the official discourse and discourse_docker repositories and implement all changes as plugins.

Using the official discourse_docker will save you from issues like the one in this topic, and not forking Discourse but keeping all your modifications in separate plugins save you from deviating from the main branch and having to put lots and lots of effort into porting all upstream changes back into your fork.

The learning curve of developing plugins will break even on the effort of merging upstream within a few weeks and from then on it is only more efficient.

When you are using the official Discourse repo then you can also consider managed hosting and people will be more enthusiastic (and/or less expensive) when they need to help you out.


Thanks for your inputs. Had a couple of follow-up questions:

  1. With the plug-in approach, is their a possibility that we might hit a bottleneck with some requirements which may not be possible through plug-ins? For instance, managing user roles in a very customized way?
  2. What would the end to end pipeline look like if we take the discourse_docker and deploy in our AWS account on ECS? As I mentioned, we use Github actions as of now to deploy to ECS in our AWS account. What deployment strategy can we use from public repo while still protecting our AWS credentials?
  1. Plugins support Ruby monkey patching and extending Ember objects so in the end everything is possible.

  2. Not my expertise, so I will leave this up to someone else.

Always start with a copy of the discourse_docker repository. Create an app.yml therein.

Use the bootstrap subcommand of the launcher script in your working copy of discourse_docker to create a docker image. Push the docker image to a docker repository. Deploy that docker image anywhere you like.

Write plugins if you need to. List your custom plugins in the app.yml like the other plugins.


@ashish_rawat @Vijay_Vantipalli How did you set up Discourse Docker in ECS? When I try on EC2 server, Discourse is loading fine. But when I push the Discourse Docker image to the ECR registry, and create a task from that image, the container is not running – I just get Exit Code 1. I’ve been stuck for more than a week now. I would love to hear your advise. Thank you!

Created a separate RDS instance and ElastiCache for Redis cluster for this.

Try examining the arguments present in ./launcher start-cmd app - there might be something in there that you’ve missed copying over to ECS.


Thank you for the fast response! I think I’m just missing something simple. I’ll try to do that.

Sorry if this is out of your scope. I tried adding the “-e” I found from start-cmd app, but there are other arguments like the following:

+ /usr/bin/docker run --shm-size=512m -d --restart=always 
-h <server ip> 
--name app -t -p 80:80 
-v /var/discourse/shared/web-only:/shared 
-v /var/discourse/shared/web-only/log/var-log:/var/log 
--mac-address <address> local_discourse/app /sbin/boot

Is the -v really required?

Yes, those are volume mounts. It is absolutely required for Discourse to have storage available at /shared inside the container.