Install Discourse on a residential internet with Cloudflare Tunnel


I just installed Discourse and Cloudflared on my R-Pi 4, and I followed the instructions in the original post, but I am not sure on what to put as a host for Discourse, should I just put localhost since cloudflared tunnel will forward it ?
Maybe @Falco could help ?

Btw sorry for bumping.

1 Like

You still need to own a domain for this guide, so the host value will be either the domain apex or the subdomaon you configured for Discourse and for the tunnel.

1 Like

So the host value should be the subdomain I want Discourse to be in ?

1 Like

Yes it should be the url where you want Discourse to be.


Are you sure ?
If I do that, it gives me this error :

Do you think i did something wrong ?

I set the Discourse hostname to the exact subdomain where I want discourse to be.
I installed Cloudflared on R-Pi4 from the CLI (as written here : and I am running it as a service.
And I installed discourse as mentioned in your original post I am pretty sure.

1 Like

Can you share the domain?

Could I send it to you in DMs ? Don’t really want random people to see it.

Is it working now that you put up the proper domain?

1 Like

Yes ! Just booted it up ! Thanks for your help ! I only have an issue with MailJet (the mail provider I use for STMP), which is having fun pre-blocking my verification emails…


A post was split to a new topic: Any MailJet alternatives?

A post was merged into an existing topic: Any MailJet alternatives?

Hey there, I managed to have a working install ! Just had a small question, how much activity/members do you think a R-Pi 4 Model B with 4 gigs of RAM can handle ?


That’s a great question. Since it’s hard to make a direct correlation between number of users and the server load in a complex system like Discourse, it’s fair to acknowledge that the main bottleneck in a RaspberryPi system is the storage IOPS.

So as long as most of your needed resources are in the RAM, between proccesses RSS and Linux caching, you should have a smooth experience. The fact that Cloudflare is acting like a caching CDN will also help quite a bit, and you can even stretch the longevity of the Pi setup by using Using Object Storage for Uploads (S3 & Clones) after a while.


i got this error parts of docker

Pups::ExecError: /usr/local/bin/ruby -e 'if ENV["DISCOURSE_HOSTNAME"] == ""; puts "Aborting! Domain is not configured!"; exit 1; end' failed with return #<Process::Status: pid 115 exit 1>
Location of failure: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params "/usr/local/bin/ruby -e 'if ENV[\"DISCOURSE_HOSTNAME\"] == \"\"; puts \"Aborting! Domain is not configured!\"; exit 1; end'"
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.

That means you didn’t configure your domain properly. You need a valid domain for this to work. Run ./discourse-setup again or edit the app.yml file to fix it.

1 Like

thx for reply
i sucessed deploy it on RockPi4 :+1:


hi @Falco,

i’m pretty sure i set it up just like your guide, but i’m noticing something weird.

in the container config, i am not loading the ssl templates, and i have the DISCOURSE_FORCE_HTTPS env var set to true. not sure what that does, but i’m guessing it sets SiteSetting.force_https to true and then hides it in the admin dash to prevent it from being disabled.

my cf tunnel config is like this:

  - hostname:
    service: http://dc:80 # dc is my discourse standalone app container name

the thing is, i can visit, and it doesn’t get redirected to https. is that the expected behavior?

can you reproduce this? i wonder if it’s a bug.

my relevant cf settings are:

  • SSL/TLS > Overview > SSL/TLS encryption mode: full (not full (strict))
  • SSL/TLS > Edge Certificates > Always Use HTTPS: off

i know i can make cf do the redirection (either with Always Use HTTPS or a bulk redirect rule), but i would have assumed that discourse would handle that and redirect all internal URIs if force_https is on. thoughts?

ignoring the redirect issue, browsing works fine regardless of the value of DISCOURSE_FORCE_HTTPS or SiteSetting.force_https.

edit: despite not understanding what force_https is actually doing for us (maybe it just does nothing if the ssl templates aren’t included?), it just occurred to me that the tunnel config probably wouldn’t work as-is if discourse actually https redirected everything. if it did that, argotunnel couldn’t hit discourse with http (like service: http://dc:80), so maybe i should:

  • rely on cf to do my redirecting OR
  • have discourse use a cert and have cloudflared hit the discourse origin with https (service: https://dc:443)

anyways, maybe your argotunnel guide could be updated to account for this?


Oh you are right. I haven’t noticed this my test TLD .dev is HTTPS only:

I updated the guide telling people to use a page rule for this, thanks for the report!


but i have a question…
i see high anon view on Consolidated Pageviewshow, i think that because of ddos because the cpu server got on 60% and the crawler is just little bit… but how about to protect from ddos… thanks before for answer

1 Like

if you use cloudflare as a reverse proxy (a separate thing from cloudflared/argotunnel), you should get some ddos protection out of the box. enable it with the ‘orange cloud’ on your dns record(s).

1 Like