Cannot get past bootstrapping

Installation
1

I’ve now installed Discourse on 2 different VMs.
I’m using the official install instructions.
One running Debian 12 in a VMWare Fusion instance on a Mac Pro, the other is Ubuntu 24 in a VM running under TrueNAS.
They are both on dedicated servers running on my local network with bridged networks and have unique accessible IP addresses.
The TN server hosts multiple other docker containerized apps and they are all working and accessible via LAN and Internet, the Mac Pro natively hosts a wiki.
On both, the bootstrap function completes, but I don’t get a working site. Just ‘server not responding’ in a browser.
According to docker ps the container “app” is up and running, listening on ports 80 and 443, ufw reports that it’s allowing those ports.
For a while the Debian site was showing an nginx default welcome page, but now that’s no longer responding either.
I’m not any sort of developer or web wizard so I’m not sure how to troubleshoot, I asked Grok for some help but so far nothing has worked.

Definitely appreciate any help given.

2

If they are not on the public internet with a domain name pointing at them then you can’t do a standard install.

You can look at Install Discourse on a residential internet with Cloudflare Tunnel

1 Like
3

I have a publicly available static IP address and a domain name pointing to that address.
I generally use a wildcard A record to point any host to that IP but in my troubleshooting I ran across a post saying that Discourse may not play nice with proxied addresses in Cloudflare DNS so I created a dedicated A record and turned off proxy for that one.

4

Did you run discourse-setup? Did it pass the connection test?

5

Am I using the term ‘bootstrap function’ correctly?
Just want to be sure we’re talking about the same thing.
./discourse-setup IS the bootstrap, right?
So if I say it bootstraps, and the container is running, then the connection test, which happens at the very beginning of the setup has passed.

Does all that make sense?

6

Well, sort of. It creates a app.yml and then runs ./launcher bootstrap app.

If you’ve run it a bunch of times without DNS working right then you’ve hit rate limits with let’s encrypt. The easy solutions are to wait a week or to use a different domain name.

And nothing else is running on that machine?

And when you ran discourse-setup it didn’t complain about not being able to connect to itself?

7

I’ve only run it once on each VM, and I used a different host name for each.

Brand new VMs with nothing else running on them. On the actual hardware there are other things running. But they have separate internal IP addresses from their hosts.

Correct.

8

Here’s the errors I found in the install output, none look like show stoppers:

690:M 30 Apr 2025 22:05:22.859 # Warning: Could not create server TCP listening socket *:6379: bind: Address already in use
690:M 30 Apr 2025 22:05:22.859 # Failed listening on port 6379 (TCP), aborting.

109:M 30 Apr 2025 21:59:42.411 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition...

2025-04-30 21:59:41.125 UTC [60] postgres@postgres ERROR:  database "discourse" already exists
2025-04-30 21:59:41.274 UTC [63] postgres@discourse ERROR:  role "discourse" already exists

WARN: Unresolved or ambiguous specs during Gem::Specification.reset:
      stringio (>= 0)
      Available/installed versions of this gem:
      - 3.1.7
      - 3.1.5
      - 3.1.1
WARN: Clearing out unresolved specs. Try 'gem cleanup <gem>'
Please report a bug if this causes problems.

The setting 'staticAddonTrees' will default to true in the next version of Embroider and can't be turned off. To prepare for this you should set 'staticAddonTrees: true' in your Embroider config.
The setting 'staticAddonTestSupportTrees' will default to true in the next version of Embroider and can't be turned off. To prepare for this you should set 'staticAddonTestSupportTrees: true' in your Embroider config.

Node.js heap_size_limit is less than 2048MB. Setting --max-old-space-size=2048 and CHEAP_SOURCE_MAPS=1

-e DISCOURSE_SMTP_DOMAIN=discourse.example.com

[BABEL] Note: The code generator has deoptimised the styling of /var/www/discourse/app/assets/javascripts/discourse/ember/ember-template-compiler.js as it exceeds the max of 500KB.
[BABEL] Note: The code generator has deoptimised the styling of /var/www/discourse/app/assets/javascripts/discourse/ember/ember.js as it exceeds the max of 500KB.
9

What are the specs of your VMs? As in, how many vCPUs/RAM is allocated to them?

10

Both have 2/2

1 Like
11

Does increasing it to 4 GB RAM help? I think the memory requirements may have gone up.

1 Like
12

I wasn’t thinking about the fact that since port 80 is already in use and I only have the one external IP that even though the domain check was passing during the setup process, I had to alter the host side ports to get things going.

I’m using NPM internally.

Steps to get things working:

  1. Change host side port to 7080 for http
  2. Since I’ll be passing traffic through my proxy manager I simplified my life and disabled the LE scripts
  3. Updated the app
  4. Passed ‘ext IP:80’ to ‘int IP:7080’ in the reverse proxy, then the container reversed the ports… then they did the Hokey Pokey and turned around.

Now everything so far appears to be working.

2 Likes