Configure an S3 compatible object storage provider for uploads

Sorry, I can’t get.
Why do we have to specify settings in app.yml, as we can enter this information within from Discourse->Settings ?

1 Like

Because of the way that it handles building assets when the container is built, I think. It is quite confusing that the behavior is different when the settings are in the environment variables and the database, but that’s the way it works. It’s also a better way too handle them, as it means you can build and restore a new site from the command line.


Where should I set this? I’m not finding it in Discourse admin settings?

1 Like

It’s set in the example configuration block for Vultr in the OP. Copy and paste into your app.yml and adjust the necessary fields.


Thanks, I missed this bit:

1 Like

This isn’t going smoothly for me, sorry to reply so many times.

If I do the above, should I ignore the admin panel settings for s3 and backups?

Or should admin panel settings be configured as well?

1 Like

You just need to follow this guide here in the OP and you will get a functional object storage configuration.


Setting those variables makes them unavailable from the UX. You must set them as described here rather than the ux.


I think it’s (mostly?) working now, but is this content security policy script src safe?

I’m using AWS for two S3 containers (for uploads & backups), and two CloudFront CDNs (for files & assets). When I use my own CNAMEs for the CloudFront CDNs, I get a bunch of script-src network errors in my browser when loading Discourse. No more errors after adding those entires to my CSP.

1 Like

Are those the urls you put in the env variables described in the OP? And are they https?

1 Like

Yes, I don’t have script-src warnings when I put the two URLs in the env variables. When I put my custom URLs, i.e. community-cdn.mydomain and files-cdn.mydomain, in the env variables, that’s the time I get these script-src warnings. And apparently the stripe js is still giving me this warning even though it’s in my content security policy script src.


I set up S3 Uploads and object storage as outlined here in the OP, but without a CDN.

For the DISCOURSE_S3_CDN_URL variable, I have this:

All seems fine, including backups, however, in the console this error shows up when a reply to a post is started:

The request url in the error is actually a string of two urls which seems like the cause?


A CDN is mandatory for it to work correctly.


I’m also in this situation with an object store configured (minio) but no CDN. Is it a use case that could be supported ?

From what I’m seeing so far in my tests there is only the markdown-it-bundle js file that is having issues as its pointing to the wrong URL - DISCOURSE_HOSTNAME/DISCOURSE_S3_CDN_URL/assets/

It actually looks lit a bug for this one, if I set DISCOURSE_CDN_URL variable, it still points to the wrong URL in this form DISCOURSE_HOSTNAME/DISCOURSE_CDN_URL/assets/

it should point to DISCOURSE_S3_CDN_URL/assets/

Other js assets are pointing to the right URL ’

I guess from what you are saying I will have other issues that I have not identified yet. Maybe you can give me more info on what could go wrong ?

If I undestand it well, js assets are on the object store, stylesheets should be on a CDN. WIthout a CDN could the stylesheets be delivered by the app as usual ? (from what i’m seeing its the case)

Thanks for your help


That is not a supported use case per the OP:

1 Like

Dear all,

I set up a new discourse server with Lightsail, using this guide for S3 uploads and backups setting-up-file-and-image-uploads-to-s3

After setup, I got the error shown “The bucket does not allow ACLs” on the screen when I upload an image

Here is my policy for S3:

    "Version": "2012-10-17",
    "Statement": [
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
            "Resource": [

And here is my setup public access for S3 bucket:

Would someone help me to solve this issue, please?
Thanks so much


Should my staging site use the same S3 bucket as my production site?

1 Like

No, that would be very unsafe, and it could delete files that should still exist in the other environment and change files from the other environment (which could cause missing files, wrong files, and so on).

Both the buckets as well as the credentials should be different (and the staging credentials shouldn’t have access to the production bucket, specially regarding write and delete operations).

Maybe there’s a way using paths with different credentials for each path, but the chances of shooting your own foot are high, so I advise to use separate buckets.


DISCOURSE_CDN_URL and DISCOURSE_S3_CDN_URL need to be separate as well?

1 Like

I assume so, because if your staging and production domains/urls are different (they are, aren’t they?), then DISCOURSE_CDN_URL (that ends up pointing to the CDN provider, which points to your website domain) is expected to be different for staging and production. The same logic applies to DISCOURSE_S3_CDN_URL (because different buckets should have different urls).